By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,263 Members | 2,640 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,263 IT Pros & Developers. It's quick & easy.

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

P: n/a
please help. thanks.

May 26 '07 #1
Share this Question
Share on Google+
45 Replies


P: n/a
you're welcome
May 26 '07 #2

P: n/a

"Umesh" <fr****************@gmail.comha scritto nel messaggio
news:11**********************@a26g2000pre.googlegr oups.com...
please help. thanks.
To print a newline, simplily use putchar('\n');
I can't imagine why you want to print a null character, but
putchar(0) should work.
May 26 '07 #3

P: n/a
Umesh <fr****************@gmail.comwrote:
please help. thanks.
I would like to, but:

1) please put your question into the body of your posting,
2) please phrase your question in a way that it makes some
sense.
How to print "\n" or '\0'
doesn't.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
May 26 '07 #4

P: n/a
"Umesh"
please help. thanks.
Are you purposely being dense? Haven't you been told to post your question
in the body of your message?

WRT the '\0'. That stand for null - note the lower case spelling - it's an
ordinary English word. Now look up null.

http://www.answers.com/null&r=67

Pay particular attention to definitions 3 and 4. Now how does one represent
nothing? Difficult isn't it? Perhaps you want to learn about the
hexadecimal representation of numbers. Look at the format specifier "%x".
May 26 '07 #5

P: n/a
//how to print "\n" or '\0'

#include"stdio.h"
int main()
{
printf("\\n");
printf("\n");
printf("'\\0'");
return 0;
}

May 26 '07 #6

P: n/a

"Jens Thoms Toerring" <jt@toerring.dewrote in message
news:5b*************@mid.uni-berlin.de...
Umesh <fr****************@gmail.comwrote:
>please help. thanks.

I would like to, but:

1) please put your question into the body of your posting,
2) please phrase your question in a way that it makes some
sense.
How to print "\n" or '\0'
doesn't.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
I'm amazed that only one person answered the question, while the rest of you
were overly concerned about specific structuring of the body of his post and
specific requirements for the wording.
May 26 '07 #7

P: n/a
Eigenvector wrote:
"Jens Thoms Toerring" <jt@toerring.dewrote in message
news:5b*************@mid.uni-berlin.de...
>Umesh <fr****************@gmail.comwrote:
>>please help. thanks.
I would like to, but:

1) please put your question into the body of your posting,
2) please phrase your question in a way that it makes some
sense.
How to print "\n" or '\0'
doesn't.

I'm amazed that only one person answered the question, while the rest of you
were overly concerned about specific structuring of the body of his post and
specific requirements for the wording.
The OP is building quite a reputation for idiotic posts and ignoring advice.

--
Ian Collins.
May 26 '07 #8

P: n/a
Eigenvector said:

<snip>
I'm amazed that only one person answered the question, while the rest
of you were overly concerned about specific structuring of the body of
his post and specific requirements for the wording.
I'm astounded that anyone answered his question at all. I'd have thought
he'd be in everyone's killfiles by now.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
May 26 '07 #9

P: n/a
Ian Collins wrote:
Eigenvector wrote:
>"Jens Thoms Toerring" <jt@toerring.dewrote in message
news:5b*************@mid.uni-berlin.de...
>>Umesh <fr****************@gmail.comwrote:
please help. thanks.
I would like to, but:

1) please put your question into the body of your posting,
2) please phrase your question in a way that it makes some
sense.
How to print "\n" or '\0'
doesn't.
I'm amazed that only one person answered the question, while the rest of you
were overly concerned about specific structuring of the body of his post and
specific requirements for the wording.
The OP is building quite a reputation for idiotic posts and ignoring advice.
Not to mention that the one person answered only one of the many
possible interpretations of the question. Which is more helpful,
answering the wrong question, or asking for clarification?
--
clvrmnky <mailto:sp******@clevermonkey.org>

Direct replies will be blacklisted. Replace "spamtrap" with my name to
contact me directly.
May 28 '07 #10

P: n/a
Groovy hepcat Umesh was jivin' on 26 May 2007 09:25:29 -0700 in
comp.lang.c.
Re: How to print "\n" or '\0''s a cool scene! Dig it!
>//how to print "\n" or '\0'

#include"stdio.h"
Now, I know you know better than that, Umesh. You must be trolling,
I think. The only explanation I can think of for your baffling
behaviour is that you are a troll.
That said, the only reason I'm responding to a troll is to encourage
others to ignore Umesh, and all trolls. Killfile the fool.

--

Dig the even newer still, yet more improved, sig!

http://alphalink.com.au/~phaywood/
"Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker.
I know it's not "technically correct" English; but since when was rock & roll "technically correct"?
May 29 '07 #11

P: n/a
Peter 'Shaggy' Haywood wrote:
Groovy hepcat Umesh was jivin' on 26 May 2007 09:25:29 -0700 in
comp.lang.c.
Re: How to print "\n" or '\0''s a cool scene! Dig it!
>>//how to print "\n" or '\0'

#include"stdio.h"

Now, I know you know better than that, Umesh. You must be trolling,
I think. The only explanation I can think of for your baffling
behaviour is that you are a troll.
That said, the only reason I'm responding to a troll is to encourage
others to ignore Umesh, and all trolls. Killfile the fool.
#include "stdio.h" is allowed in standard C. When #include "..." does not
pick up a file in the locations for user headers, it is replaced by the
compiler as if it read #include <...>.
May 29 '07 #12

P: n/a

