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.

[Ben Pfaff]

vi******@gmail. 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.
--
Ben Pfaff
http://benpfaff.org

[vippstar]

On May 23, 6:35 pm, Ben Pfaff <[e-mail] rd.eduwrote:

vipps...@gmail. 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?

[Richard Heathfield]

vi******@gmail. com said:

On May 23, 6:35 pm, Ben Pfaff <[e-mail] rd.eduwrote:

>vipps...@gmail .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?

The int type must be able to represent values in the range INT_MIN to -1,
none of which values are in the range of unsigned char (which, lacking a
sign bit, cannot represent negative values).

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

[vippstar]

On May 23, 6:42 pm, Richard Heathfield <[e-mail].i nvalidwrote:

vipps...@gmail. com said:

On May 23, 6:35 pm, Ben Pfaff <[e-mail] rd.eduwrote:

vipps...@gmail. 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?

The int type must be able to represent values in the range INT_MIN to -1,
none of which values are in the range of unsigned char (which, lacking a
sign bit, cannot represent negative values).

I'm talking about the case that both int and unsigned char are 16
bits, and to be honest I'm still not convinced that this is false.

[Richard Tobin]

In article <c9************ *************** *******@e39g200 0hsf.googlegrou ps.com>,
<vi******@gmail .comwrote:

>Assuming all the values of int are in the range of unsigned char, what
happends if getc returns EOF?

If int and char are the same size, and all possible unsigned char
values can be read, then it is possible that getc() will attempt to
convert to an int a value which cannot be represented as one. This is
implementation-defined. Assuming it works in the usual way, it may
return a negative integer equal to EOF.

>Does that mean that code aiming for maximum portability needs to check
for both feof() and ferror()?

Yes, but it seems to me that undefined behaviour is involved.

For maximum portability, don't use machines like that :-)

-- 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]

vi******@gmail. com wrote:

On May 23, 6:42 pm, Richard Heathfield <[e-mail].i nvalidwrote:

>vipps...@gmail .com said:

>>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?

The int type must be able to represent values in the range INT_MIN to -1,
none of which values are in the range of unsigned char (which, lacking a
sign bit, cannot represent negative values).

I'm talking about the case that both int and unsigned char are 16
bits, and to be honest I'm still not convinced that this is false.

Then you didn't express quite what you meant.

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

1a) "Must be distinguishable when converted" follows from
7.19.2p3's promise that data read from a binary stream must
compare equal to the data written. If two different characters
mapped to the same `int', this promise couldn't be kept.

2) Converting a too-large `unsigned char' to `int' must
not raise a signal. (At least, it must not do so when getc()
performs the conversion; it's possible that an "open-code"
conversion would behave differently.)

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'. Hence, a maximally portable program
cannot assume that the value EOF indicates a getc() failure;
it must go on to check both feof() and ferror():

int ch = getc(stream);
if (ch == EOF) {
if (feof(stream))
return ALL_DONE;
if (ferror(stream) )
return ALL_FU;
}
return ALLS_WELL; /* even if ch == EOF */

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

[Ben Pfaff]

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

On May 23, 6:35 pm, Ben Pfaff <[e-mail] rd.eduwrote:

>vipps...@gmail .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.
--
char a[]="\n .CJacehknorstu" ;int putchar(int);in t main(void){unsi gned long b[]
={0x67dffdff,0x 9aa9aa6a,0xa77f fda9,0x7da6aa6a ,0xa67f6aaa,0xa a9aa9f6,0x11f6} ,*p
=b,i=24;for(;p+ =!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)bre ak;else default:continu e;if(0)case 1:putchar(a[i&15]);break;}}}

[Bartc]

"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...@gmai l.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.

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

--
Bartc

[Keith Thompson]

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

On May 23, 6:42 pm, Richard Heathfield <[e-mail].i nvalidwrote:

>vipps...@gmail .com said:

On May 23, 6:35 pm, Ben Pfaff <[e-mail] rd.eduwrote:
vipps...@gmail .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?

The int type must be able to represent values in the range INT_MIN to -1,
none of which values are in the range of unsigned char (which, lacking a
sign bit, cannot represent negative values).

I'm talking about the case that both int and unsigned char are 16
bits, and to be honest I'm still not convinced that this is false.

Your underlying point is right; you just stated it incorrectly. The
problem occurs when not all values of unsigned char are in the range
of int.

The value returned by getc() is either the next character from the
input stream, interpreted as an unsigned char and converted to int, or
the value EOF (which must be negative and is typically -1).

On most systems, all values of type unsigned char can be converted to
int without changing their numeric value.

If both int and unsigned char are 16 bits, then (a) the conversion
from unsigned char to int is implementation-defined for values
numerically greater than INT_MAX, and (b) some valid unsigned char
value might be converted to the value EOF.

You can work around (b) by checking feof() and ferror() after getc()
returns EOF. If both are false, then you can assume that you read a
legimate character (say, 0xFFFF) that happened to be converted to EOF
(or that there's a bug in the implementation' s feof() or ferror()
function, which might be almost as likely). Most programmers don't
bother to worry about this possibility. As a result, some code will
likely break if ported to such a system (most likely a DSP, which
probably has a freestanding implementation anyway and thus needn't
support <stdio.hat all) *if* it happens to read such a character.

(a) the implementation-definedness of the conversion, could be a more
serious problem. Given this problem, I can't think of a way to write
*really* portable code to read from a file.

fread() is likely to copy the input directly into an array of
characters, and thus probably won't run into the same problem -- but
fread() is defined to work by calling fgetc(), so the standard doesn't
guarantee that you won't run into exactly the same problem.

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

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