[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: vms argv[0] and exit status fixes.
From: |
h.becker |
Subject: |
Re: vms argv[0] and exit status fixes. |
Date: |
Sat, 08 Mar 2014 13:15:46 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130519 Icedove/17.0.5 |
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).
> 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.
> 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].
> 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.
>>> 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.
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.
>> 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 :-)
As already said, I try to move the code and will post that as a
suggestion this weekend.
- vms argv[0] and exit status fixes., John E. Malmberg, 2014/03/05
- Re: vms argv[0] and exit status fixes., h.becker, 2014/03/05
- Re: vms argv[0] and exit status fixes., John E. Malmberg, 2014/03/06
- Re: vms argv[0] and exit status fixes., h.becker, 2014/03/06
- Re: vms argv[0] and exit status fixes., John E. Malmberg, 2014/03/07
- Re: vms argv[0] and exit status fixes.,
h.becker <=
- Re: vms argv[0] and exit status fixes., John E. Malmberg, 2014/03/08
- VMS exit status fixes., John E. Malmberg, 2014/03/08
- Re: vms argv[0] and exit status fixes., h.becker, 2014/03/10
- Re: vms argv[0] and exit status fixes., John E. Malmberg, 2014/03/10
- Re: vms argv[0] and exit status fixes., h.becker, 2014/03/11
- Re: vms argv[0] and exit status fixes., h.becker, 2014/03/24
- Re: vms argv[0] and exit status fixes., John E. Malmberg, 2014/03/25
- Re: vms argv[0] and exit status fixes., h.becker, 2014/03/25