Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Reading beyond the end of file Date: Mon, 05 Oct 2015 15:24:55 -0700 Organization: None to speak of Lines: 34 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="11173"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18w96F0/efOOODk1d4Pib5i" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:M7FtlDSzmLl0gKdvLP7drEltmTY= sha1:wbx/VqwamFXjE4/dXr20DDhJimk= Xref: csiph.com comp.lang.c:72008 supercat@casperkitty.com writes: > On Monday, October 5, 2015 at 1:59:45 PM UTC-5, Keith Thompson wrote: >> Another problem is that the input character is treated as an unsigned >> char and converted to signed int. If unsigned char fits in the range of >> signed int, that's not a problem. But if not, and if you read a >> character with a value exceeding INT_MAX, then the conversion to int >> yields an implementation-defined result or raises an >> implementation-defined signal. Probably the conversion will do the >> typical 2's-complement wraparound, but if it doesn't, hilarity ensues. > > If James Kuyper's citation of 7.21.2p3 is accurate, I would think that any > platform where UCHAR_MAX > INT_MAX would be required to use an "int" type > which supported a value which behaved as -INT_MAX-1. I think it might be > possible for a ones'-complement or sign-magnitude implementation to meet > the requirement if the bit pattern for "negative zero" was never generated > by any calculations within the range of "int" but was produced by trying to > convert "INT_MAX+1U" to "int", and if converting that value to "unsigned" > yielded "INT_MAX+1U". Yes, James raised some points that I hadn't thought of. The required behavior for stdio seems to impose some additional requirements on how certain integer conversions behave. Note that that's relevant only for implementations with UCHAR_MAX > INT_MAX. As I mentioned elsethread, there are currently very few such impementations, and as far as I know they're all freestanding (which means they needn't support stdio, which means the additional requirement don't apply.) -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"