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

Groups > comp.lang.c > #163505 > unrolled thread

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

Back to article view | Back to comp.lang.c

Contents

  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

Page 1 of 3  [1] 2 3  Next page →

#163505 — K&R, 2nd edition, Brian's concerns with ``char c = EOF''

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.

[toc] | [next] | [standalone]

#163509

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.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#163515

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.

[toc] | [prev] | [next] | [standalone]

#163517

Meredith Montgomery <mmontgomery@levado.to> writes:
[...]
> 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.

DSP (Digital Signal Processor) is a generic term for a kind of
specialized microprocessor chip.  TI makes them, but so do other
manufacturers.

I've never worked with them myself.  They're of interest in the context
of C mainly because they're perhaps the only kind of modern system
likely to have a C implementation with CHAR_BIT != 8.

https://en.wikipedia.org/wiki/Digital_signal_processor

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#163527

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

> Meredith Montgomery <mmontgomery@levado.to> writes:
> [...]
>> 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.
>
> DSP (Digital Signal Processor) is a generic term for a kind of
> specialized microprocessor chip.  TI makes them, but so do other
> manufacturers.

Thanks!

> I've never worked with them myself.  They're of interest in the context
> of C mainly because they're perhaps the only kind of modern system
> likely to have a C implementation with CHAR_BIT != 8.

Thank you!  So, yes, it's an excellent example for the context.

> https://en.wikipedia.org/wiki/Digital_signal_processor

Thanks!

[toc] | [prev] | [next] | [standalone]

#163550

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Meredith Montgomery <mmontgomery@levado.to> writes:
>[...]
>> 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.
>
>DSP (Digital Signal Processor) is a generic term for a kind of
>specialized microprocessor chip.  TI makes them, but so do other
>manufacturers.

Tensilica, Ceva and a handful of others.

>
>I've never worked with them myself.  They're of interest in the context
>of C mainly because they're perhaps the only kind of modern system
>likely to have a C implementation with CHAR_BIT != 8.

They're also more likely to have a Harvard Architecture.

[toc] | [prev] | [next] | [standalone]

#163563

Am 19.11.21 um 21:21 schrieb Keith Thompson:

> 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.
Many such implementations, however do use 8-bit octets for interfacing
with the outside world. I.e. on such ain implementation even where
CHAR_MAX >= 256, getchar will still always return either a value in the
range [0, 255] or EOF.

Philipp

[toc] | [prev] | [next] | [standalone]

#163572

Philipp Klaus Krause <pkk@spth.de> writes:
> Am 19.11.21 um 21:21 schrieb Keith Thompson:
>> 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.
> Many such implementations, however do use 8-bit octets for interfacing
> with the outside world. I.e. on such ain implementation even where
> CHAR_MAX >= 256, getchar will still always return either a value in the
> range [0, 255] or EOF.

Interesting.  That's likely to be non-conforming, since for example you
should be able to write a byte value of 0xABCD to a stream and read it
back as 0xABCD (N1570 7.21.2) -- but useful and non-conforming is
sometimes better than conforming.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#163600

Am 22.11.21 um 21:55 schrieb Keith Thompson:
> but useful and non-conforming is
> sometimes better than conforming.
> 

A 16-bit ptrdiff_t on a freestanding implementation that does not
support objects bigger than (1 << 15) would be another common example.
Though that is only nonconforming for C99, C11 and C17, but valid C90,
C95 and C23.

[toc] | [prev] | [next] | [standalone]

#163610

Philipp Klaus Krause <pkk@spth.de> writes:
> Am 22.11.21 um 21:55 schrieb Keith Thompson:
>> but useful and non-conforming is
>> sometimes better than conforming.
>
> A 16-bit ptrdiff_t on a freestanding implementation that does not
> support objects bigger than (1 << 15) would be another common example.
> Though that is only nonconforming for C99, C11 and C17, but valid C90,
> C95 and C23.

