which functions set the end-of-file indicator?

[nicolas.sitbon]

Hi everybody, in a french C book, the author says that only {fgetc,
getc, getchar, fgetwc, getwc, getwchar, fgets, gets, fgetws, getws,
fputc, putc, putchar, fputwc, putwc, putwchar, fputs, puts, fputws}
are guaranteed to set the end-of-file indicator when the end-of-file
is reached, but in C99 standard, I find p 288 (ISO/IEC 9899:TC3
Committee Draft — Septermber 7, 2007 WG14/N1256)

/* ============================= */
#include <stdio.h>
/* ... */
int count; float quant; char units[21], item[21];
do {
count = fscanf(stdin, "%f%20s of %20s", &quant, units, item);
fscanf(stdin,"%*[^\n]");
} while (!feof(stdin) && !ferror(stdin));
/* ============================= */
It seems to say that fscanf family function set end-of-file indicator
too? which functions set the end-of-file indicator?

[Barry Schwarz]

On Tue, 05 Aug 2008 13:46:17 -0400, Eric Sosman <Er*********@sun.com>
wrote:

>Barry Schwarz wrote:

>>
No one said EOF could not be a valid byte. However, putc will never
put a negative value. In the absence of an error, putc returns the
value it puts. Therefore, in the absence of an error, it must return
a positive value. Since EOF is negative, putc cannot return EOF other
than as an error indicator.

Not even when CHAR_MIN<=EOF and UCHAR_MAX>INT_MAX?

CHAR_MIN is irrelevant since the only char at issue is unsigned char.
UCHAR_MIN, if it existed, would have to be 0. putc only puts unsigned
char. In the absence of an error, it will return the value of the
char that was put. That value is unsigned and therefore non-negative.
Since EOF must be negative, the only time EOF can be returned is when
an error is detected. In the case of an error, the value of the
original int to be put is irrelevant.

--
Remove del for email

[Barry Schwarz]

On Tue, 5 Aug 2008 10:36:17 -0700 (PDT), vi******@gmail.com wrote:

>On Aug 5, 8:23 pm, Barry Schwarz <[e-mail]:

>5On Tue, 5 Aug 2008 05:32:36 -0700 (PDT), [e-mail] wrote:

>On Aug 5, 11:44 am, Barry Schwarz <[e-mail]:
On Mon, 4 Aug 2008 18:45:02 -0700 (PDT), [e-mail] wrote:
<snip>

>The end of file indicator has nothing to do with the EOF macro.
When putc returns EOF, it means one of the following

o error with the stream; ferror() should return non-zero.
o EOF is a valid byte value that has been written to the stream.

>The second case cannot be. EOF is guaranteed to be negative. While
it is certainly possible to pass this value to putc, it will be
converted to unsigned char (7.19.7.8-2 and 7.19.7.3-2). It is this
positive value which will be returned, not EOF.

>No it can be. We had a recent discussion about this and I think
everyone agreed that it's possible for EOF to be a valid byte.

No one said EOF could not be a valid byte. However, putc will never
put a negative value. In the absence of an error, putc returns the
value it puts. Therefore, in the absence of an error, it must return
a positive value. Since EOF is negative, putc cannot return EOF other
than as an error indicator.

It will never return EOF as the value of the byte written. That is
what you claimed as the second case and it cannot be. More to the
point, putc will never write a negative value since each byte is
converted to unsigned char. Read the second section of the standard I
reference above.

I'm not convinced. Read the discussion in my message that you snipped.
I don't think you understand the situation I'm talking about.

Your text claims it is possible for putc to return EOF when it is
passed the int value EOF and successfully writes to the stream. If
that is not what you meant, then you need to correct your text so we
can all discuss what you really meant.

putc will never write the value EOF to the stream. It will write the
value (unsigned char)EOF. Whether you are convinced or not is
irrelevant; that is what 7.19.7.3-2 says it will do. (On those
systems where EOF is -1 and CHAR_BIT is 8, (unsigned char)EOF has the
value 255.) Therefore, it will return the value (unsigned char)EOF.
This value cannot compare equal to EOF.

