Re: #include behavior



Keith Thompson wrote:
Beej Jorgensen <beej@xxxxxxx> writes:
In article <lntzxcabmx.fsf@xxxxxxxxxxxxxxx>,
Keith Thompson <kst-u@xxxxxxx> wrote:
7.1.2 paragraph 3:
If a file with the same name as one of the above < and > delimited
sequences, not provided as part of the implementation, is placed in
any of the standard places that are searched for included source
files, the behavior is undefined.
Interesting. That says that if I place a "stdlib.h" file in one of
the places searched for a
#include "stdlib.h"
directive but *not* for a
#include <stdlib.h>
Hmmm. That wasn't my read... Elaborate.

Why not for <stdlib.h>, especially since "" is a "superset" (so to
speak) of <>?
[...]

Sorry, the scope of the "*not*" was unclear.

Suppose the compiler searches for <foo.h> in /usr/include, and for
"foo.h" in $HOME/include and then /usr/include (these are just
arbitrary examples). 7.1.2p3, as I read it, says that if I place a
"stdlib.h" file in $HOME/include (which, as I wrote above, is one of
the places searched for "stdlib.h", but not one of the places searched
for <stdlib.h>), then the behavior is undefined.

If I place a "stdlib.h" file in /usr/include, of course, it also
causes UB.

Given that the whole include business is implementation-defined,
7.1.2.3 is rather just an additional "don't mess with implementation"
hint. Especially given that the standard doesn't require the very
possibility to place a source file into some place. From the other
hand, programs having "string.h" header do exists, even the alive
supported ones.

And I just noticed that 7.1.2p3 talks about "a file with the same
name", which ignores the mapping specified by 6.10.2. In 6.10.2,
it says that <foo.h> refers to

a header identified uniquely by the specified sequence between the
< and > delimiters

whereas "foo.h" refers to

the source file identified by the specified sequence between the "
delimiter

What does "identified by" mean here? Is "foo.h" actually the *name*
of the file (as would be accepted by fopen(), or is it subject to the
same mapping as <foo.h>?

It means the latter (not *the same* though), since the standard simply
doesn't talk about files at all, i.e. it doesn't say source files should
be "real" files on disk (you know, those bizarre implementations where
there is no disk and files or which use database or streams or
anything). fopen() is irrelevant since it's what happens on the target
system in compiled program, not what compiler does.
The mapping may or may not be the same as for <foo.h> (and it
isn't in practice with at least one popular compiler, and it must
not be the same according to the common practice of "yours.h" and
<system.h>).

But 7.10.2.3 doesn't ignore 6.10.2. It just uses human language,
it says exactly what it says: "you put stdlib.h into one of those
places and you get UB", even though it doesn't define what it means
to put a source file into some place. It's not the only place where it
talks humanish, isn't it?

Yevgen
.



Relevant Pages

  • Re: #include behavior
    ... possibility to place a source file into some place. ... which ignores the mapping specified by 6.10.2. ... the source file identified by the specified sequence between the ...
    (comp.lang.c)
  • Re: Preprocessor includes, difference between quote and lt/gt
    ... header identified uniquely by the specified sequence between ... causes the replacement of that directive by the entire ... contents of the source file identified by the specified ... sequence between the " delimiters. ...
    (comp.lang.c)
  • Re: right sequence of included module files
    ... When more module files use other module, ... I usually have to decide very carefully the sequence of the included ... compiler processes program units sequentially in the source, ... USE A earlier in the source file that defines module A, ...
    (comp.lang.fortran)
  • Re: Mail Merge Table keeps Resorting itself
    ... Word gets the sequence you want ... select Tools / Letters & Mailings / Mail Merge which opens up a step by step ... >> If the problem is with your your mailmerge source file, after>> switching the fields around in that file, did you save the changes? ...
    (microsoft.public.word.docmanagement)
  • Re: Hello
    ... VR of this tag and "00 E0" has to be the length of the value that ... sequence of items, where sequence and item have unknown length. ... The delimiters look like tags and have a lengh as well. ...
    (comp.protocols.dicom)