Re: vms argv[0] and exit status fixes.

[John E. Malmberg]

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
> code).

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 
compile time.

> > 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
> > > > SYS$SCRATCH:
> > >
> > > 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 
make binary.

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 
obvious.

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.

Regards,
-John