--
Remove del for email

[Flash Gordon]

Barry Schwarz wrote, On 06/08/08 03:08:

On Tue, 05 Aug 2008 13:46:17 -0400, Eric Sosman <Er*********@sun.com>
wrote:

>Barry Schwarz wrote:

>>No one said EOF could not be a valid byte. However, putc will never
put a negative value. In the absence of an error, putc returns the
value it puts. Therefore, in the absence of an error, it must return
a positive value. Since EOF is negative, putc cannot return EOF other
than as an error indicator.

Not even when CHAR_MIN<=EOF and UCHAR_MAX>INT_MAX?

CHAR_MIN is irrelevant since the only char at issue is unsigned char.
UCHAR_MIN, if it existed, would have to be 0. putc only puts unsigned
char. In the absence of an error, it will return the value of the
char that was put. That value is unsigned and therefore non-negative.
Since EOF must be negative, the only time EOF can be returned is when
an error is detected. In the case of an error, the value of the
original int to be put is irrelevant.

You have missed the point (although the bit about CHAR_MIN=EOF is
irrelevant I believe). To take a concrete example imagine an
implementation where CHAR_BIT is 16 and sizeof(int)==1 that uses 2s
complement. On this implementation

UCHAR_MAX==65535
INT_MAX=32767
EOF==-1

In the code you to

int ret = putc(EOF,stdout);

-1 is passed to putc.
putc converts it to an unsigned char giving a value of 65535
putc outputs 65535 to stdout (or the file of your choice)
put *attempts* to return 65535, but as it does not fit in an int
(greater than INT_MAX) it cannot. So putc returns the bit-pattern of all
16 bits set (as that is how 65535 is represented in an unsigned char on
this implementation).
All 16 bits set, when interpreted as a 16 bit 2s complement number
(which is what int is on this implementation) is -1.
Therefore, on this implementation, putc returns -1, which is the value
of EOF on this implementation, when -1 (the value of EOF) is passed in
and putc succeeds.

There have previously been long discussions here about whether such a
hosted implementation is conforming. There are definitely a lot of
freestanding implementations with sizeof(int)==1, but they are not
required to provide putc.
--
Flash Gordon

[Flash Gordon]

Barry Schwarz wrote, On 06/08/08 03:08:

On Tue, 05 Aug 2008 20:28:38 +0530, santosh <sa*********@gmail.com>
wrote:

>CBFalconer wrote:

>>Richard Heathfield wrote:
CBFalconer said:
vi******@gmail.com wrote:
... snip ...
>No it can be. We had a recent discussion about this and I think
>everyone agreed that it's possible for EOF to be a valid byte.
Since EOF is a negative constant, it is hard to represent in an
unsigned char.
It is, however, trivial to convert EOF into an unsigned char.
However it is far from trivial to convert an unsigned char into
EOF.

That's impossible and makes no sense too.

The issue here is whether it makes sense to pass EOF to fputc or putc.
As they take an int expression for their first arguments, it is
possible to do so. That value is then converted inside [f]putc to an
unsigned char value and written to the stream specified. Then this byte
is cast to int and returned, if there are no write errors, in which
case EOF is returned.

When the unsigned char is converted back to an int, the value must be
non-negative.

Incorrect, see my other post for a specific example showing what happens
if sizeof(int)==1.

In that case it cannot be EOF which is guaranteed to be
negative. In the absence of an error, only non-negative values will
be returned. EOF is only returned on error.

Not that simple I'm afraid. See my other post.

>I think the issue is whether both of these two (simplified)
implementations of fputc are correct, as per the Standard:

int fputc(int ch, FILE *s) {
if (write((unsigned char)ch, s) == SUCCESS) return (unsigned char)ch;
else { s->err_flag = 1; return EOF; }
}

int fputc(int ch, FILE *s) {
if (write((unsigned char)ch, s) == SUCCESS) return ch;
else { s->err_flag = 1; return EOF; }
}

I think that the Standard doesn't allow the second implementation. The
relevant part is 7.19.7.3 of n1256.

