Re: #include "string.h"

kuyper@xxxxxxxxxx wrote:
Yevgen Muntyan wrote:
kuyper@xxxxxxxxxx wrote:
On Mar 7, 9:07 pm, Yevgen Muntyan <muntyan.removet...@xxxxxxxx> wrote:
...
if I have a program, with my own header string.h (not standard
header replacement, just some silly string functions) [1], and a
source file which contains

#include "string.h"

in the same directory as string.h, then is it UB?
7.1.2p3 is specifically about #include <header.h>, not #include
"header.h".
It doesn't talk about #include directive at all, does it?

My apologies; I looked only at your citation of 7.1.2p3, and I forgot
the context of that citation. 7.1.2p3 does apparently apply, whether
or not your program contains even a single #include statement. That
doesn't fit my mental model of how unexpected behavior could actually
happen; but that's what it says, so my mental model needs adjusting. I
apologize for the misinformation.

Even if it's only about programs with #include directives, it won't
change much, since any program does use some standard headers anyway.
And then if you have #include <string.h>, it's natural if implementation
won't like your custom string.h. But, why is it UB (or is it?)
if you put string.h into the folder next to the source file,
and use #include "string.h"? Say, elsethread it was said it's a
good practice to use #include "string.h" instead of
#include <string.h> so one can override string.h (for portability
reasons). Is this practice actually a practice of relying on UB
which is de-facto well-defined in all implementations out there?

...
Here you describe the difference between #include <name> and
#include "filename". But the distinction I said about is
between *words* "headers" and "source files". In chapter 6.10
it's important (or not so important really since source files
may be not files just as standard headers), but perhaps it's not
outside that chapter, since the whole 6.10 is called "Source file
inclusion", not "Source file inclusion and headers" or something.
Given that these are not terms defined somewhere in the standard,
we can expect wording sloppiness (I think of it as "human language")

When a word appears in italics in the standard, it indicates that the
text containing that word should be considered as implicitly defining
the term. For "source files", this occurs in 5.1.1.1p1. For "header",
this occurs in 7.1.2p1. Footnote 142 clearly states a fact that can
(less clearly) be derived from those definitions: a header doesn't
have to be a source file.

Indeed, you're right. But here's another thing: it uses word "headers"
*only* for standard headers. For instance, if you have
#include <regex.h>, then 6.10.2p2 says it's UB (or rather it doesn't
say what it means, which is why it's UB)? I believe "headers" means
more than what it's talked about in 7.1.2p1 (or the intent for it
was to mean more, something like that). In other words, the standard is
not strict in all uses of word "header".

there, here, or in both places. I.e. I doubt that from "places that are
searched for included source files" we can make a conclusion it's
exactly about Q-places. Or can we?

I don't see adequate justification for your doubt.

Yes, as I read it now, "places that are searched for included source
files" sounds clear. But then again there is that "standard", which
I snipped.

And of course there are no "standard places" at all.
There are standard places, they're just implementation-defined.
In particular, there may be no standard places at all. In
any case, "standard" is tricky word here. One could say
everything in the standard is standard (or everything which
is not implementation-defined or undefined, but then it's
not Q-places).

In this context, the term "standard" can't refer to the C standard
itself, because the C standard does not specify those places; it must
be meant in a less specific sense: the search locations that are
standard for that implementation.

Well, this is the point. If you do #include "foo.h", implementations
usually look at the current directory or directory where source file is
located. It's hardly a "standard place"; while e.g. /usr/include really
is a standard place on unix implementations.

It's been argued that an implementation must actually provide at least
one such place. I'm not so sure that conclusion is valid. I think that
the argument used depended too much upon the intent of the authors of
the standard, and not enough on the actual words of the standard.

It's impossible to write programs without non-standard headers, so it's
not so important. The intent certainly was to allow people to write
C files and H files :)

Best regards,
Yevgen
.

Relevant Pages

  • Re: #include "string.h"
    ... since any program does use some standard headers anyway. ... if you put string.h into the folder next to the source file, ... POSIX is another. ...
    (comp.std.c)
  • Re: Forth Go Program
    ... Does anyone have a tool for converting ANS keywords to uppercase ... Nor do I desire to uppercase the code. ... and to define all standard names in upper case. ... or Ruby which would post process your source file. ...
    (comp.lang.forth)
  • Re: #include "string.h"
    ... since the whole 6.10 is called "Source file ... Given that these are not terms defined somewhere in the standard, ... a header doesn't ... exactly about Q-places. ...
    (comp.std.c)
  • Re: Forth Go Program
    ... Does anyone have a tool for converting ANS keywords to uppercase ... and to define all standard names in upper case. ... Except if you go a long list of words, a quick approach (say up to one to two thousand words¹, would be to write a script in AWK, Perl, Python or Ruby which would post process your source file. ... So this would be not the issue, I think, it may become a second style decision as it will be the school willing the words to be uppercase in comments and some are used in ordinary English, and then that requires a very advanced semantic analysis to a short script to chew;-) ...
    (comp.lang.forth)
  • Re: Sleeping or waiting
    ... delimited sequence and the external source file name. ... by a period and a single letter. ... standard wisely didn't take advantage of that. ... C99 increases the limit to eight significant characters ...
    (comp.lang.c)
Loading