which functions set the end-of-file indicator?

[Flash Gordon]

santosh wrote, On 07/08/08 06:26:

He never claimed that the code was portable. He was talking about a
particular case, a particular machine, that does define perfectly the
conversion of (unsigned char)EOF to an int, yielding EOF again.

True. How it behaves on an implementation which raises a trap is just as
irrelevant to the point as how it behaves on a VAX or under MSVC (since
all the world is now MSVC instead of being a VAX).

Chuck, if you were going to pick up on the non-portable aspects in my
post you should also have picked up on me specifying:
2s complement
CHAR_BIT==16
EOF==-1
sizeof(int)==1
no padding bits in int
putc not failing

That an implementation could be defined as raising a signal on the
conversion is just as irrelevant as the fact that putc could fail or
that CHAR_BIT can be 8, 9 or 15. In such situations putc cannot return
the value of EOF and the discussion was about whether it is possible for
putc to return EOF on any implementation.

 

[CBFalconer]

CBFalconer wrote:
.... snip ...


He never claimed that the code was portable. He was talking about a
particular case, a particular machine, that does define perfectly
the conversion of (unsigned char)EOF to an int, yielding EOF again.

Just checked. Yes, this newsgroup is c.l.c. Particular machines
are off-topic here. We are entitled to assume that any articles
are dealing with the C language.

 

[santosh]

santosh wrote, On 07/08/08 06:26:

True. How it behaves on an implementation which raises a trap is just
as irrelevant to the point as how it behaves on a VAX or under MSVC
(since all the world is now MSVC instead of being a VAX).

Chuck, if you were going to pick up on the non-portable aspects in my
post you should also have picked up on me specifying:
2s complement
CHAR_BIT==16
EOF==-1
sizeof(int)==1
no padding bits in int
putc not failing

That an implementation could be defined as raising a signal on the
conversion is just as irrelevant as the fact that putc could fail or
that CHAR_BIT can be 8, 9 or 15. In such situations putc cannot return
the value of EOF and the discussion was about whether it is possible
for putc to return EOF on any implementation.

Just a small question. When the Standard says that upon integer overflow
an implementation defined signal or other action occurs, does it also
include the possibility of overflow within the Standard library itself,
or just "user code"? I don't think so, since the Standard library is
allowed to be implemented in languages other than C.

 

[santosh]

Just checked. Yes, this newsgroup is c.l.c. Particular machines
are off-topic here. We are entitled to assume that any articles
are dealing with the C language.

It's still on-topic to debate the semantics of C for different values
for variables that are specified as implementation defined in the
Standard. Otherwise this newsgroups will be just about useless.

Note that Flash was not talking about anything not defined in the
Standard, but merely with the behaviour that would be produced if
sizeof(int) were one. Are you saying that this is off-topic for this
group?

 

[vippstar]

... snip ...



Just checked. Yes, this newsgroup is c.l.c. Particular machines
are off-topic here. We are entitled to assume that any articles
are dealing with the C language.

Your snip makes it look like 'santosh' posts are off-topic, but that's
not true.
Please learn to snip.

 

[vippstar]

Just a small question. When the Standard says that upon integer overflow
an implementation defined signal or other action occurs, does it also
include the possibility of overflow within the Standard library itself,
or just "user code"? I don't think so, since the Standard library is
allowed to be implemented in languages other than C.

If x; is implementation defined, then f() { x; }, would make 'f'
implementation defined as well.
If the description of the function doesn't mention implementation
defined behavior, then something like integer overflow can't occur in
the implementation of that function, for it would make the
implementation non-conforming.

 

[Keith Thompson]

Just checked. Yes, this newsgroup is c.l.c. Particular machines
are off-topic here. We are entitled to assume that any articles
are dealing with the C language.

Specifying particular values for a (perhaps hypothetical)
implementation, such as CHAR_BIT, sizeof(int), and so forth, and
exploring the consequences of those values is perfectly appropriate as
a way to illuminate the requirements of the standard. That's all
Flash did. He mentioned, among other things, that his sample
implementation uses 2's-complement. He didn't explicitly state that
arithmetic behaves as it typically does for 2's-complement systems,
i.e., that signed overflow results in wraparound. That makes his
description *slightly* incomplete (though it's reasonable to infer the
common behavior). It does *not* make it off-topic.

If someone asked the following:

Suppose CHAR_BIT==8 and sizeof(int)==4. Must INT_MAX be exactly
2147483647?

would you say the question is off-topic because the standard doesn't
require those particular values?

(If anyone is wondering, the answer is no, due to the possibility of
padding bits.)

 

[Antoninus Twink]

Just checked. Yes, this newsgroup is c.l.c. Particular machines
are off-topic here. We are entitled to assume that any articles
are dealing with the C language.

Perhaps you could explain in what way the article below, which you
posted five minutes after the one quoted above, "deals with the C
language".