Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #163515

Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF''

From Meredith Montgomery <mmontgomery@levado.to>
Newsgroups comp.lang.c
Subject Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF''
Date 2021-11-19 18:14 -0300
Organization Aioe.org NNTP Server
Message-ID <86ee7bkfv6.fsf@levado.to> (permalink)
References <86pmqwkm7u.fsf@levado.to> <878rxjq4l9.fsf@nosuchdomain.example.com>

Show all headers | View raw

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Meredith Montgomery <mmontgomery@levado.to> writes:
>> I did not get Brian Kernighan's concern with setting EOF to a char c.
>> The context is
>>
>>   char c = getchar();
>>
>> And Kernighan says:
>>
>> --8<---------------cut here---------------start------------->8---
>> We must declare c to be a type big enough to hold any value that getchar
>> returns. We can't use char since c must be big enough to hold EOF in
>> addition to any possible char . Therefore we use int.
>> --8<---------------cut here---------------end--------------->8---
>>
>>
>> I'm trying to justify this using C99's document.  Here's what I find.
>>
>> --8<---------------cut here---------------start------------->8---
>> Section 6.25 Types
>> [...]
>>
>> 3. An object declared as type char is large enough to store any member
>> of the basic execution character set. If a member of the basic execution
>> character set is stored in a char object, its value is guaranteed to be
>> positive.  If any other character is stored in a char object, the
>> resulting value is implementation-defined but shall be within the range
>> of values that can be represented in that type.
>> --8<---------------cut here---------------end--------------->8---
>>
>> So I can't be sure a char would always be signed, for example.  I can't
>> be sure EOF would fit in a char.
>>
>> Am I looking at the right place, thinking the right thing?  Thank you.
>
> Yes, that's pretty much it -- except that the same issue applies (with
> some differences) whether plain char is signed or unsigned.
>
> For simplicity, assume CHAR_BIT==8, 2's-complement for signed types, and
> EOF==-1.  Then a char object can hold any of exactly 256 distinct
> values, either 0..255 or -128..127.
>
> A call to getchar() can return any of exactly 257 distinct values.  If
> it succeeds, the result is in the range 0..255.  If it fails, it returns
> EOF.  (A cleaner design choice might have been to separate the data from
> the status, but C does it this way and we're stuck with it.)
>
> Suppose you (unwisely) store the result of getchar() in a char:
>
>     char c = getchar();
>
> If char is signed and getchar() returns EOF, then c==-1 -- but -1 could
> also be a valid character value.  The test (c == EOF) will succeed if
> you read a valid character with the value -1.
>
> If char is unsigned and getchar() returns EOF, then c==255 -- and again,
> 255 could be a valid character value.  But now the test (c == EOF) will
> never succeed, because the converted value is no longer equal to EOF.
> (In the 8-bit Latin-1 character set, character 255 is 'ΓΏ').
>
> The byte value 0xff never appears in valid UTF-8, but of course it can
> easily appear in binary data.
>
> Note that if you have an exotic implementation with CHAR_BIT==16 and
> sizeof(int)==1, storing the result of getchar() in an int still doesn't
> let you distinguish between EOF and a valid character with the same
> value.  In practice, you probably wouldn't be doing normal character
> input on such a system (which is likey to be a DSP).  But if you had to,
> you could call feof() and ferror() after the getchar() call to determine
> whether the EOF value is an actual end-of-file indicator or a valid
> 16-bit character.

Thank you the careful description of what could happen in each case ---
and for the example of the DSP system, which appears to be a hardware by
Texas Instruments.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Meredith Montgomery <mmontgomery@levado.to> - 2021-11-19 15:57 -0300
  Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-11-19 12:21 -0800
    Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Meredith Montgomery <mmontgomery@levado.to> - 2021-11-19 18:14 -0300
      Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-11-19 14:10 -0800
        Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Meredith Montgomery <mmontgomery@levado.to> - 2021-11-20 17:30 -0300
        Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' scott@slp53.sl.home (Scott Lurndal) - 2021-11-21 16:01 +0000
    Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Philipp Klaus Krause <pkk@spth.de> - 2021-11-22 11:23 +0100
      Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-11-22 12:55 -0800
        Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Philipp Klaus Krause <pkk@spth.de> - 2021-11-23 17:04 +0100
          Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-11-23 09:43 -0800
            Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Philipp Klaus Krause <pkk@spth.de> - 2021-11-24 11:26 +0100
              Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-10 01:41 -0800
                Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' David Brown <david.brown@hesbynett.no> - 2021-12-10 14:40 +0100
  Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Barry Schwarz <schwarzb@delq.com> - 2021-11-19 12:22 -0800
    Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Meredith Montgomery <mmontgomery@levado.to> - 2021-11-19 18:10 -0300
    Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' David Brown <david.brown@hesbynett.no> - 2021-11-20 13:24 +0100
      Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Meredith Montgomery <mmontgomery@levado.to> - 2021-11-20 17:32 -0300
  Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Mark Bluemel <mark.bluemel@gmail.com> - 2021-11-22 00:27 -0800
  Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Mark Bluemel <mark.bluemel@gmail.com> - 2021-11-22 00:34 -0800
    Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-11-22 02:04 -0800
      Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Mark Bluemel <mark.bluemel@gmail.com> - 2021-11-22 02:46 -0800
      Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-11-22 21:22 -0800
        Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-11-22 22:03 -0800
          Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' scott@slp53.sl.home (Scott Lurndal) - 2021-11-23 14:52 +0000
  Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Dave Dunfield <dave.dunfield@gmail.com> - 2021-11-26 07:31 -0800
    Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Dave Dunfield <dave.dunfield@gmail.com> - 2021-12-08 07:26 -0800
      Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-12-08 12:16 -0800
        Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Dave Dunfield <dave.dunfield@gmail.com> - 2021-12-08 18:59 -0800
          Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-08 19:23 -0800
            Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Dave Dunfield <dave.dunfield@gmail.com> - 2021-12-09 06:30 -0800
              Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Manfred <noname@add.invalid> - 2021-12-09 16:10 +0100
              Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-09 16:05 +0000
                Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Bart <bc@freeuk.com> - 2021-12-09 17:41 +0000
                Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Dave Dunfield <dave.dunfield@gmail.com> - 2021-12-09 12:24 -0800
                Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-09 22:59 +0000
                Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-09 21:26 +0000
                Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Bart <bc@freeuk.com> - 2021-12-09 22:37 +0000
                Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-09 23:09 +0000
              Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-10 01:58 -0800
                Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-12-10 10:46 -0800
                Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-12 08:21 -0800
          Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Paul <nospam@needed.invalid> - 2021-12-09 10:31 -0500
            Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-12-09 13:32 -0800
          Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' luser droog <luser.droog@gmail.com> - 2021-12-09 17:08 -0800
            Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Dave Dunfield <dave.dunfield@gmail.com> - 2021-12-10 12:45 -0800
              Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Manfred <noname@add.invalid> - 2021-12-11 19:17 +0100
              Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Bart <bc@freeuk.com> - 2021-12-11 23:19 +0000
              Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-15 00:31 -0800
      Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Mark Bluemel <mark.bluemel@gmail.com> - 2021-12-09 02:26 -0800
        Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Bart <bc@freeuk.com> - 2021-12-09 11:20 +0000
          Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Dave Dunfield <dave.dunfield@gmail.com> - 2021-12-09 06:50 -0800
  Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-12-08 20:00 -0800
  Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' Kaz Kylheku <480-992-1380@kylheku.com> - 2021-12-12 18:55 +0000
    Re: K&R, 2nd edition, Brian's concerns with ``char c = EOF'' James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-12-12 14:38 -0500

csiph-web