Since you know this to be incorrect, then you know that the return
value will be non-negative in the absence of an error.

It doesn't allow the 2nd normally. However, if sizeof(int)==1 then about
half the values of an unsigned char (including EOF) cannot be
represented as an int, what does the implementation do with those?

See other post for a worked example.
--
Flash Gordon

[nicolas.sitbon]

When a file is opened via fopen(), what's the state of the end-of-file
and error indicator? undetermined? cleared? setted?

[santosh]

ni************@gmail.com wrote:

When a file is opened via fopen(), what's the state of the end-of-file
and error indicator? undetermined? cleared? setted?

They are both cleared.

[nicolas.sitbon]

On 6 août, 10:22, santosh <[e-mail]:

[e-mail] wrote:

When a file is opened via fopen(), what's the state of the end-of-file
and error indicator? undetermined? cleared? setted?

They are both cleared.

In fact, I find that :
7 When opened, a stream is fully buffered if and only if it can be
determined not to refer to
an interactive device. The error and end-of-file indicators for the
stream are cleared.

But what about append mode "a"? in this case what's the state of the
end-of-file indicator?

[santosh]

ni************@gmail.com wrote:

On 6 août, 10:22, santosh <[e-mail]:

>[e-mail] wrote:

When a file is opened via fopen(), what's the state of the
end-of-file and error indicator? undetermined? cleared? setted?

They are both cleared.

In fact, I find that :
7 When opened, a stream is fully buffered if and only if it can be
determined not to refer to
an interactive device. The error and end-of-file indicators for the
stream are cleared.

But what about append mode "a"? in this case what's the state of the
end-of-file indicator?

The end-of-file indicator for a file opened with mode "a" or "ab" is
irrelevant since input cannot be performed. When open with "a+" or
ab+", then presumably, end-of-file indicator is initially cleared.

[Richard Bos]

ni************@gmail.com wrote:

In fact, I find that :
7 When opened, a stream is fully buffered if and only if it can be
determined not to refer to an interactive device. The error and
end-of-file indicators for the stream are cleared.

But what about append mode "a"? in this case what's the state of the
end-of-file indicator?

Assuming you meant "a+", it's cleared; this becomes obvious once you
realise that the EOF indicator doesn't tell you that your next operation
will read past the end of the file (as it does in Pascal), but that the
previous one did.

Richard

[nicolas.sitbon]

On 6 août, 10:53, [e-mail] (Richard Bos) wrote:

[e-mail] wrote:

In fact, I find that :
7 When opened, a stream is fully buffered if and only if it can be
* determined not to refer to an interactive device. The error and
* end-of-file indicators for the stream are cleared.

But what about append mode "a"? in this case what's the state of the
end-of-file indicator?

Assuming you meant "a+", it's cleared; this becomes obvious once you
realise that the EOF indicator doesn't tell you that your next operation
will read past the end of the file (as it does in Pascal), but that the
previous one did.

Richard

thanks for explanation.

[Barry Schwarz]

On Wed, 06 Aug 2008 08:15:18 +0100, Flash Gordon
<sp**@flash-gordon.me.ukwrote:

>Barry Schwarz wrote, On 06/08/08 03:08:

>On Tue, 05 Aug 2008 13:46:17 -0400, Eric Sosman <Er*********@sun.com>
wrote:

>>Barry Schwarz wrote:
No one said EOF could not be a valid byte. However, putc will never
put a negative value. In the absence of an error, putc returns the
value it puts. Therefore, in the absence of an error, it must return
a positive value. Since EOF is negative, putc cannot return EOF other
than as an error indicator.
Not even when CHAR_MIN<=EOF and UCHAR_MAX>INT_MAX?

CHAR_MIN is irrelevant since the only char at issue is unsigned char.
UCHAR_MIN, if it existed, would have to be 0. putc only puts unsigned
char. In the absence of an error, it will return the value of the
char that was put. That value is unsigned and therefore non-negative.
Since EOF must be negative, the only time EOF can be returned is when
an error is detected. In the case of an error, the value of the
original int to be put is irrelevant.

