getc and "large" bytes

[vippstar]

Assuming all the values of int are in the range of unsigned char, what
happends if getc returns EOF?
Is it possible that EOF was the value of the byte read?
Does that mean that code aiming for maximum portability needs to check
for both feof() and ferror()?
(for example, if both feof() and ferror() return 0 for the stream when
getc() returned EOF, consider EOF a valid byte read)
To me, that seems to be the case, but maybe the standard says this to
be incorrect.

As always, all replies appreciated.

[Richard Heathfield]

Bartc said:

>
"Ben Pfaff" <bl*@cs.stanfor d.eduwrote in message

<snip>

>-1 is in the range of int.
-1 is not in the range of unsigned char.
Therefore it is not true that all the values of int are in the
range of unsigned char.

The OP mentioned an example where both might be 16 bits.

That doesn't affect Ben's counter-example (or my range of counter-examples,
presented earlier).

So -1 in one
could be 0xFFFF in the other, causing ambiguity

There is no ambiguity here. 0xFFFF is an integer constant with the value
65535. This is not equal to -1.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Keith Thompson]

"Bartc" <[e-mail] rites:

"Ben Pfaff" <bl*@cs.stanfor d.eduwrote in message
news:87******** ****@blp.benpfa ff.org...

>vi******@gmail. com writes:

>>On May 23, 6:35 pm, Ben Pfaff <[e-mail] rd.eduwrote:
vipps...@gma il.com writes:
Assuming all the values of int are in the range of unsigned char, what
happends if getc returns EOF?

Your assumption is false.
Would you please elaborate?

-1 is in the range of int.
-1 is not in the range of unsigned char.
Therefore it is not true that all the values of int are in the
range of unsigned char.

The OP mentioned an example where both might be 16 bits. So -1 in one could
be 0xFFFF in the other, causing ambiguity in the (I think unlikely) event of
reading a 16-bit character 0xFFFF from a file with 16-bit encoding.

No, -1 and 0xFFFF are two different values. It's possible that one of
those values is the result of converting the other.

(How would such a character size read standard 8-bit files? By
zero-extending to 16?)

It would be implementation-defined, or perhaps undefined.

For such an implementation to see an 8-bit file, the file would have
to have been copied to the system, or at least made visible somehow.
Such copying might necessarily involve some sort of conversion. The
conversion is outside the scope of C.

--
Keith Thompson (The_Other_Keit h) 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"

[Keith Thompson]

Eric Sosman <Er*********@su n.comwrites:
[...]

It seems to me that the behavior required of getc() places
far-reaching requirements on implementations where `int' and
`char' have the same width. Here are a few:

1) Since `unsigned char' can represent 2**N distinct values
and all of these must be distinguishable when converted to `int',
it follows that `int' must also have 2**N distinct values. Thus,
signed-magnitude and ones' complement representations are ruled
out, and INT_MIN must have its most negative possible value
(that is, INT_MIN == -INT_MAX - 1, all-bits-set cannot be a trap
representation) .

[...]

How do you conclude that all 2**N distinct values of type unsigned
char must be distinguishable when converted to int? The result of the
conversion is implementation-defined. If, for example, int has the
range -32768 .. +32767, and unsigned char has the range 0 .. 65536, I
see nothing in the standard that forbids converting all unsigned char
values greater than 32767 to 32767 (saturation). It would break
stdio, but I'm not convinced that that would make it non-conforming
(particularly for a freestanding implementation that needn't provide
stdio).

--
Keith Thompson (The_Other_Keit h) 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"

[Richard Tobin]

In article <ln************ @nuthaus.mib.or g>,
Keith Thompson <ks***@mib.orgw rote:

>In my opinion, it would be reasonable for the standard to require
INT_MAX >= UCHAR_MAX for all hosted implementations .

An implementation with, say, 16-bit ints and chars is still likely to
have 8-bit data on disk and most other input sources. In which case
fgetc() could read 8-bit values, and have no problem. At least, I
don't konw of anything in the standard that prevents this.

One can imagine a future implementation that uses UTF-32-encoded
Unicode characters, and has 32-bit chars. In that case there is no
problem with text (because Unicode in fact only goes up to about
2^20), but binary data would still have the problem.

-- Richard
--
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)

[Richard Tobin]

In article <NH************ *****@text.news .virginmedia.co m>,
Bartc <[e-mail] rote:

>The OP mentioned an example where both might be 16 bits. So -1 in one could
be 0xFFFF in the other, causing ambiguity in the (I think unlikely) event of
reading a 16-bit character 0xFFFF from a file with 16-bit encoding.

There is a problem with chars and ints of equal size, but the OP
expressed it wrongly: he talked about "all the values of int [being]
in the range of unsigned char" - which can't happen, because negative
ints aren't in the range of unsigned char. The right way to put it is
that some of the values of unsigned char are not representable as int.

-- Richard
--
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)

[Eric Sosman]

Keith Thompson wrote:

Eric Sosman <Er*********@su n.comwrites:
[...]

> It seems to me that the behavior required of getc() places
far-reaching requirements on implementations where `int' and
`char' have the same width. Here are a few:

1) Since `unsigned char' can represent 2**N distinct values
and all of these must be distinguishable when converted to `int',
it follows that `int' must also have 2**N distinct values. Thus,
signed-magnitude and ones' complement representations are ruled
out, and INT_MIN must have its most negative possible value
(that is, INT_MIN == -INT_MAX - 1, all-bits-set cannot be a trap
representation ).

[...]

