[Info-vax] C compiler snag

[John E. Malmberg]

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