Discussion:
C compiler snag
Add Reply
Richard Levitte
2021-05-19 09:51:22 UTC
Reply
Permalink
Hey folks,

it's been long since I've been present here... been all busy with OpenSSL, not much time for something else.

Now, speaking of OpenSSL, I'm hitting an "interesting" snag that I can't seem to find a good solution for. It's easy to demonstrate, with this set of files:

humpf.c
[.incl]h.h
something.h

----- humpf.c
#include "./incl/h.h"

int main()
{
}
-----

----- [.incl]h.h
#include "../something.h"
-----

----- something.h
int foo(void);
-----

The content of those files isn't terribly interesting, but the inclusion sequence is, i.e. humpf.c includes "./incl/h.h" includes "../something.h". Structures like this may seem strange, but they do exist. So now for the snag:

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

Version data:

(alpha) $ cc/version
VSI C V7.4-002 on OpenVMS Alpha V8.4-2L2

(itanium) $ cc/version
VSI C V7.4-001 on OpenVMS IA64 V8.4-2L1
Craig A. Berry
2021-05-19 11:57:06 UTC
Reply
Permalink
Post by Richard Levitte
Hey folks,
it's been long since I've been present here... been all busy with
OpenSSL, not much time for something else.
Now, speaking of OpenSSL, I'm hitting an "interesting" snag that I
can't seem to find a good solution for. It's easy to demonstrate, with
humpf.c
[.incl]h.h
something.h
----- humpf.c
#include "./incl/h.h"
int main()
{
}
-----
----- [.incl]h.h
#include "../something.h"
-----
----- something.h
int foo(void);
-----
-----
$ 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.
Have you tried specifying the current working directory in Unix format
on the command line:
cc/include="./" humpf.c

?

I think I remember something like that being necessary for some
situation, but I'm not sure if it was this situation exactly.

Other than that, SET WATCH FILE is your friend for figuring out where
exactly the compiler is looking for the file it can't find.
Post by Richard Levitte
(alpha) $ cc/version
VSI C V7.4-002 on OpenVMS Alpha V8.4-2L2
(itanium) $ cc/version
VSI C V7.4-001 on OpenVMS IA64 V8.4-2L1
Richard Whalen
2021-05-19 12:30:44 UTC
Reply
Permalink
Post by Craig A. Berry
Post by Richard Levitte
Hey folks,
it's been long since I've been present here... been all busy with
OpenSSL, not much time for something else.
Now, speaking of OpenSSL, I'm hitting an "interesting" snag that I
can't seem to find a good solution for. It's easy to demonstrate, with
humpf.c
[.incl]h.h
something.h
----- humpf.c
#include "./incl/h.h"
int main()
{
}
-----
----- [.incl]h.h
#include "../something.h"
-----
----- something.h
int foo(void);
-----
-----
$ 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.
Have you tried specifying the current working directory in Unix format
cc/include="./" humpf.c
?
I think I remember something like that being necessary for some
situation, but I'm not sure if it was this situation exactly.
Other than that, SET WATCH FILE is your friend for figuring out where
exactly the compiler is looking for the file it can't find.
Post by Richard Levitte
(alpha) $ cc/version
VSI C V7.4-002 on OpenVMS Alpha V8.4-2L2
(itanium) $ cc/version
VSI C V7.4-001 on OpenVMS IA64 V8.4-2L1
I think that you need to look at /NESTED_INCLUDE_DIRECTORY
Richard Levitte
2021-05-19 18:26:06 UTC
Reply
Permalink
Post by Richard Whalen
I think that you need to look at /NESTED_INCLUDE_DIRECTORY
That defaults to INCLUDE_FILE, which seems sensible.
David Jones
2021-05-19 12:46:24 UTC
Reply
Permalink
Post by Craig A. Berry
Have you tried specifying the current working directory in Unix format
cc/include="./" humpf.c
?
I think I remember something like that being necessary for some
situation, but I'm not sure if it was this situation exactly.
I replicated the problem, and got it work with
cc/include="./incl" humpf.c

Specifying various values of /nest_include made no difference.
Richard Levitte
2021-05-19 18:29:52 UTC
Reply
Permalink
Post by David Jones
I replicated the problem, and got it work with
cc/include="./incl" humpf.c
Ah! That actually makes sense, albeit a bit strangely. What I understand is that with this, "../something.h" will among others get to look at "./incl/../something.h", and that will find the header file in question.

Gotta admit, though, that it's a bit annoying having to do this sort of trick...

Anyway, thanks! This does help quite a bit.