How do you conclude that all 2**N distinct values of type unsigned
char must be distinguishable when converted to int? The result of the
conversion is implementation-defined. If, for example, int has the
range -32768 .. +32767, and unsigned char has the range 0 .. 65536, I
see nothing in the standard that forbids converting all unsigned char
values greater than 32767 to 32767 (saturation). It would break
stdio, but I'm not convinced that that would make it non-conforming
(particularly for a freestanding implementation that needn't provide
stdio).

My case for distinguishabil ity was in the part you snipped,
labeled "1a)". It derives from the Standard's requirement that
bytes read back from a binary stream must compare equal to those
written to it (on the same implementation, not counting trailing
zeroes, et cetera). If there are fewer `int' values than there
are `unsigned char' values, then by the pigeonhole principle there
must be at least one collision where two distinct `unsigned char'
values V1 and V2 convert to the same `int' value. Then this
code fragment

putc(V1, stream);
putc(V2, stream);
rewind(stream);
assert(getc(str eam) == V1);
assert(getc(str eam) == V2);

.... cannot succeed. (Yes, I know, it's very bad to generate
side-effects in an assert(), but this is just for illustration.)

"Upon further review," as they say in American football, I
guess an implementation could choose to report an I/O error if
it ever encountered V2, say, on input. (If "helpful," it would
also report an error for any attempt to write V2.) That would
give an extremely low QoI, but the Standard does not forbid I/O
operations from failing "predictabl y." (Indeed, on many systems
fopen("/", "w") will fail predictably.) So perhaps a sufficiently
bad implementation could in fact claim conformance even if unable
to read and write all `unsigned char' values, and this would allow
signed magnitude and ones' complement (and two's complement with
one trap representation) .

And, of course, no argument based on the behavior of getc()
has any force for freestanding implementations .

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

[Bartc]

"Keith Thompson" <ks***@mib.orgw rote in message
news:ln******** ****@nuthaus.mi b.org...

"Bartc" <[e-mail] rites:

>"Ben Pfaff" <bl*@cs.stanfor d.eduwrote in message
news:87******* *****@blp.benpf aff.org...

>>vi******@gmail. com writes:

On May 23, 6:35 pm, Ben Pfaff <[e-mail] rd.eduwrote:
vipps...@gm ail.com writes:
Assuming all the values of int are in the range of unsigned char,
what
happends if getc returns EOF?
>
Your assumption is false.
Would you please elaborate?

-1 is in the range of int.
-1 is not in the range of unsigned char.
Therefore it is not true that all the values of int are in the
range of unsigned char.

The OP mentioned an example where both might be 16 bits. So -1 in one
could
be 0xFFFF in the other, causing ambiguity in the (I think unlikely) event
of
reading a 16-bit character 0xFFFF from a file with 16-bit encoding.

No, -1 and 0xFFFF are two different values. It's possible that one of
those values is the result of converting the other.

I don't understand. In a 16-bit system where all 65536 bit patterns might
represent characters, what bit pattern would you use to signal EOF?

(Reading Eric's first post:

An implication of (1) for the programmer is that yes, there
will be a legitimate `unsigned char' value that maps to EOF
when converted to `int'.

this seems to suggest that yes an ambiguity can occur.)

--
bartc

[Keith Thompson]

"Bartc" <[e-mail] rites:

"Keith Thompson" <ks***@mib.orgw rote in message
news:ln******** ****@nuthaus.mi b.org...

>"Bartc" <[e-mail] rites:

[...]

>>The OP mentioned an example where both might be 16 bits. So -1 in
one could be 0xFFFF in the other, causing ambiguity in the (I
think unlikely) event of reading a 16-bit character 0xFFFF from a
file with 16-bit encoding.

No, -1 and 0xFFFF are two different values. It's possible that one of
those values is the result of converting the other.

I don't understand. In a 16-bit system where all 65536 bit patterns might
represent characters, what bit pattern would you use to signal EOF?

Bit patterns are not values. A value is an *interpretation * of a bit
pattern; the interpretation is done with respect to a specified type.

For example, an object of type float with the value 123.0 and an
object of type unsigned int with the value 0x42f60000 might happen to
contain the same bit pattern, but they have distinct values because
those bit patterns (representation s) are interpreted as having
different types.

(Reading Eric's first post:

> An implication of (1) for the programmer is that yes, there
will be a legitimate `unsigned char' value that maps to EOF
when converted to `int'.

this seems to suggest that yes an ambiguity can occur.)

Yes.

--
Keith Thompson (The_Other_Keit h) 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"

[Walter Roberson]

In article <ln************ @nuthaus.mib.or g>,
Keith Thompson <ks***@mib.orgw rote:

>Bit patterns are not values. A value is an *interpretation * of a bit
pattern; the interpretation is done with respect to a specified type.

Not in C: in C, a bit pattern is a *representation * of a value.
A machine doesn't have to use real bits (binary digits) as long as
the operators produce the right -values-.

(Though, I'd want to have another look over the wording on
floating point representations , as I seem to recall that that
wording could be interpreted as requiring Real Bits (SM).)
--
"Walter is undoubtedly the country's and club's most popular player."
-- vitalfootball.c o.uk

[lawrence.jones]

Richard Tobin <ri*****@cogsci .ed.ac.ukwrote:

>
An implementation with, say, 16-bit ints and chars is still likely to
have 8-bit data on disk and most other input sources. In which case
fgetc() could read 8-bit values, and have no problem. At least, I
don't konw of anything in the standard that prevents this.

Writing a byte with fputc() and then reading it back with fgetc() must
produce the same value. That won't happen if you only write or read
half the bits.

-- Larry Jones

It must be sad being a species with so little imagination. -- Calvin