[Info-vax] C compiler snag

[John Reagan]

On Friday, May 21, 2021 at 9:25:44 AM UTC-4, John E. Malmberg wrote:
> On 5/19/2021 9:06 AM, John Reagan wrote: 
> > On Wednesday, May 19, 2021 at 8:50:32 AM UTC-4, John E. Malmberg wrote: 
> >> On 5/19/2021 4:51 AM, Richard Levitte wrote: 
> >>> Hey folks, 
> >>> 
> >>> it's been long since I've been present here... been all busy with 
> >>> OpenSSL, not much time for something else. 
> >> <snip> 
> >>> 
> >>> ----- 
> >>> $ cc humpf.c 
> >>> 
> >>> #include "../something.h" 
> >>> .^ 
> >>> %CC-F-NOINCLFILEF, Cannot find file "../something.h" specified in #include directive. 
> >>> at line number 1 in file USER:[LEVITTE.TEST.CC-INCL-2.INCL]h.h;1 
> >>> ----- 
> >>> 
> >>> So my question is, is there any trick that I can do with the compiler 
> >>> to make this go through without error? i would rather not have to 
> >>> restructure the inclusion if I can. 
> >> Only solution that I have found is to run a pre-build script to find and 
> >> re-edit the source code to change "../" to path or a logical name. 
> >> 
> >> I don't thing that is ever going to get fixed in the Alpha/IA64 compilers. 
> >> 
> >> Regards, 
> >> -John 
> > I doubt the compilers are at fault. At somepoint, we give that filespec to the CRTL's open/fopen. 
> > 
> > Relative filespecs are controlled by various DECC$ feature logicals <insert ugly comment here>. 
> > DECC$POSIX_COMPLIANT_PATHNAMES might help but setting that the DCL prompt before the 
> > compilation might be too big of a hammer as some code <insert 2nd ugly comment here>. 
> > 
> > I have the same issue with some of the files in LLVM that use relative filespecs.
> The C compiler seems to isolate it self, and ignores most of the DECC$ 
> feature logical settings that I have tried. 
> 
> I will have to add some tests to gnulib-assist to see if I can duplicate 
> the exact problem, but for that I need to know what exactly the 
> compilers are passing to the CRTL. 
> 
> By itself, the CRTL seems to handle most of the the "../" cases for path 
> to a filename. 
> 
> The compiler however is doing some extra stuff with processing the 
> directory found in a header file depending on the options set for the 
> compiler on the command line (And possibly #pragmas) 
> 
> And I have demonstrated that the Compiler handling of filenames is 
> different than the CRTL in that the <net/xxxx.h> headers in the text 
> library can not be accessed by the compiler if decnet is running. 
> 
> The CRTL does does not have a issue with converting "net/xxx.h" to 
> [.net]xxx.h for finding files. Only the C Compiler treats "net/xxx.h" 
> as net:xxx.h and then fails the compile, very similar to the ".." failure. 
> 
> The behavior that I see: 
> 
> If the directory is present in the specification and is a logical name, 
> that logical name is used. CRTL feature settings do not appear to 
> affect this for the C compiler, but do affect it for user programs. 
> 
> Depending on the compiler settings, if a directory is present in the 
> specification and exists in the source code, then the header will be 
> used from that directory instead of the OpenVMS text libraries, except 
> if the directory is specified as "..". 
> 
> The case of ".." is a case where this does not work, and I can not 
> reproduce this failure with just test programs on the CRTL, regardless 
> of the feature settings. 
> 
> If the directory is present and is not ".." and does not exist, it 
> discards it and uses the OpenVMS text libraries for the headers. This 
> has turned out to be a very useful feature to insure that my code 
> includes the OpenVMS header file instead of a file with the same name 
> used by a project. (Pretty common in open source porting) 
> 
> Either way the current behavior of the compiler is incorrect. If it is 
> in the CRTL, then it is bug and should get fixed there, otherwise it 
> should get fixed or worked around in the compiler, just like the 
> handling of the decnet NET: device needs to get fixed in the compiler. 
> 
> Regards, 
> -John
I'll do more research but there is nothing of your description that matches what
I know.  There is some GEM code mixed in as well.  I don't see the C compiler (or
the C++) compiler doing anything to avoid DECC$ logicals.  For example, turn on
DECC$POSIX_COMPLIANT_PATHNAMES and watch the compiler not able to find
.TLB files, etc.