"Harald van D?k" <tr*****@gmail.comha scritto nel messaggio
news:f3**********@news1.zwoll1.ov.home.nl...
Peter 'Shaggy' Haywood wrote:
>Groovy hepcat Umesh was jivin' on 26 May 2007 09:25:29 -0700 in
comp.lang.c.
Re: How to print "\n" or '\0''s a cool scene! Dig it!
>>>//how to print "\n" or '\0'

#include"stdio.h"

Now, I know you know better than that, Umesh. You must be trolling,
I think. The only explanation I can think of for your baffling
behaviour is that you are a troll.
That said, the only reason I'm responding to a troll is to encourage
others to ignore Umesh, and all trolls. Killfile the fool.

#include "stdio.h" is allowed in standard C. When #include "..." does not
pick up a file in the locations for user headers, it is replaced by the
compiler as if it read #include <...>.
I don't think Peter referred to that. Umesh asked a question which
can be misunderstood very easily, then, after being told how to
print a newline or a null character[1], he answered his question
himself, showing that what he was trying to do was printing a
backslash followed by a lowercase n, or an apostrophe followed by
a backslash followed by the digit 0 followed by another apostrophe,
a question which could be asked much less ambiguously as "how can I
print a backslash?".

[1]Not always meaningless. For example, if you freopen()ed stdout
as a binary file (or if you are working on a Unix-like system where
there is no real difference between binary and text), and are
creating a PPM picture,
putchar(p.Red); putchar(p.Green); putchar(p.Blue);
should work even to put a black pixel.
Jun 1 '07 #13

P: n/a
Army1987 wrote:
"Harald van D?k" <tr*****@gmail.comha scritto nel messaggio
news:f3**********@news1.zwoll1.ov.home.nl...
>Peter 'Shaggy' Haywood wrote:
>>Groovy hepcat Umesh was jivin' on 26 May 2007 09:25:29 -0700 in
comp.lang.c.
Re: How to print "\n" or '\0''s a cool scene! Dig it!

//how to print "\n" or '\0'

#include"stdio.h"

Now, I know you know better than that, Umesh. You must be trolling,
I think. The only explanation I can think of for your baffling
behaviour is that you are a troll.
That said, the only reason I'm responding to a troll is to encourage
others to ignore Umesh, and all trolls. Killfile the fool.

#include "stdio.h" is allowed in standard C. When #include "..." does not
pick up a file in the locations for user headers, it is replaced by the
compiler as if it read #include <...>.

I don't think Peter referred to that. Umesh asked a question which
can be misunderstood very easily, then, after being told how to
print a newline or a null character[1], he answered his question
himself, showing that what he was trying to do was printing a
backslash followed by a lowercase n, or an apostrophe followed by
a backslash followed by the digit 0 followed by another apostrophe,
a question which could be asked much less ambiguously as "how can I
print a backslash?".
What you are saying would also make sense, but I think he referred to the
#include style, because he snipped every other part of Umesh's code in his
reply.
Jun 1 '07 #14

P: n/a

"Harald van D?k" <tr*****@gmail.comha scritto nel messaggio
news:f3**********@news2.zwoll1.ov.home.nl...
Army1987 wrote:
>"Harald van D?k" <tr*****@gmail.comha scritto nel messaggio
news:f3**********@news1.zwoll1.ov.home.nl...
>>Peter 'Shaggy' Haywood wrote:
Groovy hepcat Umesh was jivin' on 26 May 2007 09:25:29 -0700 in
comp.lang.c.
Re: How to print "\n" or '\0''s a cool scene! Dig it!

>//how to print "\n" or '\0'
>
>#include"stdio.h"

Now, I know you know better than that, Umesh. You must be trolling,
I think. The only explanation I can think of for your baffling
behaviour is that you are a troll.
That said, the only reason I'm responding to a troll is to encourage
others to ignore Umesh, and all trolls. Killfile the fool.

#include "stdio.h" is allowed in standard C. When #include "..." does
not
pick up a file in the locations for user headers, it is replaced by the
compiler as if it read #include <...>.

I don't think Peter referred to that. Umesh asked a question which
can be misunderstood very easily, then, after being told how to
print a newline or a null character[1], he answered his question
himself, showing that what he was trying to do was printing a
backslash followed by a lowercase n, or an apostrophe followed by
a backslash followed by the digit 0 followed by another apostrophe,
a question which could be asked much less ambiguously as "how can I
print a backslash?".

What you are saying would also make sense, but I think he referred to the
#include style, because he snipped every other part of Umesh's code in his
reply.
Or he simplily arbitrarily snipped from that point onwards, considering he
did not snip the previous comment...
Jun 1 '07 #15

P: n/a
Groovy hepcat Harald van =?UTF-8?B?RMSzaw==?= was jivin' on Tue, 29
May 2007 18:43:15 +0200 in comp.lang.c.
Re: How to print "\n" or '\0''s a cool scene! Dig it!
>Peter 'Shaggy' Haywood wrote:
>Groovy hepcat Umesh was jivin' on 26 May 2007 09:25:29 -0700 in
comp.lang.c.
Re: How to print "\n" or '\0''s a cool scene! Dig it!
>>>//how to print "\n" or '\0'

#include"stdio.h"

Now, I know you know better than that, Umesh. You must be trolling,
I think. The only explanation I can think of for your baffling
behaviour is that you are a troll.
That said, the only reason I'm responding to a troll is to encourage
others to ignore Umesh, and all trolls. Killfile the fool.