How would it be valid C23?  The N2731 draft defines PTRDIFF_WIDTH in
<stdint.h> and requires it to be at least 17.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#163638

Am 23.11.21 um 18:43 schrieb Keith Thompson:
> Philipp Klaus Krause <pkk@spth.de> writes:
>> Am 22.11.21 um 21:55 schrieb Keith Thompson:
>>> but useful and non-conforming is
>>> sometimes better than conforming.
>>
>> A 16-bit ptrdiff_t on a freestanding implementation that does not
>> support objects bigger than (1 << 15) would be another common example.
>> Though that is only nonconforming for C99, C11 and C17, but valid C90,
>> C95 and C23.
> 
> How would it be valid C23?  The N2731 draft defines PTRDIFF_WIDTH in
> <stdint.h> and requires it to be at least 17.
> 

N2808 was voted into C23 on Thursday (conditionally on not causing
problems for C++, which will be discussed at one of the monthly
WG14/WG21 liaison meetings).

Philipp

[toc] | [prev] | [next] | [standalone]

#163760

Philipp Klaus Krause <pkk@spth.de> writes:

> Am 23.11.21 um 18:43 schrieb Keith Thompson:
>
>> Philipp Klaus Krause <pkk@spth.de> writes:
>>
>>> Am 22.11.21 um 21:55 schrieb Keith Thompson:
>>>
>>>> but useful and non-conforming is
>>>> sometimes better than conforming.
>>>
>>> A 16-bit ptrdiff_t on a freestanding implementation that does not
>>> support objects bigger than (1 << 15) would be another common example.
>>> Though that is only nonconforming for C99, C11 and C17, but valid C90,
>>> C95 and C23.
>>
>> How would it be valid C23?  The N2731 draft defines PTRDIFF_WIDTH in
>> <stdint.h> and requires it to be at least 17.
>
> N2808 was voted into C23 on Thursday (conditionally on not causing
> problems for C++, which will be discussed at one of the monthly
> WG14/WG21 liaison meetings).

It is a very sad day for the C programming language.

[toc] | [prev] | [next] | [standalone]

#163767

On 10/12/2021 10:41, Tim Rentsch wrote:
> Philipp Klaus Krause <pkk@spth.de> writes:
> 
>> Am 23.11.21 um 18:43 schrieb Keith Thompson:
>>
>>> Philipp Klaus Krause <pkk@spth.de> writes:
>>>
>>>> Am 22.11.21 um 21:55 schrieb Keith Thompson:
>>>>
>>>>> but useful and non-conforming is
>>>>> sometimes better than conforming.
>>>>
>>>> A 16-bit ptrdiff_t on a freestanding implementation that does not
>>>> support objects bigger than (1 << 15) would be another common example.
>>>> Though that is only nonconforming for C99, C11 and C17, but valid C90,
>>>> C95 and C23.
>>>
>>> How would it be valid C23?  The N2731 draft defines PTRDIFF_WIDTH in
>>> <stdint.h> and requires it to be at least 17.
>>
>> N2808 was voted into C23 on Thursday (conditionally on not causing
>> problems for C++, which will be discussed at one of the monthly
>> WG14/WG21 liaison meetings).
> 
> It is a very sad day for the C programming language.
> 

Do you care to elaborate?

It is irrelevant to all "big" systems, where ptrdiff_t is 32-bit or
more, but it means that C implementations for small systems don't need
to be pointlessly non-conformant.  It sounds like a good day to me - an
acknowledgement that C is important on small systems, and that
conformency is important for such small systems.

So IMHO Phillip is to be congratulated on his clear and well-reasoned
proposal.  It will make little or no practical difference, but it tidies
up an unnecessary flaw in the way the standards can work for small
embedded systems.

[toc] | [prev] | [next] | [standalone]

#163510

On Fri, 19 Nov 2021 15:57:09 -0300, Meredith Montgomery
<mmontgomery@levado.to> wrote:

>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., you are.  On some systems (for example, on IBM mainframes which
use EBCDIC coding), char is unsigned.  Since EOF must be negative, it
would not fit.  Thus getchar returns an int.

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#163514

Barry Schwarz <schwarzb@delq.com> writes:

> On Fri, 19 Nov 2021 15:57:09 -0300, Meredith Montgomery
> <mmontgomery@levado.to> wrote:
>
>>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., you are.  On some systems (for example, on IBM mainframes which
> use EBCDIC coding), char is unsigned.  Since EOF must be negative, it
> would not fit.  Thus getchar returns an int.

Nice.  Thanks very much for the IBM mainframe example.

[toc] | [prev] | [next] | [standalone]

#163520

On 19/11/2021 21:22, Barry Schwarz wrote:
> On Fri, 19 Nov 2021 15:57:09 -0300, Meredith Montgomery
> <mmontgomery@levado.to> wrote:

>> 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., you are.  On some systems (for example, on IBM mainframes which
> use EBCDIC coding), char is unsigned.  Since EOF must be negative, it
> would not fit.  Thus getchar returns an int.
> 

Unsigned plain char is also common on microcontrollers.  Really, it is
the concept of having plain chars be /signed/ that is the anachronism,
coming from a time when there was no alternative explicit "signed char"
and "unsigned char" and thus plain "char" doubled up as a small integer.

Basically, if your code depends on whether plain char is signed or
unsigned, you've written pointlessly unportable code.  Don't assume that
"char" is signed unless you are using a dinosaur or something weird and
niche, in the way that you can assume that CHAR_BIT == 8 unless you are
using a dinosaur or something niche (like a DSP).

[toc] | [prev] | [next] | [standalone]

#163528

David Brown <david.brown@hesbynett.no> writes:

> On 19/11/2021 21:22, Barry Schwarz wrote:
>> On Fri, 19 Nov 2021 15:57:09 -0300, Meredith Montgomery
>> <mmontgomery@levado.to> wrote:
>
>>> 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., you are.  On some systems (for example, on IBM mainframes which
>> use EBCDIC coding), char is unsigned.  Since EOF must be negative, it
>> would not fit.  Thus getchar returns an int.
>> 
>
> Unsigned plain char is also common on microcontrollers.  Really, it is
> the concept of having plain chars be /signed/ that is the anachronism,
> coming from a time when there was no alternative explicit "signed char"
> and "unsigned char" and thus plain "char" doubled up as a small integer.
>
> Basically, if your code depends on whether plain char is signed or
> unsigned, you've written pointlessly unportable code.  Don't assume that
> "char" is signed unless you are using a dinosaur or something weird and
> niche, in the way that you can assume that CHAR_BIT == 8 unless you are
> using a dinosaur or something niche (like a DSP).

Will surely do!  Thanks!

[toc] | [prev] | [next] | [standalone]

#163560

On Friday, 19 November 2021 at 18:59:47 UTC, Meredith Montgomery wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#163561

On Friday, 19 November 2021 at 18:59:47 UTC, Meredith Montgomery wrote:
> 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.

I find the question of whether or not char is signed unhelpful.

For me, the best approach is to consider reading binary data, 
not text, from a file.

You need to be able to read a byte (in C terms "char") at a time from
the data. So char needs to be able to contain every conceivable byte
value.

You also need to be able to recognise end of file. This can't be represented
by a specific byte value, as that could also be valid in binary data.

So, given that C only allows single return values from functions, the return
value from "read()" needs to be able to represent any byte (char) value plus
one other value. So it needs to be bigger than a 'C' char.

[toc] | [prev] | [next] | [standalone]

#163562

Mark Bluemel <mark.bluemel@gmail.com> writes:
[...]
> So, given that C only allows single return values from functions, the return
> value from "read()" needs to be able to represent any byte (char) value plus
> one other value. So it needs to be bigger than a 'C' char.

You mean from getchar(), not read().

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web