Cheers,
Richard
Craig A. Berry
2021-05-19 18:30:05 UTC
Reply
Permalink
Post by David Jones
Post by Craig A. Berry
Have you tried specifying the current working directory in Unix format
cc/include="./" humpf.c
Nope, that doesn't work.
Post by David Jones
I replicated the problem, and got it work with
cc/include="./incl" humpf.c
That works for this made-up case but may not be general enough. It also
works because ./incl/../something.h is the same as ./something.h, and
the grandchild may not always be in the same location as the
grandparent. You could specify any subdirectory, even a nonexistent
one, and the result would be the same. For example, this works:

$ cc/include="./nosuchdir" humpf

A bit of poking with SET WATCH FILE/CLASS=ALL and DFU shows that the
first place the compiler looks for something.h when no include
directories are specified explicitly is the parent directory one level
up from where humpf.c is located. The next place it looks is relative
to the POSIX root but at that point it's already given up on finding it
relative to the program being compiled.

So the compiler is honoring the relative portion of the path, but it is
considering it relative to the grandparent .c file or the current
working directory of the compile operation (which are the same in this
case) and *not* relative to the file containing the #include directive
(h.h).

Whether this is a bug or a feature I don't know. But it is definitely
different from what other compilers do.
Post by David Jones
Specifying various values of /nest_include made no difference.
P.S. DFU was necessary because SET WATCH FILE gives you only the FID,
not the name, of the directory in a "Read only directory access"
message. So you have to take a message like this:

%XQP, Thread #0, Read only directory access (15599,12,0)

and find out what it is with:

$ mcr dfu search/fid=15599 dka7:

Disk and File Utilities for OpenVMS V3.2
%DFU-I-SEARCH, Start search on DKA7: ($2$DKA7:)

$2$DKA7:[000000]PSX$ROOT.DIR;1
1/16

%DFU-I-EOF, End of file INDEXF.SYS, Primary headers : 1

%DFU-S-FND , Files found : 1, Size : 1/16
John E. Malmberg
2021-05-19 12:50:49 UTC
Reply
Permalink
Post by Richard Levitte
Hey folks,
it's been long since I've been present here... been all busy with
OpenSSL, not much time for something else.
<snip>
Post by Richard Levitte
-----
$ 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
John Reagan
2021-05-19 14:06:10 UTC
Reply
Permalink
Post by John E. Malmberg
Post by Richard Levitte
Hey folks,
it's been long since I've been present here... been all busy with
OpenSSL, not much time for something else.
<snip>
Post by Richard Levitte
-----
$ 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.
Simon Clubley
2021-05-19 17:24:35 UTC
Reply
Permalink
Post by John Reagan
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.
That just means you don't have enough logicals to control behaviour, John.

You just need a few more logicals for extra configuration options. :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2021-05-19 21:57:20 UTC
Reply
Permalink
Post by Simon Clubley
Post by John Reagan
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.
That just means you don't have enough logicals to control behaviour, John.
You just need a few more logicals for extra configuration options. :-)
Simon.
Simon is now in big trouble with several people.

No, the smily isn't going to save you.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-05-19 23:12:11 UTC
Reply
Permalink
Post by Dave Froble
Post by Simon Clubley
Post by John Reagan
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.
That just means you don't have enough logicals to control behaviour, John.
You just need a few more logicals for extra configuration options. :-)
Simon.
Simon is now in big trouble with several people.
No, the smily isn't going to save you.
Well, it wouldn't be the first time that Simon has upset some people
around here. :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2021-05-19 23:41:47 UTC
Reply
Permalink
Post by Simon Clubley
Post by Dave Froble
Post by Simon Clubley
Post by John Reagan
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.
That just means you don't have enough logicals to control behaviour, John.
You just need a few more logicals for extra configuration options. :-)
Simon.
Simon is now in big trouble with several people.
No, the smily isn't going to save you.
Well, it wouldn't be the first time that Simon has upset some people
around here. :-)
You claiming to be a troll?

:-)
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-05-20 00:04:20 UTC
Reply
Permalink
Post by Dave Froble
Post by Simon Clubley
Post by Dave Froble
Post by Simon Clubley
Post by John Reagan
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.
That just means you don't have enough logicals to control behaviour, John.
You just need a few more logicals for extra configuration options. :-)
Simon.
Simon is now in big trouble with several people.
No, the smily isn't going to save you.
Well, it wouldn't be the first time that Simon has upset some people
around here. :-)
You claiming to be a troll?
:-)
No David. Just someone willing to speak some uncomfortable truths
when needed.

(However, the comment to John was a joke.)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
John E. Malmberg
2021-05-21 13:26:05 UTC
Reply
Permalink
Post by John Reagan
Post by John E. Malmberg
Post by Richard Levitte
Hey folks,
it's been long since I've been present here... been all busy with
OpenSSL, not much time for something else.
<snip>
Post by Richard Levitte
-----
$ 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
John Reagan
2021-05-21 14:34:49 UTC
Reply
Permalink
Post by John E. Malmberg
Post by John E. Malmberg
Post by Richard Levitte
Hey folks,
it's been long since I've been present here... been all busy with
OpenSSL, not much time for something else.
<snip>
Post by Richard Levitte
-----
$ 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.
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.
Simon Clubley
2021-05-21 17:42:56 UTC
Reply
Permalink
Post by John Reagan
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.
John is very right about this. There is a problem when you use net/
within an include statement. The following code compiles: !!!