#include "stdio.h" is allowed in standard C. When #include "..." does not
pick up a file in the locations for user headers, it is replaced by the
compiler as if it read #include <...>.
It's allowed (by the compiler). But that doesn't make it right. What
you say is true. However, if the compiler does find a header named
stdio.h before looking in the place it looks for <stdio.h>, then the
consequences depend on what's in that header.
In any case, the correct way to include the standard (or
implementation provided) stdio.h header is like so:

#include <stdio.h>

Anything else is the wrong way.

--

Dig the even newer still, yet more improved, sig!

http://alphalink.com.au/~phaywood/
"Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker.
I know it's not "technically correct" English; but since when was rock & roll "technically correct"?
Jun 3 '07 #16

P: n/a
Peter 'Shaggy' Haywood wrote:
Groovy hepcat Harald van =?UTF-8?B?RMSzaw==?= was jivin' on Tue, 29
May 2007 18:43:15 +0200 in comp.lang.c.
Re: How to print "\n" or '\0''s a cool scene! Dig it!
>>Peter 'Shaggy' Haywood wrote:
>>Groovy hepcat Umesh was jivin' on 26 May 2007 09:25:29 -0700 in
comp.lang.c.
Re: How to print "\n" or '\0''s a cool scene! Dig it!

//how to print "\n" or '\0'

#include"stdio.h"

Now, I know you know better than that, Umesh. You must be trolling,
I think. The only explanation I can think of for your baffling
behaviour is that you are a troll.
That said, the only reason I'm responding to a troll is to encourage
others to ignore Umesh, and all trolls. Killfile the fool.

#include "stdio.h" is allowed in standard C. When #include "..." does not
pick up a file in the locations for user headers, it is replaced by the
compiler as if it read #include <...>.

It's allowed (by the compiler). But that doesn't make it right.
It's allowed by the standard, and that does make it right.
What
you say is true. However, if the compiler does find a header named
stdio.h before looking in the place it looks for <stdio.h>, then the
consequences depend on what's in that header.
Of course. And if the umesh did place a file named stdio.h in one of the
paths the compiler looks at only for #include "..." directives, presumably
he wanted it to be used, and then #include "stdio.h" is the only way to do
it.
In any case, the correct way to include the standard (or
implementation provided) stdio.h header is like so:

#include <stdio.h>

Anything else is the wrong way.
What's correct depends on what the C standard and the implementation's
documentation say is correct.
Jun 3 '07 #17

P: n/a
Harald van Dijk <tr*****@gmail.comwrites:
Peter 'Shaggy' Haywood wrote:
>Groovy hepcat Harald van =?UTF-8?B?RMSzaw==?= was jivin' on Tue, 29
May 2007 18:43:15 +0200 in comp.lang.c.
[...]
>>>#include "stdio.h" is allowed in standard C. When #include "..." does not
pick up a file in the locations for user headers, it is replaced by the
compiler as if it read #include <...>.

It's allowed (by the compiler). But that doesn't make it right.

It's allowed by the standard, and that does make it right.
No, it makes it legal; it may or may not be "right" in a particular
context.
>What
you say is true. However, if the compiler does find a header named
stdio.h before looking in the place it looks for <stdio.h>, then the
consequences depend on what's in that header.

Of course. And if the umesh did place a file named stdio.h in one of the
paths the compiler looks at only for #include "..." directives, presumably
he wanted it to be used, and then #include "stdio.h" is the only way to do
it.
If Umesh placed a file named stdio.h in some directory, it's probably
a mistake. This is a judgement based on the level of expertise Umesh
has displayed so far in this newsgroup.
> In any case, the correct way to include the standard (or
implementation provided) stdio.h header is like so:

#include <stdio.h>

Anything else is the wrong way.

