Re: #include behavior
- From: Yevgen Muntyan <muntyan.removethis@xxxxxxxx>
- Date: Sat, 24 Feb 2007 00:00:11 GMT
Keith Thompson wrote:
Beej Jorgensen <beej@xxxxxxx> writes:In article <lntzxcabmx.fsf@xxxxxxxxxxxxxxx>,[...]
Keith Thompson <kst-u@xxxxxxx> wrote:
Hmmm. That wasn't my read... Elaborate.7.1.2 paragraph 3:Interesting. That says that if I place a "stdlib.h" file in one of
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.
the places searched for a
#include "stdlib.h"
directive but *not* for a
#include <stdlib.h>
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
.
- Follow-Ups:
- Re: #include behavior
- From: Keith Thompson
- Re: #include behavior
- References:
- Re: Automatically generate variables
- From: Mark McIntyre
- Re: Automatically generate variables
- From: Mark McIntyre
- Re: Automatically generate variables
- From: Beej Jorgensen
- Re: Automatically generate variables
- From: Keith Thompson
- Re: #include behavior (was: Automatically generate variables)
- From: Beej Jorgensen
- Re: #include behavior (was: Automatically generate variables)
- From: Keith Thompson
- Re: Automatically generate variables
- Prev by Date: Re: Structure Pointer
- Next by Date: Re: string splitting
- Previous by thread: Re: #include behavior (was: Automatically generate variables)
- Next by thread: Re: #include behavior
- Index(es):
Relevant Pages
|