How to print "\n" or '\0'

[Harald van =?UTF-8?B?RMSzaw==?=]

Keith Thompson wrote:
[...]
Using the <...> form *for the standard headers* cannot go wrong.
Using the "..." form can go wrong if there happens to be a file named
"stdio.h" (or with whatever name the implementation maps "stdio.h" to)
anywhere in some set of directories that varies from one
implementation to another.

Using the <...> form for the standard headers can also go wrong in
almost the same situations, except worse as far as the standard is
concerned. If a file named stdio.h exists in any of the standard
locations when <stdio.h> is included, the behaviour is undefined. In
practice, many implementations will happily include the user header.

This kind of error can occur only if the implementation is broken
(non-conforming). If the implementation is broken, then you can't
assume *anything*. There may be good reasons to work around specific
breakages, but they're rare in my experience.

No, the implementation does not have to be non-conforming for this to
happen. The standard locations may include project-specific locations,
and often do (depending on user configuration).

Hmm. Here's what C99 7.1.2 says:

p2 The standard headers are
[list deleted]

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

"Places" refers only to locations for the #include <...> forms, not for the
#include "..." forms. 6.10.2 says that <...> searches in a sequence of
implementation-defined places, and that "..." searches in an
implementation-defined manner.

[...]

For the standard headers (the ones listed in C99 7.1.2), I advise
everyone to use the <...> form, always. If that doesn't work, it's
because the implementation is broken; there's no reason to think that
using "..." will unbreak it.

Similarly, if the "..." form doesn't work, it's because the implementation
is broken, and there is no reason to think that using <...> will unbreak
it. When there is no possibility of a user header, the two forms are
equivalent, which means the only differences are stylistic. I've stated

The very few people who are
knowledgeable enough to replace chunks of their implementation will
know that my advice doesn't apply to them.

True. In most cases, the difference won't matter, so there's no reason /for/
using the "..." form for standard headers.

 

[Keith Thompson]

huh. You appear to be claiming that a standard-conforming implementation
doesn't allow a user to have his own header for <stdio.h>.

I'm afraid I don't recall seeing any that enforce that.

[...]

The standard appears to say that replacing the stdio.h header invokes
undefined behavior (I'm not 100% sure of my interpretation). I've
quoted the relevant section of the standard elsewhere in this thread.
An implementation is not required to detect or enforce this; that's
what "undefined behavior" means.

 

[Keith Thompson]

Keith Thompson wrote:
Keith Thompson wrote:
[...]
Using the <...> form *for the standard headers* cannot go wrong.
Using the "..." form can go wrong if there happens to be a file named
"stdio.h" (or with whatever name the implementation maps "stdio.h" to)
anywhere in some set of directories that varies from one
implementation to another.

Using the <...> form for the standard headers can also go wrong in
almost the same situations, except worse as far as the standard is
concerned. If a file named stdio.h exists in any of the standard
locations when <stdio.h> is included, the behaviour is undefined. In
practice, many implementations will happily include the user header.

This kind of error can occur only if the implementation is broken
(non-conforming). If the implementation is broken, then you can't
assume *anything*. There may be good reasons to work around specific
breakages, but they're rare in my experience.

No, the implementation does not have to be non-conforming for this to
happen. The standard locations may include project-specific locations,
and often do (depending on user configuration).

Hmm. Here's what C99 7.1.2 says:

p2 The standard headers are
[list deleted]

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

"Places" refers only to locations for the #include <...> forms, not for the
#include "..." forms. 6.10.2 says that <...> searches in a sequence of
implementation-defined places, and that "..." searches in an
implementation-defined manner.

Interesting. That's a plausible argument, and IMHO it causes the
statement to make more sense than it would otherwise, but I'm not
comfortable with this interpretation depending on the fact that
6.10.2p2 uses the word "places" and 6.20.2p3 doesn't.

[...]

True. In most cases, the difference won't matter, so there's no
reason /for/ using the "..." form for standard headers.

Precisely my point.