You have missed the point (although the bit about CHAR_MIN=EOF is
irrelevant I believe). To take a concrete example imagine an
implementation where CHAR_BIT is 16 and sizeof(int)==1 that uses 2s
complement. On this implementation

UCHAR_MAX==65535
INT_MAX=32767
EOF==-1

In the code you to

int ret = putc(EOF,stdout);

-1 is passed to putc.
putc converts it to an unsigned char giving a value of 65535
putc outputs 65535 to stdout (or the file of your choice)
put *attempts* to return 65535, but as it does not fit in an int
(greater than INT_MAX) it cannot. So putc returns the bit-pattern of all
16 bits set (as that is how 65535 is represented in an unsigned char on
this implementation).

In C99 (6.3.1.3-3), when a value is converted to a signed type in
which it will not fit, you get an implementation defined result or an
implementation defined signal. In C89 (3.2.1.2), the result is
implementation defined. What you describe can happen only if the
implementation documents it that way. I wonder if any do.

>All 16 bits set, when interpreted as a 16 bit 2s complement number
(which is what int is on this implementation) is -1.
Therefore, on this implementation, putc returns -1, which is the value
of EOF on this implementation, when -1 (the value of EOF) is passed in
and putc succeeds.

There have previously been long discussions here about whether such a
hosted implementation is conforming. There are definitely a lot of
freestanding implementations with sizeof(int)==1, but they are not
required to provide putc.

--
Remove del for email

[CBFalconer]

ni************@gmail.com wrote:

>
When a file is opened via fopen(), what's the state of the
end-of-file and error indicator? undetermined? cleared? setted?

That depends on the state of the file (including existance) and the
options specified to fopen.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[CBFalconer]

Flash Gordon wrote:

>

.... snip ...

>
You have missed the point (although the bit about CHAR_MIN=EOF is
irrelevant I believe). To take a concrete example imagine an
implementation where CHAR_BIT is 16 and sizeof(int)==1 that uses
2s complement. On this implementation

UCHAR_MAX==65535
INT_MAX=32767
EOF==-1

In the code you to

int ret = putc(EOF,stdout);

-1 is passed to putc.
putc converts it to an unsigned char giving a value of 65535
putc outputs 65535 to stdout (or the file of your choice)
put *attempts* to return 65535, but as it does not fit in an int
(greater than INT_MAX) it cannot. So putc returns the bit-pattern
of all 16 bits set (as that is how 65535 is represented in an
unsigned char on this implementation). All 16 bits set, when
interpreted as a 16 bit 2s complement number (which is what int
is on this implementation) is -1. Therefore, on this
implementation, putc returns -1, which is the value of EOF on
this implementation, when -1 (the value of EOF) is passed in
and putc succeeds.

Error there. putc returns an int. In the above case the
conversion of 65535 to int exceeds the range of an int, and the
result is either implementation or undefined.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[James Kuyper]

CBFalconer wrote:

ni************@gmail.com wrote:

>When a file is opened via fopen(), what's the state of the
end-of-file and error indicator? undetermined? cleared? setted?

That depends on the state of the file (including existance) and the
options specified to fopen.

Citation, please?

7.19.5.3p7 simply says "The error and end-of-file indicators for the
stream are cleared." Is there a statement somewhere else in the standard
that makes the applicability of 7.19.5.3p7 dependent upon either the
state of the file and the options specified to fopen()?

[santosh]

CBFalconer wrote:

ni************@gmail.com wrote:

>>
When a file is opened via fopen(), what's the state of the
end-of-file and error indicator? undetermined? cleared? setted?

That depends on the state of the file (including existance) and the
options specified to fopen.

Is that so? I thought that the end-of-file and error indicators for a
stream that has been newly created are cleared initially.

Section 7.19.5.3 (para 7) from n1256 seems to say this is so.

[Eric Sosman]

Barry Schwarz wrote:

On Tue, 05 Aug 2008 13:46:17 -0400, Eric Sosman <Er*********@sun.com>
wrote:

>Barry Schwarz wrote:

>>No one said EOF could not be a valid byte. However, putc will never
put a negative value. In the absence of an error, putc returns the
value it puts. Therefore, in the absence of an error, it must return
a positive value. Since EOF is negative, putc cannot return EOF other
than as an error indicator.

Not even when CHAR_MIN<=EOF and UCHAR_MAX>INT_MAX?

CHAR_MIN is irrelevant since the only char at issue is unsigned char.
UCHAR_MIN, if it existed, would have to be 0. putc only puts unsigned
char. In the absence of an error, it will return the value of the
char that was put. That value is unsigned and therefore non-negative.
Since EOF must be negative, the only time EOF can be returned is when
an error is detected. In the case of an error, the value of the
original int to be put is irrelevant.

CHAR_MIN is relevant because the condition CHAR_MIN<=EOF
means that there exists some `char' value equal to EOF. When
this negative `char' value is converted to `unsigned char', it
will of course be positive. (I almost wrote "non-negative,"
but I think "positive" is correct here.)

UCHAR_MAX is relevant because the condition UCHAR_MAX>INT_MAX
means there exist some `unsigned char' values that cannot be
represented as `int'. When one of these large positive values is
converted to `int' to become the value returned by putc(), it is
clear that the original large positive value cannot survive the
conversion. The out-of-range conversion produces an implementation-
defined value (I think we can rule out raising a signal, because the
implementation must arrange matters so putc() works), and there is
no requirement that the implementation-defined value be non-negative.

Hence, it is possible for a successful putc() to return a negative
value, and if EOF is within the range of `char' it is possible that
the returned value can equal EOF. (Now that I think of it, the "if"
may be unnecessary: When UCHAR_MAX>INT_MAX I think we can show that
CHAR_MIN==INT_MIN and CHAR_MAX==INT_MAX, hence every `int' value,
including EOF, is in the range of `char'. But maybe not: It might
be possible to have CHAR_MIN==-32767 and INT_MIN==-32768, so I'll
just leave the "if" in place for safety's sake.)

I don't know why you brought up the nonexistent UCHAR_MIN.

--
Er*********@sun.com

[CBFalconer]

James Kuyper wrote:

CBFalconer wrote:

>ni************@gmail.com wrote:

>>When a file is opened via fopen(), what's the state of the
end-of-file and error indicator? undetermined? cleared? setted?

That depends on the state of the file (including existance) and
the options specified to fopen.

Citation, please?

7.19.5.3p7 simply says "The error and end-of-file indicators for
the stream are cleared." Is there a statement somewhere else in
the standard that makes the applicability of 7.19.5.3p7 dependent
upon either the state of the file and the options specified to
fopen()?

Woops. Guess I am using my Pascal knowledge in the wrong place.
There opening a file implies an initial read (for a read file), and
EOF is set for a write file.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Richard]

CBFalconer <cb********@yahoo.comwrites:

James Kuyper wrote:

>CBFalconer wrote:

>>ni************@gmail.com wrote:

When a file is opened via fopen(), what's the state of the
end-of-file and error indicator? undetermined? cleared? setted?

That depends on the state of the file (including existance) and
the options specified to fopen.

Citation, please?

7.19.5.3p7 simply says "The error and end-of-file indicators for
the stream are cleared." Is there a statement somewhere else in
the standard that makes the applicability of 7.19.5.3p7 dependent
upon either the state of the file and the options specified to
fopen()?

Woops. Guess I am using my Pascal knowledge in the wrong place.
There opening a file implies an initial read (for a read file), and
EOF is set for a write file.

Pascal knowledge?!?!?!?!

LOL

[Flash Gordon]

Barry Schwarz wrote, On 06/08/08 10:24:

On Wed, 06 Aug 2008 08:15:18 +0100, Flash Gordon
<sp**@flash-gordon.me.ukwrote:

>Barry Schwarz wrote, On 06/08/08 03:08:

>>On Tue, 05 Aug 2008 13:46:17 -0400, Eric Sosman <Er*********@sun.com>
wrote:

