Representation of '\n' and EOF

[Skarmander]

Is it legal for an implementation to have '\n' == EOF?

Yes, I did read the standard, and didn't see anything that would
disallow this. I want to make sure I didn't overlook something.

S.

 

[Eric Sosman]

Is it legal for an implementation to have '\n' == EOF?

Yes, I did read the standard, and didn't see anything that would
disallow this. I want to make sure I didn't overlook something.

All characters in the "basic execution character set,"
including '\n', must have non-negative values. EOF must
have a negative value.

 

[Skarmander]

All characters in the "basic execution character set,"
including '\n', must have non-negative values. EOF must
have a negative value.

Thanks for the pointer.

That EOF had to be negative was obvious; that '\n' had to be nonnegative
was not, hence the question. The standard does in fact say this,
indirectly, as I wager it says most things indirectly. (Give me a break,
I've never read it before.

You need to puzzle it together from the following sections:

5.2.1.3. "[..] In the basic execution character set, there shall be
control characters representing alert, backspace, carriage return, and
new line."

This establishes that newline (or very precisely, a control character
representing newline) is part of the basic execution charset.

5.2.2.2. "Alphabetic escape sequences representing nongraphic characters
in the execution character set are intended to produce actions on
display devices as follows: [..] \n (new line) Moves the active position
to the initial position of the next line."

This (indirectly) establishes that '\n' is in fact the escape sequence
for newline. (Trivial but necessary.)

6.2.5.3. "An object declared as type char is large enough to store any
member of the basic execution character set. If a member of the basic
execution character set is stored in a char object, its value is
guaranteed to be nonnegative. [...]"

The main attraction, but it only applies to characters stored in char
objects and '\n' is just a constant, so we're *not* done yet.

6.4.4.4.10. "[..] If an integer character constant contains a single
character or escape sequence, its value is the one that results when an
object with type char whose value is that of the single character or
escape sequence is converted to type int."

Now,
- by 5.2.1.3., the control character representing newline is a member of
the basic execution character set;
- by 6.4.4.4.10., the value of the constant '\n' is the value that
results when an object of type char whose value is that of '\n' is
converted to type int;
- by 5.2.2.2., '\n' is the escape sequence for the control character
representing newline;
- by 6.2.5.3. and the above, the value of '\n' is guaranteed to be
nonnegative.

QED. I'm starting to see why reading the standard isn't everyone's
favorite pastime.

S.

 

[lawrence.jones]

Is it legal for an implementation to have '\n' == EOF?

Yes, I did read the standard, and didn't see anything that would
disallow this. I want to make sure I didn't overlook something.

Such questions are more appropriate for comp.std.c, but the answer is
"no". 7.19.1 requires EOF to have a negative value but 6.2.5 requires
that all the members of the basic character set (of which '\n' is one)
have non-negative values.

-Larry Jones

We don't ATTEND parties, we just CRASH 'em. -- Calvin

 

[Skarmander]

Such questions are more appropriate for comp.std.c,

<snip>

Yes, you're right. The distinction of when comp.lang.c and when
comp.std.c is more appropriate seems to be rather subtle, but "stupid"
questions like the one above probably don't qualify as "everyday C
programming".

Of course, I wasn't subscribed to comp.std.c. I've rectified this.

S.

 

[Keith Thompson]

Such questions are more appropriate for comp.std.c, but the answer is
"no". 7.19.1 requires EOF to have a negative value but 6.2.5 requires
that all the members of the basic character set (of which '\n' is one)
have non-negative values.

Really? It seems to me that it's a question about the language (as
defined by the standard, of course), and therefore more appropriate
for comp.lang.c than for comp.std.c.

 

[Chris Torek]

[on newsgroup appropriateness; all other detail snipped]

Really? It seems to me that it's a question about the language (as
defined by the standard, of course), and therefore more appropriate
for comp.lang.c than for comp.std.c.

This one is certainly more of a borderline issue.

If one were to phrase it as, say, "by what clause(s) in the C
standard, if any, can we conclude that '\n' != EOF", it would
certainly be a comp.std.c question.

A question like: "What's wrong with this code?" (followed yb
example code) is certainly comp.lang.c material.

A question as to whether some particular expression is standard
conforming is often borderline, and phrasing could push it in one
direction or the other.

A question about whether a particular word on the 127th page should
actually be "shall" is certainly comp.std.c material.

It might be useful if Steve Summit were to add something along
these lines to the comp.lang.c FAQ.

 

[lawrence.jones]

Really? It seems to me that it's a question about the language (as
defined by the standard, of course), and therefore more appropriate
for comp.lang.c than for comp.std.c.

The traditional division is that comp.lang.c is for discussions about
using C to write programs whereas comp.std.c is for discussions about
the definition of C. Thus, a question about whether a particular
implementation is allowable or not is more appropriate in comp.std.c.

-Larry Jones

I've got more brains than I know what to do with. -- Calvin

 

[pete]

The traditional division is that comp.lang.c is for discussions about
using C to write programs whereas comp.std.c is for discussions about
the definition of C. Thus, a question about whether a particular
implementation is allowable or not is more appropriate in comp.std.c.

I always thought std was mostly interested in
changes which should be made to the standard
in order to add new features, remove old ones, or to improve clarity.

 

[Peter Nilsson]

... The standard does in fact say this, indirectly, as I wager it says
most things indirectly. ...

"But the plans were on display..."
- Mr Prosser

<g>