---------------------------------------------------------------------------
$ type nettest.c
#include <stdio.h>
#include <net/does_not_exist.h>

int main(int argc, char *argv[])
{
printf("Testing net include\n");
return 0;
}
$ cc nettest.c
---------------------------------------------------------------------------

Change this to the following and you get the expected error:

---------------------------------------------------------------------------
$ type nettest.c
#include <stdio.h>
#include <net1/does_not_exist.h>

int main(int argc, char *argv[])
{
printf("Testing net include\n");
return 0;
}
$ cc nettest.c

#include <net1/does_not_exist.h>
.^
%CC-F-NOINCLFILEF, Cannot find file <net1/does_not_exist.h> specified in #includ
e directive.
---------------------------------------------------------------------------

$ cc/version
VSI C V7.4-002 on OpenVMS Alpha V8.4-2L2

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Simon Clubley
2021-05-21 17:46:28 UTC
Reply
Permalink
Post by Simon Clubley
Post by John Reagan
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.
John is very right about this. There is a problem when you use net/
within an include statement. The following code compiles: !!!
That is John Malmberg is right about this. Too many people called John
around here. :-)

Simon.
Post by Simon Clubley
---------------------------------------------------------------------------
$ type nettest.c
#include <stdio.h>
#include <net/does_not_exist.h>
int main(int argc, char *argv[])
{
printf("Testing net include\n");
return 0;
}
$ cc nettest.c
---------------------------------------------------------------------------
---------------------------------------------------------------------------
$ type nettest.c
#include <stdio.h>
#include <net1/does_not_exist.h>
int main(int argc, char *argv[])
{
printf("Testing net include\n");
return 0;
}
$ cc nettest.c
#include <net1/does_not_exist.h>
.^
%CC-F-NOINCLFILEF, Cannot find file <net1/does_not_exist.h> specified in #includ
e directive.
---------------------------------------------------------------------------
$ cc/version
VSI C V7.4-002 on OpenVMS Alpha V8.4-2L2
Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
John E. Malmberg
2021-05-22 00:19:07 UTC
Reply
Permalink
Post by Simon Clubley
Post by Simon Clubley
Post by John Reagan
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.
John is very right about this. There is a problem when you use net/
within an include statement. The following code compiles: !!!
That is John Malmberg is right about this. Too many people called John
around here. :-)
Wrong reproducer. The bug demonstrated in the GNV gnulib_assist self test.

The bug only trips for me with decnet phase IV running which creates a
NET0: device.

type [.vms]test_vms_if_h.c
#ifdef VMS_CRTL
#include <net/if.h>
#else
#include "vms/if.h"
#endif
#pragma assert_m non_zero(__IF_LOADED) "if.h did not get loaded."

Note, I have not tested the fragments posted here.

$ cdef = VMS_CRTL=1"
$ define/user decc$user_include "sys$disk:[.vms]"
$ CC/define=('cdef')'psize''cfloat''cinc'/noobj -
[.vms]test_vms_stdio_h.c


The <net/if.h> is a standard header file used in network programming in C.

You simply can not compile that source if DECNET phase IV is running.
Not sure about Phase V, yanked that out a while back.

I will be posting an update to the gnulib_assist sometime this weekend
after which all the things I have tests for will pass.

Current checked in code has a bug where it is skipping some tests and
the rename wrappers to generate correct rename behavior is not implemented.

Regards,
-John

Craig A. Berry
2021-05-21 19:30:22 UTC
Reply
Permalink
Post by Simon Clubley
There is a problem when you use net/
within an include statement. The following code compiles: !!!
---------------------------------------------------------------------------
$ type nettest.c
#include <stdio.h>
#include <net/does_not_exist.h>
int main(int argc, char *argv[])
{
printf("Testing net include\n");
return 0;
}
$ cc nettest.c
---------------------------------------------------------------------------
Bug or feature I don't know, but again it seems to have nothing to do
with the compiler. Opening a non-existent file on the net: device
returns success. What you expect from opening a non-existent file:

$ perl -e "open my $f, '<', 'nosuchfile.dat' or die $^E;"
%RMS-E-FNF, file not found at -e line 1.
%SYSTEM-F-ABORT, abort

What you get when you prepend "net:" to the filename:

$ perl -e "open my $f, '<', 'net:nosuchfile.dat' or die $^E;"
$ show symbol $status
$STATUS == "%X00000001"

Note that you can't reproduce this with DCL:

$ open f net:nosuchfile.dat
%DCL-E-INVRFM, invalid record format for record I/O - file not opened