Barry Schwarz wrote:
No one said EOF could not be a valid byte. However, putc will never
put a negative value. In the absence of an error, putc returns the
value it puts. Therefore, in the absence of an error, it must return
a positive value. Since EOF is negative, putc cannot return EOF other
than as an error indicator.
Not even when CHAR_MIN<=EOF and UCHAR_MAX>INT_MAX?
CHAR_MIN is irrelevant since the only char at issue is unsigned char.
UCHAR_MIN, if it existed, would have to be 0. putc only puts unsigned
char. In the absence of an error, it will return the value of the
char that was put. That value is unsigned and therefore non-negative.
Since EOF must be negative, the only time EOF can be returned is when
an error is detected. In the case of an error, the value of the
original int to be put is irrelevant.

You have missed the point (although the bit about CHAR_MIN=EOF is
irrelevant I believe). To take a concrete example imagine an
implementation where CHAR_BIT is 16 and sizeof(int)==1 that uses 2s
complement. On this implementation

UCHAR_MAX==65535
INT_MAX=32767
EOF==-1

In the code you to

int ret = putc(EOF,stdout);

-1 is passed to putc.
putc converts it to an unsigned char giving a value of 65535
putc outputs 65535 to stdout (or the file of your choice)
put *attempts* to return 65535, but as it does not fit in an int
(greater than INT_MAX) it cannot. So putc returns the bit-pattern of all
16 bits set (as that is how 65535 is represented in an unsigned char on
this implementation).

In C99 (6.3.1.3-3), when a value is converted to a signed type in
which it will not fit, you get an implementation defined result or an
implementation defined signal. In C89 (3.2.1.2), the result is
implementation defined. What you describe can happen only if the
implementation documents it that way. I wonder if any do.

I'm not aware of any implementations that raise a signal but I am aware
of implementations where sizeof(int)==1. I also happen to know that the
one I used a lot would on converting from unsigned to signed just do a
re-interpretation of the bits and therefore 65535 *would* become -1 (as
it did not raise a signal this behaviour would have to be defined).
However, it was not a hosted implementation and so was not bound to
provide putc (or if providing it was not bound to provide one meeting
the requirements of putc on a hosted implementation).

<snip>
--
Flash Gordon

[Flash Gordon]

CBFalconer wrote, On 06/08/08 13:40:

Flash Gordon wrote:
... snip ...

>You have missed the point (although the bit about CHAR_MIN=EOF is
irrelevant I believe). To take a concrete example imagine an
implementation where CHAR_BIT is 16 and sizeof(int)==1 that uses
2s complement. On this implementation

^^^^^^^^^^^^^^^^^^^^^^

<snip>

>is on this implementation) is -1. Therefore, on this
implementation, putc returns -1, which is the value of EOF on
this implementation, when -1 (the value of EOF) is passed in
and putc succeeds.

Error there.

No.

putc returns an int.

Yes, as I at least implied as why else would I be talking about the size
of int?

In the above case the
conversion of 65535 to int exceeds the range of an int, and the
result is either implementation or undefined.

So? I was *explicitly* talking about an implementation which does what I
described and by your own admission above an implementation is *allowed*
to define the behaviour. So unless you are claiming that an
implementation is not allowed to define the behaviour as being what
probably most implementations with sizeof(int)==1 actually do I don't
see your point.
--
Flash Gordon

[Antoninus Twink]

On 6 Aug 2008 at 18:04, Richard wrote:

CBFalconer <cb********@yahoo.comwrites:

>Guess I am using my Pascal knowledge in the wrong place. There
opening a file implies an initial read (for a read file), and EOF is
set for a write file.

Pascal knowledge?!?!?!?!

LOL

Unbelievable, isn't it? I mean, you simply couldn't make it up: CBF
takes a view of topicality so strict that even Harold "the machine" van
Dijk slams him for narrow-mindedness, but then somehow thinks it's a
good idea to answer a question about C with information on file-handling
in Pascal. Incredible.

[CBFalconer]

Flash Gordon wrote:

>
CBFalconer wrote, On 06/08/08 13:40:

.... snip ...

>

> putc returns an int.

Yes, as I at least implied as why else would I be talking about
the size of int?