What's correct depends on what the C standard and the implementation's
documentation say is correct.
And on the requirements in any particular case, unless you have a very
narrow definition of "correct". For example, the following program is
perfectly legal (in fact, I believe it's strictly conforming), but
it's not "correct".

#include <stdio.h>

#define SIX 1+5
#define NINE 8+1

int main(void)
{
printf("%d * %d = %d\n", SIX, NINE, SIX * NINE);
return 0;
}

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 3 '07 #18

P: n/a
Keith Thompson wrote:
Harald van Dijk <tr*****@gmail.comwrites:
>Peter 'Shaggy' Haywood wrote:
>>Groovy hepcat Harald van =?UTF-8?B?RMSzaw==?= was jivin' on Tue, 29
May 2007 18:43:15 +0200 in comp.lang.c.
[...]
>>>>#include "stdio.h" is allowed in standard C. When #include "..." does
#not
pick up a file in the locations for user headers, it is replaced by the
compiler as if it read #include <...>.

It's allowed (by the compiler). But that doesn't make it right.

It's allowed by the standard, and that does make it right.

No, it makes it legal; it may or may not be "right" in a particular
context.
See below, I used "right" as "correct".
>>What
you say is true. However, if the compiler does find a header named
stdio.h before looking in the place it looks for <stdio.h>, then the
consequences depend on what's in that header.

Of course. And if the umesh did place a file named stdio.h in one of the
paths the compiler looks at only for #include "..." directives,
presumably he wanted it to be used, and then #include "stdio.h" is the
only way to do it.

If Umesh placed a file named stdio.h in some directory, it's probably
a mistake. This is a judgement based on the level of expertise Umesh
has displayed so far in this newsgroup.
Fair enough.
>> In any case, the correct way to include the standard (or
implementation provided) stdio.h header is like so:

#include <stdio.h>

Anything else is the wrong way.

What's correct depends on what the C standard and the implementation's
documentation say is correct.

And on the requirements in any particular case, unless you have a very
narrow definition of "correct". For example, the following program is
perfectly legal (in fact, I believe it's strictly conforming), but
it's not "correct".

#include <stdio.h>

#define SIX 1+5
#define NINE 8+1

int main(void)
{
printf("%d * %d = %d\n", SIX, NINE, SIX * NINE);
return 0;
}
Here's what I meant by correct:

If this is intended to print "6 * 9 = 54", the standard doesn't say that it
does (in fact, it says that it doesn't), so it is then not correct.

If this is intended to print "6 * 9 = 42", the standard says that it does,
so it is then correct.

I think this is not very different from what you mean, but please tell me if
I'm misunderstanding what you consider correct.
Jun 4 '07 #19

P: n/a
Harald van =?UTF-8?B?RMSzaw==?= wrote:
>
Keith Thompson wrote:
Harald van Dijk <tr*****@gmail.comwrites:
And on the requirements in any particular case,
unless you have a very narrow definition of "correct".
For example,
the following program is
perfectly legal (in fact, I believe it's strictly conforming),
but it's not "correct".

#include <stdio.h>

#define SIX 1+5
#define NINE 8+1

int main(void)
{
printf("%d * %d = %d\n", SIX, NINE, SIX * NINE);
return 0;
}

Here's what I meant by correct:

If this is intended to print "6 * 9 = 54",
the standard doesn't say that it
does (in fact, it says that it doesn't),
so it is then not correct.

If this is intended to print "6 * 9 = 42",
the standard says that it does, so it is then correct.

I think this is not very different from what you mean,
but please tell me if
I'm misunderstanding what you consider correct.
The above shown code is a correct program.
The C99 standard says what a "correct program" is.

N869
4. Conformance
[#1] In this International Standard, ``shall'' is to be
interpreted as a requirement on an implementation or on a
program; conversely, ``shall not'' is to be interpreted as a
prohibition.
[#2] If a ``shall'' or ``shall not'' requirement that
appears outside of a constraint is violated, the behavior is
undefined. Undefined behavior is otherwise indicated in
this International Standard by the words ``undefined
behavior'' or by the omission of any explicit definition of
behavior. There is no difference in emphasis among these
three; they all describe ``behavior that is undefined''.
[#3] A program that is correct in all other aspects,
operating on correct data, containing unspecified behavior
shall be a correct program and act in accordance with
5.1.2.3.

--
pete
Jun 4 '07 #20

P: n/a
Harald van Dijk <tr*****@gmail.comwrites:
Keith Thompson wrote:
[...]
>And on the requirements in any particular case, unless you have a very
narrow definition of "correct". For example, the following program is
perfectly legal (in fact, I believe it's strictly conforming), but
it's not "correct".

#include <stdio.h>

#define SIX 1+5
#define NINE 8+1

int main(void)
{
printf("%d * %d = %d\n", SIX, NINE, SIX * NINE);
return 0;
}

Here's what I meant by correct:

If this is intended to print "6 * 9 = 54", the standard doesn't say that it
does (in fact, it says that it doesn't), so it is then not correct.

If this is intended to print "6 * 9 = 42", the standard says that it does,
so it is then correct.

I think this is not very different from what you mean, but please tell me if
I'm misunderstanding what you consider correct.
I had forgotten that the standard uses the word "correct" in a sense
that differs from the way I've been using it here; thanks to pete for
reminding us.

A program that is correct in all other aspects, operating on
correct data, containing unspecified behavior shall be a correct
program and act in accordance with 5.1.2.3.

(Note that this isn't presented as a definition of the word "correct"
I presume that a program doesn't *have* to contain unspecified
behavior to be considered correct.)

I've been trying to draw a strong distinction between programs that
don't violate the standard and programs that, in addition, actually
work the way they're supposed to.

Going back to what started this, using
#include "stdio.h"
is legal and "correct" in the sense that the standard uses the term,
but it's almost certainly not *right* unless the author actually
intends to allow the program to use a stdio.h header other than the
one provided by the implementation.

It's important to point out that using
#include "stdio.h"
rather than
#include <stdio.h>
is almost certainly a mistake.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 4 '07 #21

P: n/a
Keith Thompson wrote:
[snip]
Going back to what started this, using
#include "stdio.h"
is legal and "correct" in the sense that the standard uses the term,
but it's almost certainly not *right* unless the author actually
intends to allow the program to use a stdio.h header other than the
one provided by the implementation.

It's important to point out that using
#include "stdio.h"
rather than
#include <stdio.h>
is almost certainly a mistake.
I have to disagree here. Since until you get to the point where creating a
file named stdio.h is a good idea, there is no difference between the two
forms, I don't think the first form is a mistake at all. If you mix
the "..." and <...forms, there are many cases where it's not clear which
form is most appropriate and whether the answer may change. If you always
use the "..." form, you can't go wrong. So why not always use the "..."
form?
Jun 4 '07 #22

P: n/a
Harald van Dijk <tr*****@gmail.comwrites:
Keith Thompson wrote:
>[snip]
Going back to what started this, using
#include "stdio.h"
is legal and "correct" in the sense that the standard uses the term,
but it's almost certainly not *right* unless the author actually
intends to allow the program to use a stdio.h header other than the
one provided by the implementation.

It's important to point out that using
#include "stdio.h"
rather than
#include <stdio.h>
is almost certainly a mistake.

I have to disagree here. Since until you get to the point where creating a
file named stdio.h is a good idea, there is no difference between the two
forms, I don't think the first form is a mistake at all. If you mix
the "..." and <...forms, there are many cases where it's not clear which
form is most appropriate and whether the answer may change. If you always
use the "..." form, you can't go wrong. So why not always use the "..."
form?
Using the "..." form tells a knowledgeable reader that the directive
might refer to some arbitrary file other than the standard header. It
tells me that either (a) the author might have inserted his own
stdio.h file for some reason, and I'd better figure out why if I want
to understand the code, or (b) the author doesn't really know what
he's doing, and he's just wasted my time.

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.

There are legitimate reasons to use either the "..." form or the <...>
form for headers other than the ones defined by the standard. None of
those reasons apply to stdio.h.

(Do you use #include "stdio.h" in your own code?)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 4 '07 #23

P: n/a
Keith Thompson <ks***@mib.orgwrote:
Using the <...form *for the standard headers* cannot go wrong.
There are exceptions to that rule,
as you would realize on a moment's reflection.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Jun 5 '07 #24

P: n/a
In article <13*************@corp.supernews.com>,
Thomas Dickey <di****@saltmine.radix.netwrote:
>Using the <...form *for the standard headers* cannot go wrong.
>There are exceptions to that rule,
as you would realize on a moment's reflection.
Why not save us a moment and tell us?

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Jun 5 '07 #25

P: n/a
Richard Tobin <ri*****@cogsci.ed.ac.ukwrote:
In article <13*************@corp.supernews.com>,
Thomas Dickey <di****@saltmine.radix.netwrote:
>>Using the <...form *for the standard headers* cannot go wrong.
>>There are exceptions to that rule,
as you would realize on a moment's reflection.
Why not save us a moment and tell us?
It's too early in the day to cut/paste the appropriate paragraphs from
the standard.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Jun 5 '07 #26

P: n/a
Keith Thompson wrote:
Harald van Dijk <tr*****@gmail.comwrites:
>Keith Thompson wrote:
>>[snip]
Going back to what started this, using
#include "stdio.h"
is legal and "correct" in the sense that the standard uses the term,
but it's almost certainly not *right* unless the author actually
intends to allow the program to use a stdio.h header other than the
one provided by the implementation.

It's important to point out that using
#include "stdio.h"
rather than
#include <stdio.h>
is almost certainly a mistake.

I have to disagree here. Since until you get to the point where creating
a file named stdio.h is a good idea, there is no difference between the
two forms, I don't think the first form is a mistake at all. If you mix
the "..." and <...forms, there are many cases where it's not clear
which form is most appropriate and whether the answer may change. If you
always use the "..." form, you can't go wrong. So why not always use the
"..." form?

Using the "..." form tells a knowledgeable reader that the directive
might refer to some arbitrary file other than the standard header. It
tells me that either (a) the author might have inserted his own
stdio.h file for some reason, and I'd better figure out why if I want
to understand the code, or (b) the author doesn't really know what
he's doing, and he's just wasted my time.
It's different to me. If "stdio.h" is included, I assume the standard
header, or a user header with the same effect, is included. If the
user-supplied stdio.h file does not behave like the standard stdio.h
header, that's what I consider wasting time.
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.
There are legitimate reasons to use either the "..." form or the <...>
form for headers other than the ones defined by the standard. None of
those reasons apply to stdio.h.
What if the programmer wants to deal with a system where <stdio.h>
unconditionally declares a function named read(), which conflicts with a
valid use of read as a global variable in the project, and supplying a
custom stdio.h header is less work than renaming the variable name
everywhere?
(Do you use #include "stdio.h" in your own code?)
Personally, I use "..." for source files in my project directories, and
<...for source files outside my project directories. In the event that it
could be either (suppose I use libfoo, and bundle it with my application,
but also support the system's libfoo if it's installed already -- or
suppose I optionally use my own stdio.h header for one specific
implementation to deal with a problem in the system's header), I use the
<...form, even though officially, in the second case, the behaviour is
undefined. So no, I would not use #include "stdio.h" in my own code.
Jun 5 '07 #27

P: n/a
Thomas Dickey <di****@saltmine.radix.netwrote:
Richard Tobin <ri*****@cogsci.ed.ac.ukwrote:
>In article <13*************@corp.supernews.com>,
Thomas Dickey <di****@saltmine.radix.netwrote:
>>>Using the <...form *for the standard headers* cannot go wrong.
>>>There are exceptions to that rule,
as you would realize on a moment's reflection.
>Why not save us a moment and tell us?
cut/paste time (though a waste since the knowledgable readers of this
newsgroup should know this offhand):

6.10.2 Source file inclusion

2 A preprocessing directive of the form

# include <h-char-sequencenew-line

searches a sequence of implementation-defined places for a header
identified uniquely by the specified sequence between the < and >
delimiters, and causes the replacement of that directive by the
entire contents of the header. How the places are specified or the
header identified is implementation-defined.
Using the <...form *for the standard headers* cannot go wrong.
Note that there's nothing that ensures that a bracketed include necessarily
refers to a "standard header" nor that giving the name of a standard
header will yield the expected file. It's implementation-defined (and
subject to how the user may/may not specify the places).

Several counter-examples came to mind on viewing that "Using" statement,
but those are from experience...

regards.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Jun 5 '07 #28

P: n/a
In article <13*************@corp.supernews.com>,
Thomas Dickey <di****@saltmine.radix.netwrote:
>Thomas Dickey <di****@saltmine.radix.netwrote:
>Richard Tobin <ri*****@cogsci.ed.ac.ukwrote:
>>In article <13*************@corp.supernews.com>,
Thomas Dickey <di****@saltmine.radix.netwrote:
>6.10.2 Source file inclusion
> 2 A preprocessing directive of the form
> # include <h-char-sequencenew-line
> searches a sequence of implementation-defined places for a header
identified uniquely by the specified sequence between the < and >
delimiters, and causes the replacement of that directive by the
entire contents of the header. How the places are specified or the
header identified is implementation-defined.
>Using the <...form *for the standard headers* cannot go wrong.
>Note that there's nothing that ensures that a bracketed include necessarily
refers to a "standard header" nor that giving the name of a standard
header will yield the expected file. It's implementation-defined (and
subject to how the user may/may not specify the places).
C89 4.1.2 Standard Headers

Each library function is declared in a header, whose contents are
made available by the #include preprocessing directive. The header
declares a set of related functions, plus any necessary types and
additional macros needed to facilitate their use.

The standard headers are:

<assert.h <locale.h <sstddef.h>
[etc]

If a file with the same name as one of the above < and delimited
sequences, not provied as part of the implementation, is placed in
any of the standard places for a source file to be included,
the behavior is undefined.
This plus plenty of Usage statements in C89 enshrine the above token
sequences as being *the* way to refer to the standard headers.

I believe this leaves only your point that using the <...form
for standard headers could go wrong because some idjit might have
replaced one of the standard headers with non-standard content.
--
"It is important to remember that when it comes to law, computers
never make copies, only human beings make copies. Computers are given
commands, not permission. Only people can be given permission."
-- Brad Templeton
Jun 5 '07 #29

P: n/a
Walter Roberson <ro******@ibd.nrc-cnrc.gc.cawrote:
I believe this leaves only your point that using the <...form
for standard headers could go wrong because some idjit might have
replaced one of the standard headers with non-standard content.
heh. All you're asserting is that if the standard doesn't apply then
it's undefined behavior, and that since the standard only describes
defined behavior then KT's claim that using the standard form cannot
go wrong is always correct since we're forbidden to contemplate any
other result.

Given your other recent followups, I don't suppose I could expect much.

bye.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Jun 5 '07 #30

P: n/a
In article <13************@corp.supernews.com>,
Thomas Dickey <di****@saltmine.radix.netwrote:
>Walter Roberson <ro******@ibd.nrc-cnrc.gc.cawrote:
>I believe this leaves only your point that using the <...form
for standard headers could go wrong because some idjit might have
replaced one of the standard headers with non-standard content.
>heh. All you're asserting is that if the standard doesn't apply then
it's undefined behavior, and that since the standard only describes
defined behavior then KT's claim that using the standard form cannot
go wrong is always correct since we're forbidden to contemplate any
other result.
I made no such assertion. In your earlier posting, you gave
multiple reasons for a particular viewpoint; I refuted one of the
reasons with reference to the C89 standard, and summarized the
reason that remained, without making comment as to whether that
reason was correct or incorrect.

If you wish to point out that one should not say that something
"can never" go wrong, on the grounds that the implementation might
be broken, or a hardware error may occur, or a Finite Improbability
Generator might be operating nearby and might translate all of
the program's undergarments simultaneously 3 feet to the left,
then I would agree

>Given your other recent followups, I don't suppose I could expect much.
I can never remember which emoticon encodes "Raises Eyebrows".
--
Prototypes are supertypes of their clones. -- maplesoft
Jun 5 '07 #31

P: n/a
Walter Roberson <ro******@ibd.nrc-cnrc.gc.cawrote:
I made no such assertion. In your earlier posting, you gave
multiple reasons for a particular viewpoint; I refuted one of the
reasons with reference to the C89 standard, and summarized the
reason that remained, without making comment as to whether that
reason was correct or incorrect.
I'm afraid you missed the point. All you accomplished was reminding
the dwindling audience that in the absence of the standard's
permissable but unspecified implementation-specific behavior
that an include will get the expected header.

That's obvious (and the extra cut/paste wasn't needed, since it
adds no information).

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Jun 5 '07 #32

P: n/a
In article <13*************@corp.supernews.com>,
Thomas Dickey <di****@saltmine.radix.netwrote:
>Walter Roberson <ro******@ibd.nrc-cnrc.gc.cawrote:
>I made no such assertion. In your earlier posting, you gave
multiple reasons for a particular viewpoint; I refuted one of the
reasons with reference to the C89 standard, and summarized the
reason that remained, without making comment as to whether that
reason was correct or incorrect.
>I'm afraid you missed the point. All you accomplished was reminding
the dwindling audience that in the absence of the standard's
permissable but unspecified implementation-specific behavior
that an include will get the expected header.
No, I pointed out a section of the C89 standard that overrides
the "implementation-specific" clause you quoted, for the
case of the standard headers (which were the ones in question).
For non-standard headers, the implementation-specific clause holds.
Every conforming implementation must, for example, support

#include <string.h>

If any implementation that said, "But the association between
token strings in <...and files is implementation defined, so
*I'm* going to require that the programs use

#include <#$&F* 9 =>

instead!", then that implementation would be breaking a great
many clauses in the standard.

Implementations are not even required to store the standard
headers -as- files or in any readable format: all that is required
of them is that when the standard header names are used, that the
defined interfaces and types become available to be used from that
pointed down in that translation unit. It is considered perfectly
fine for the standard headers to be "precompiled" into some
intermediate format and that format loaded in when the standard header
names are recognized; it is also considered perfectly acceptable
for the standard header contents to be literally built into the
compiler and just "turned on" by recognition of the appropriate
#include (that has not been discarded due to conditional compilation.)

--
"No one has the right to destroy another person's belief by
demanding empirical evidence." -- Ann Landers
Jun 5 '07 #33

P: n/a
Harald van Dijk <tr*****@gmail.comwrites:
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.

[...]
What if the programmer wants to deal with a system where <stdio.h>
unconditionally declares a function named read(), which conflicts with a
valid use of read as a global variable in the project, and supplying a
custom stdio.h header is less work than renaming the variable name
everywhere?
Then the implementation is non-conforming.
>(Do you use #include "stdio.h" in your own code?)

Personally, I use "..." for source files in my project directories, and
<...for source files outside my project directories. In the event that it
could be either (suppose I use libfoo, and bundle it with my application,
but also support the system's libfoo if it's installed already -- or
suppose I optionally use my own stdio.h header for one specific
implementation to deal with a problem in the system's header), I use the
<...form, even though officially, in the second case, the behaviour is
undefined. So no, I would not use #include "stdio.h" in my own code.
But you seem to be advising others to do so. I'm confused.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 5 '07 #34

P: n/a
Thomas Dickey <di****@saltmine.radix.netwrites:
Keith Thompson <ks***@mib.orgwrote:
>Using the <...form *for the standard headers* cannot go wrong.

There are exceptions to that rule,
as you would realize on a moment's reflection.
Chapter and verse, please.

Assuming a conforming implementation, I know of no cases where using
the <...form can "go wrong" in the sense we're discussing. Please
clarify.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 5 '07 #35

P: n/a
Keith Thompson wrote:
Harald van Dijk <tr*****@gmail.comwrites:
>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.his 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).
[...]
>What if the programmer wants to deal with a system where <stdio.h>
unconditionally declares a function named read(), which conflicts with a
valid use of read as a global variable in the project, and supplying a
custom stdio.h header is less work than renaming the variable name
everywhere?

Then the implementation is non-conforming.
True, but it's nice to make the same code work for specific non-conforming
systems that works for the conforming systems.
>>(Do you use #include "stdio.h" in your own code?)

Personally, I use "..." for source files in my project directories, and
<...for source files outside my project directories. In the event that
it could be either (suppose I use libfoo, and bundle it with my
application, but also support the system's libfoo if it's installed
already -- or suppose I optionally use my own stdio.h header for one
specific implementation to deal with a problem in the system's header), I
use the <...form, even though officially, in the second case, the
behaviour is undefined. So no, I would not use #include "stdio.h" in my
own code.

But you seem to be advising others to do so. I'm confused.
I'm advising others to do so, only if they wish both to have the option to
use or switch to a custom stdio.h file, and to have 100% strictly
conforming code. If either the code doesn't have to be 100% strictly
conforming, or there is no possibility that a user stdio.h will be used in
the future, I'm advising others use whichever form they are most
comfortable with, whether that's the <...form or the "..." form.
Jun 5 '07 #36

P: n/a
Keith Thompson <ks***@mib.orgwrote:
Thomas Dickey <di****@saltmine.radix.netwrites:
>Keith Thompson <ks***@mib.orgwrote:
>>Using the <...form *for the standard headers* cannot go wrong.

There are exceptions to that rule,
as you would realize on a moment's reflection.
Chapter and verse, please.
Assuming a conforming implementation, I know of no cases where using
the <...form can "go wrong" in the sense we're discussing. Please
clarify.
Harald's been telling you also, but since you've used cut/paste replies
to his postings without evidencing any comprehension of the discussion,
it'd be a waste of my time.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Jun 5 '07 #37

P: n/a
Walter Roberson <ro******@ibd.nrc-cnrc.gc.cawrote:
No, I pointed out a section of the C89 standard that overrides
the "implementation-specific" clause you quoted, for the
case of the standard headers (which were the ones in question).
For non-standard headers, the implementation-specific clause holds.
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.

It's certainly none of the Unix/etc compilers, nor any of Microsoft's
or their competitors. They all quite happily provide me with the
contents of the files (or not) according to the implementation-defined
search mechanism. Granted that the standard does not guarantee that
there _is_ a mechanism for searching in multiple locations, it is
assumed by all of those compiler-implementers that they're doing
something that follows the standard.

Perhaps you should followup and get their certification revoked.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Jun 5 '07 #38

P: n/a
On Jun 5, 11:29 pm, Thomas Dickey <dic...@saltmine.radix.netwrote:
Walter Roberson <rober...@ibd.nrc-cnrc.gc.cawrote:
No, I pointed out a section of the C89 standard that overrides
the "implementation-specific" clause you quoted, for the
case of the standard headers (which were the ones in question).
For non-standard headers, the implementation-specific clause holds.

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.
But in what does an implementation consist? Surely not just a
compiler, but the preprocessor plus compiler plus standard library
functions plus headers (plus other stuff probably) all together
constitute a single implementation.
It's certainly none of the Unix/etc compilers, nor any of Microsoft's
or their competitors. They all quite happily provide me with the
contents of the files (or not) according to the implementation-defined
search mechanism. Granted that the standard does not guarantee that
there _is_ a mechanism for searching in multiple locations, it is
assumed by all of those compiler-implementers that they're doing
something that follows the standard.

Perhaps you should followup and get their certification revoked.

--
Thomas E. Dickeyhttp://invisible-island.netftp://invisible-island.net

Jun 5 '07 #39

P: n/a
Harald van Dijk <tr*****@gmail.comwrites:
Keith Thompson wrote:
>Harald van Dijk <tr*****@gmail.comwrites:
>>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.his 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.

I suppose that means that any attempt to provide your own stdio.h,
even if you do so by placing the file in a location searched by
#include "..." but not by #include <...>, invokes undefined behavior.
It seems to me to be a bit excessive, but if you mess around with that
kind of thing, you're on your own.

Placing your own stdio.h file in a location searched by #include <...>
is just messing with the implementation; it's just like replacing the
executable that implements the preprocessor, or replacing the object
code that implements stdio. I would have said that it just breaks the
implementation, rendering it non-conforming. I guess that saying "the
behavior is undefined" has the same effect.

[...]
I'm advising others to do so, only if they wish both to have the
option to use or switch to a custom stdio.h file, and to have 100%
strictly conforming code. If either the code doesn't have to be 100%
strictly conforming, or there is no possibility that a user stdio.h
will be used in the future, I'm advising others use whichever form
they are most comfortable with, whether that's the <...form or the
"..." form.
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. The very few people who are
knowledgeable enough to replace chunks of their implementation will
know that my advice doesn't apply to them.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 5 '07 #40

P: n/a
Keith Thompson wrote:
Harald van Dijk <tr*****@gmail.comwrites:
>Keith Thompson wrote:
>>Harald van Dijk <tr*****@gmail.comwrites:
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.his 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.

[...]
>I'm advising others to do so, only if they wish both to have the
option to use or switch to a custom stdio.h file, and to have 100%
strictly conforming code. If either the code doesn't have to be 100%
strictly conforming, or there is no possibility that a user stdio.h
will be used in the future, I'm advising others use whichever form
they are most comfortable with, whether that's the <...form or the
"..." form.

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
that I personally use the <...form, so as far as style goes, I do agree,
but styles can differ greatly.
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.
Jun 5 '07 #41

P: n/a
Thomas Dickey <di****@saltmine.radix.netwrites:
Walter Roberson <ro******@ibd.nrc-cnrc.gc.cawrote:
>No, I pointed out a section of the C89 standard that overrides
the "implementation-specific" clause you quoted, for the
case of the standard headers (which were the ones in question).
For non-standard headers, the implementation-specific clause holds.

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 (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 6 '07 #42

P: n/a
Harald van Dijk <tr*****@gmail.comwrites:
Keith Thompson wrote:
>Harald van Dijk <tr*****@gmail.comwrites:
>>Keith Thompson wrote:
Harald van Dijk <tr*****@gmail.comwrites:
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.his 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.

[...]
>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.
Precisely my point.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 6 '07 #43

P: n/a
Harald van D?k wrote:
Keith Thompson wrote:
.... snip ...
>
>It's important to point out that using
#include "stdio.h"
rather than
#include <stdio.h>
is almost certainly a mistake.

I have to disagree here. Since until you get to the point where
creating a file named stdio.h is a good idea, there is no
difference between the two forms, I don't think the first form
is a mistake at all. If you mix the "..." and <...forms, there
are many cases where it's not clear which form is most appropriate
and whether the answer may change. If you always use the "..."
form, you can't go wrong. So why not always use the "..." form?
Because you MAY want to replace stdio by something specific. For
example, you may have a system where only putchar and getchar are
available for i/o, and want early warnings if you accidentally use
other features. So you write a "stdio.h" that defines some things
as "error ..." and use that for the occasional compilation.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Jun 6 '07 #44

P: n/a
Harald van D?k wrote:
>
.... snip ...
>
What if the programmer wants to deal with a system where <stdio.h>
unconditionally declares a function named read(), which conflicts
with a valid use of read as a global variable in the project, and
supplying a custom stdio.h header is less work than renaming the
variable name everywhere?
In that case the compiler is not standards-compliant. Which is one
reason I use "gcc -W -Wall -ansi -pedantic".

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Jun 6 '07 #45

P: n/a
Walter Roberson wrote:
Thomas Dickey <di****@saltmine.radix.netwrote:
.... snip ...
>
>6.10.2 Source file inclusion
> 2 A preprocessing directive of the form
> # include <h-char-sequencenew-line
> searches a sequence of implementation-defined places for a
header identified uniquely by the specified sequence between
the < and delimiters, and causes the replacement of that
directive by the entire contents of the header. How the
places are specified or the header identified is
implementation-defined.
>>Using the <...form *for the standard headers* cannot go wrong.
>Note that there's nothing that ensures that a bracketed include
necessarily refers to a "standard header" nor that giving the
name of a standard header will yield the expected file. It's
implementation-defined (and subject to how the user may/may not
specify the places).

C89 4.1.2 Standard Headers

Each library function is declared in a header, whose contents
are made available by the #include preprocessing directive. The
header declares a set of related functions, plus any necessary
types and additional macros needed to facilitate their use.

The standard headers are:

<assert.h <locale.h <sstddef.h>
[etc]

If a file with the same name as one of the above < and >
delimited sequences, not provied as part of the implementation,
is placed in any of the standard places for a source file to be
included, the behavior is undefined.

This plus plenty of Usage statements in C89 enshrine the above
token sequences as being *the* way to refer to the standard headers.

I believe this leaves only your point that using the <...form
for standard headers could go wrong because some idjit might have
replaced one of the standard headers with non-standard content.
I gave an example of using the "..." form yesterday, and the
reasons for it. This doesn't change the fact that it is normally a
BAD IDEA. Note that there is no reason to assume such standard
files actually exist in the system. They may be implemented via
code in the compiler proper.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Jun 6 '07 #46

This discussion thread is closed

Replies have been disabled for this discussion.