So the compiler is just converting net/does_not_exist.h to VMS syntax
net:does_not_exist.h and getting a successful open but nothing happens
when you read from it (except EOF I guess). The filename portion
doesn't matter and seems to be ignored. As far as I can tell, the
behavior is identical to that of _NLA0:.

The compiler could also be led astray by:

#include "nl/foo.h"
Simon Clubley
2021-05-21 21:13:27 UTC
Reply
Permalink
Post by Craig A. Berry
Post by Simon Clubley
There is a problem when you use net/
within an include statement. The following code compiles: !!!
---------------------------------------------------------------------------
$ type nettest.c
#include <stdio.h>
#include <net/does_not_exist.h>
int main(int argc, char *argv[])
{
printf("Testing net include\n");
return 0;
}
$ cc nettest.c
---------------------------------------------------------------------------
Bug or feature I don't know, but again it seems to have nothing to do
with the compiler. Opening a non-existent file on the net: device
I'm not so sure. Based on what has been said so far, I think this
is a compiler specific problem.

I think John Malmberg is right and that the compiler is wrongly
looking for a device (NET:) with the name of the net/ include directory
and using that instead of looking for a [.net] directory.
Post by Craig A. Berry
So the compiler is just converting net/does_not_exist.h to VMS syntax
net:does_not_exist.h and getting a successful open but nothing happens
when you read from it (except EOF I guess). The filename portion
doesn't matter and seems to be ignored. As far as I can tell, the
behavior is identical to that of _NLA0:.
That's my understanding as well. What it should be doing instead is
looking for [.net]does_not_exist.h and then reporting an error when
it doesn't find the file in that location.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Craig A. Berry
2021-05-21 22:47:51 UTC
Reply
Permalink
Post by Simon Clubley
Post by Craig A. Berry
Post by Simon Clubley
There is a problem when you use net/
within an include statement. The following code compiles: !!!
---------------------------------------------------------------------------
$ type nettest.c
#include <stdio.h>
#include <net/does_not_exist.h>
int main(int argc, char *argv[])
{
printf("Testing net include\n");
return 0;
}
$ cc nettest.c
---------------------------------------------------------------------------
Bug or feature I don't know, but again it seems to have nothing to do
with the compiler. Opening a non-existent file on the net: device
I'm not so sure. Based on what has been said so far, I think this
is a compiler specific problem.
I think John Malmberg is right and that the compiler is wrongly
looking for a device (NET:) with the name of the net/ include directory
and using that instead of looking for a [.net] directory.
I think John M is right that something goes wrong, but it's not clear to
me how much, if any, is the compiler's fault and how much is just how
things fall out from all the different special devices.

The compiler would have to have some special handling of prefixes such
as "sys/" and "net/" in order to look things up in
sys$library:decc$rtldef.tlb because a text library is just a key lookup
and there is no nesting. But the fact that the "nl/" prefix shows the
exact same behavior as the "net/" prefix suggests that this isn't the
problem, because /usr/include/nl is not a location that needs to be
emulated in the same way that /usr/include/sys and /usr/include/net do.
Post by Simon Clubley
Post by Craig A. Berry
So the compiler is just converting net/does_not_exist.h to VMS syntax
net:does_not_exist.h and getting a successful open but nothing happens
when you read from it (except EOF I guess). The filename portion
doesn't matter and seems to be ignored. As far as I can tell, the
behavior is identical to that of _NLA0:.
That's my understanding as well. What it should be doing instead is
looking for [.net]does_not_exist.h and then reporting an error when
it doesn't find the file in that location.
That's the expected behavior for the source code on a Unix system, but
on VMS that's not necessarily correct behavior if "net" is a device name
or a logical name. The logical name case can be suppressed with
DECC$DISABLE_TO_VMS_LOGNAME_TRANSLATION -- you'll probably have to do
that if you have a 'sys" logical name defined.

It does seem possible the compiler is cutting off the prefix and testing
it as a device. That would explain why the following two tests behave
identically:

#include "net/nosuchfile.dat"
#include "nl/nosuchfile.dat"

This one is interesting:

#include "tt/nosuchfile.dat"

It will hang waiting for input from your terminal.
Craig A. Berry
2021-05-21 16:01:14 UTC
Reply
Permalink
Post by John E. Malmberg
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.
You seem to have missed my analysis showing that ../ does work but the
question about handling relative paths is relative to what? As far as I
can find, there is no standard and how this is handled is
implementation-defined. Most compilers seem to specify that it's
relative to the file in which the #include directive is found. The VMS
compiler doesn't do that but looks for the header relative to either the
top-level compilation unit or the current working directory from which
the compile command was run. The two were one and the same in the
example originally posted, so it's impossible to know which without
further analysis (or reading the compiler sources, which I don't have).
Loading...