>In the above case the conversion of 65535 to int exceeds the
range of an int, and the result is either implementation or
undefined.

So? I was *explicitly* talking about an implementation which
does what I described and by your own admission above an
implementation is *allowed* to define the behaviour. So unless
you are claiming that an implementation is not allowed to define
the behaviour as being what probably most implementations with
sizeof(int)==1 actually do I don't see your point.

For example the system may crash, may signal, etc. The point is
that the action is not predictable and thus the code is not
portable.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[santosh]

CBFalconer wrote:

Flash Gordon wrote:

>>
CBFalconer wrote, On 06/08/08 13:40:

... snip ...

>>

>> putc returns an int.

Yes, as I at least implied as why else would I be talking about
the size of int?

>>In the above case the conversion of 65535 to int exceeds the
range of an int, and the result is either implementation or
undefined.

So? I was *explicitly* talking about an implementation which
does what I described and by your own admission above an
implementation is *allowed* to define the behaviour. So unless
you are claiming that an implementation is not allowed to define
the behaviour as being what probably most implementations with
sizeof(int)==1 actually do I don't see your point.

For example the system may crash, may signal, etc. The point is
that the action is not predictable and thus the code is not
portable.

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.

[Flash Gordon]

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

CBFalconer wrote:

>Flash Gordon wrote:

>>CBFalconer wrote, On 06/08/08 13:40:

... snip ...

>>> putc returns an int.
Yes, as I at least implied as why else would I be talking about
the size of int?

In the above case the conversion of 65535 to int exceeds the
range of an int, and the result is either implementation or
undefined.
So? I was *explicitly* talking about an implementation which
does what I described and by your own admission above an
implementation is *allowed* to define the behaviour. So unless
you are claiming that an implementation is not allowed to define
the behaviour as being what probably most implementations with
sizeof(int)==1 actually do I don't see your point.

For example the system may crash, may signal, etc. The point is
that the action is not predictable and thus the code is not
portable.

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.
--
Flash Gordon

[santosh]

Flash Gordon wrote:

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

>CBFalconer wrote:

>>Flash Gordon wrote:
CBFalconer wrote, On 06/08/08 13:40:

... snip ...
putc returns an int.
Yes, as I at least implied as why else would I be talking about
the size of int?

In the above case the conversion of 65535 to int exceeds the
range of an int, and the result is either implementation or
undefined.
So? I was *explicitly* talking about an implementation which
does what I described and by your own admission above an
implementation is *allowed* to define the behaviour. So unless
you are claiming that an implementation is not allowed to define
the behaviour as being what probably most implementations with
sizeof(int)==1 actually do I don't see your point.
For example the system may crash, may signal, etc. The point is
that the action is not predictable and thus the code is not
portable.

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.

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.

[CBFalconer]

santosh wrote:

CBFalconer wrote:

.... snip ...

>

>For example the system may crash, may signal, etc. The point is
that the action is not predictable and thus the code is not
portable.

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.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[santosh]

CBFalconer wrote:

santosh wrote:

>CBFalconer wrote:

... snip ...

>>

>>For example the system may crash, may signal, etc. The point is
that the action is not predictable and thus the code is not
portable.

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.

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]

On Aug 7, 10:52 am, CBFalconer <[e-mail]:

santosh wrote:

CBFalconer wrote:

... snip ...

For example the system may crash, may signal, etc. The point is
that the action is not predictable and thus the code is not
portable.

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.

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

[vippstar]

On Aug 7, 11:09 am, santosh <[e-mail]:
<snip>

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]

CBFalconer <cb********@yahoo.comwrites:

santosh wrote:

>CBFalconer wrote:

... snip ...

>>

>>For example the system may crash, may signal, etc. The point is
that the action is not predictable and thus the code is not
portable.

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.

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Antoninus Twink]

On 7 Aug 2008 at 7:52, CBFalconer wrote:

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

On 7 Aug 2008 at 7:57, CBFalconer wrote:

santosh wrote:

A clock cannot be right twice a day.

A conventional one, with a face and hands, will be if stopped.