[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: vms argv and exit status fixes.
John E. Malmberg
Re: vms argv and exit status fixes.
Sat, 08 Mar 2014 07:47:53 -0600
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
On 3/8/2014 6:15 AM, h.becker wrote:
On 03/07/2014 02:24 PM, John E. Malmberg wrote:
On 3/6/2014 6:14 PM, h.becker wrote:
For DCL it will be only one format.
Not true. The decc$ features can be set by logical names, and a user
may have set them for the various formats.
It as a user/administrator error to enable a decc$ feature with a
logical name other than /user prior to run the program which relies on
that feature (and is incorrectly coded not to use image initialization
Only if the user is aware of that restriction, which most are not. Many
programs set feature logical names for their own use and then LIB$SPAWN
children, and sometimes like GNU Make, the children can be any program.
If a C program can be broken by an incorrect decc$ feature name, it
should protect itself with a lib$initialize section.
I disagree. The decc$ feature design is broken and should be fixed,
maybe with a feature logical :-). Any program which relies on a decc$
feature should set it with image initialization code (or any other
appropriate interface provided by the crtl). But that is another
discussion and doesn't seem to belong here.
You say you disagree, yet your statement agrees with mine. The
lib$initialize section is the documented method that the CRTL states to
use to accomplish this.
And I agreee that the decc$ feature design is a bit broken, as in some
cases it has the run-time setting of features that should be set at
How about this, I append the process ID string to the symbol to make it
unique, and then use an at_exit() call to delete it.
I suggest to have it settable in config.h-vms[.template].
That would hard code it to a specific name. Do you have a suggestion
for a such a name that will not collide with something a user has set
and could expect to be visible in a makefile?
This program wraps around the main() module, so either must be included
into main either implicitly, or with a /first_include feature.
As far as I see and coded it: no. The only reason to include code into
other code is when the included code has to access static
variables/functions of the "includer". As far as I see, that's not the case.
The original main function name needs to be changed so that the code can
wrap it. The wrapper code can reside anywhere, but should remain in its
own module so that it can be deployed to other projects with out editing.
I am not just doing one project, I am doing a whole suite of projects
and am reusing as much code as possible for the common issues.
If someone has defined /TMP to other than SYS$SCRATCH: then they will
probably be suprised if a GNU utility is not honoring it and still using
For DCL, I don't think so.
What ever is done, it needs to be documented in the readme.vms and
probably the gnu make manual as a VMS feature. As clear
To have it different under GNV will require a global variable to use as
a flag to be set if getenv("SHELL") returns a value, as I do think we
want to call gentenv("SHELL") every place GNV needs alternative behavior.
Again, I would want to make it settable in config.h-vms[.template].
Maybe it is necessary to create a config.h-gnv[.template], but I don't
know, yet. And yes, it needs to be documented.
Since there will only be one build procedure and one resulting binary,
there would not be two templates.
One of the main reasons for merging this fork back in is to get to one
The one binary where needed will check if it is running under a UNIX
shell or DCL and adjust its behavior as needed.
This is the way that Curl and Perl now work.
That way users do not have to track two implementations of the same
version of product.
On the other hand, P_temdir is defined in the recent version of stdio.h
as "SYS$SCRATCH:", so I'm not sure whether your change to use /tmp will
work. And it seems like the RTL engineers or whoever wrote stdio.h think
this is what developers/users expect.
That bug has been previously reported to HP. It actually will cause a
run-time error depending on the decc$feature settings. VMS format files
specifications can not be exposed as constants in the header file.
But the reality is that if someone sets the TMP: logical to something
other than SYS$SCRATCH:, they may not find some of their temporary files
in TMP: and some in SYS$SCRATCH:, and I think that needs to be noted in
the VMS specific documentation of the application, as it will not be
After all there very well could be cases where the CRTL is using /tmp
instead of sys$scratch because it implemented the automatic conversion.
I prefer to have all vms specific code in the existing vms sources,
vmsfunctions.c may be the one for the new code.
I would prefer multiple modules, so that they can be re-used between
other projects. A vmsfunctions.c could #include these modules.
The reason I want to use existing ones is simple: I don't want to add so
many vms specific source files. But if there will be a config.h-gnv,
then there may be [a] gnv specific source[s] as well. Anyway, this is
still GNU make and not VMS make :-)
I am already expecting that a [.vms] directory will be needed to contain
at the minimum, the files needed for building the PCSI kit.
There are already directories for other platforms.
As already said, I try to move the code and will post that as a
suggestion this weekend.
Then I will try to come up with fixes to some of the test failures.
- vms argv and exit status fixes., John E. Malmberg, 2014/03/05
- Re: vms argv and exit status fixes., h.becker, 2014/03/05
- Re: vms argv and exit status fixes., John E. Malmberg, 2014/03/06
- Re: vms argv and exit status fixes., h.becker, 2014/03/06
- Re: vms argv and exit status fixes., John E. Malmberg, 2014/03/07
- Re: vms argv and exit status fixes., h.becker, 2014/03/08
- Re: vms argv and exit status fixes.,
John E. Malmberg <=
- VMS exit status fixes., John E. Malmberg, 2014/03/08
- Re: vms argv and exit status fixes., h.becker, 2014/03/10
- Re: vms argv and exit status fixes., John E. Malmberg, 2014/03/10
- Re: vms argv and exit status fixes., h.becker, 2014/03/11
- Re: vms argv and exit status fixes., h.becker, 2014/03/24
- Re: vms argv and exit status fixes., John E. Malmberg, 2014/03/25
- Re: vms argv and exit status fixes., h.becker, 2014/03/25