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.

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

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

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.

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.

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

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

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!

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!

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.

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.

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.

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

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

On Monday, 22 November 2021 at 10:04:48 UTC, Keith Thompson wrote:
> Mark Bluemel <mark.b...@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().

True - thanks for the correction, Keith.

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

On Monday, 22 November 2021 at 10:04:48 UTC, Keith Thompson wrote:
> Mark Bluemel <mark.b...@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().
>
getc() / fgetc(). getchar() reads from stdin, which is text. ASCII does in fact
have end of text / end of transmission codes (EXT = 3, EOT = 4).

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Monday, 22 November 2021 at 10:04:48 UTC, Keith Thompson wrote:
>> Mark Bluemel <mark.b...@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().
>>
> getc() / fgetc(). getchar() reads from stdin, which is text. ASCII does in fact
> have end of text / end of transmission codes (EXT = 3, EOT = 4).

getchar() does read from stdin, but getc() and fgetc() take a FILE*
argument and can easily read from binary streams.

Yes, ASCII does define EXT and EOT characters. EOT is commonly entered
as Control-D, which typically triggers an end-of-file condition on
Unix-like systems -- but typically those characters when stored in a
file are just treated as ordinary characters (for which iscntrl() will
return a true value). An EOT character stored in a file is meaningless
(or rather, it has whatever meaning you choose to assign to it).

Few systems use more than a handful of the ASCII control characters with
their originally intended meanings.

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

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> On Monday, 22 November 2021 at 10:04:48 UTC, Keith Thompson wrote:
>>> Mark Bluemel <mark.b...@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().
>>>
>> getc() / fgetc(). getchar() reads from stdin, which is text. ASCII does in fact
>> have end of text / end of transmission codes (EXT = 3, EOT = 4).
>
>getchar() does read from stdin, but getc() and fgetc() take a FILE*
>argument and can easily read from binary streams.
>
>Yes, ASCII does define EXT and EOT characters. EOT is commonly entered
>as Control-D, which typically triggers an end-of-file condition on
>Unix-like systems -- but typically those characters when stored in a
>file are just treated as ordinary characters (for which iscntrl() will
>return a true value). An EOT character stored in a file is meaningless
>(or rather, it has whatever meaning you choose to assign to it).
>
>Few systems use more than a handful of the ASCII control characters with
>their originally intended meanings.

Yes, the old protocols for poll-select and contention mode.

[SYN] SOH <ad1> <ad2> <xm> STX <data bytes> ETX BCC

<ad1> <ad2> are two byte poll/select station address.
<xm> poll vs. select byte.

Still used when accessing obsolete block-mode terminals (I have two
working examples).

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.

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

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

On Friday, November 19, 2021 at 1:59:47 PM UTC-5, Meredith Montgomery wrote:

>I did not get Brian Kernighan's concern with setting EOF to a char c.

A bit of an interesting topic. As someone who created a somewhat well
received C compiler "back in the day", here is my $0.02

* Note, I wrote my compiler mid 80's, and although I later updated it to
* support some more modern syntax, it is essentially a K&R compiler.
+ I've not read through all the comments, so sorry if I duplicate.

Lets assume a very simple 16 bit system with byte support:
int = -32768 to 32767 = 0x8000 to 0x7FFF : -1 = 0xFFFF
unsigned int = 0 to 65535 = 0x0000 to 0xFFFF
char = -128 to 127 = 0x80 to 0x7F : -1 = 0xFF
unsigned char = 0 to 255 = 0x00 to 0xFF

Also, lets call signed int/char variables: si/sc
and unsigned int/char variables: ui/uc

getc() must return 16 bits, because a char value of 255 inside a binary
file is NOT EOF.

Assuming 255 is the next byte read:

If you do: uc = getc()
then uc will have 255 which is NOT EOF(-1)

If you do: sc = getc()
then sc will have -1 which IS EOF! (wrong)

** The effect is that if you are reading an ASCII text file where 0xFF
** never occurs, it appears to work correctly.
** But if you are reading a binary file into signed characters (something
** I would never do) it might see EOF instead of 0xFF characters.

If however you do: si = getc()
then si will have 255!

I find in practice with older compilers (including mine), this may
not always "get you". Consider a CPU with registrers R16 and R8:
if((c = getc()) == EOF) ...
might generate something like:

CALL getc ; 16 bit resuts comes back in R16
STORE lower-half-of R16 to c
CMP R16,0xFFFF ; R16 still has 0xFF
JZ ... ; Not taken!

In this case, because getc() returned int, even though it was stored
in a byte location, the compiler knows it's still an int value and
would probably do full 16 bit compare.

If however:
c = getc();
if(c == EOF) ...
You might see something like:

CALL getc
STORE lower-half-of R16 to c
LOAD R8 from c
CMP R8,0xFF ; now TRUE
JZ ... ; Now it IS taken!
And yes, optimization might prevent the extra load but the compiler would
still do an 8-bit compare - since it's comparing c with -1, 255 is EOF!

Regarding signed .vs. unsigned, I find that many older compilers only
take this into account for magnitude comparisons. Simple == and != would
often work regardless of signededness - this may not apply to more modern
standards where extra code might be generated to caused an unsigned 255
(0xFF) to NOT be the same as a signed -1 (0xFF).. in general I temd not
to trust that they will be different (or the same)!

I worked mainly on (and designed my compiler for) very small embedded
systems.. most "real programmers" dislike my style as I tend to use "unsigned"
and "unsigned char" instead of "int" and "char" when I don't actually
need/want signed values. On very tiny CPUs sign-extension may require more
code than simple zero-extension.

I also don't much rely on signed characters in general. If I want to
know a character is not ASCII (0x00-0x7F) I will usually: if(c & 0x80) ...

-- Interesting but mostly irrevlent note --

This does actually come into play with my C-FLEA, a virtual CPU I designed
to be a fairly optimal target for my compiler with very small code size.
C-FLEA has one "accumulator" which is always 16-bit. 8-bit is only supported
for memory accesses which when used as a value is auto zero-extended.

This means "char" appears as a "signed" positive value between 0 and 255
where "unsigned char" is an unsigned positive value between 0 and 255!
The "signed"/"unsigned" attribute only affects how the compiler propagates
the signededness of results.

Dave

Having nothing better to do this morning, I decided to write a little
test of this for various compilers I have readily available:

My own Micro-C (DOS and DVM-Win32)
Borland Turbo-C (DOS)
LCCwin32 (Win32)
GCC under (Linux Ubunto 20.10)

The tests simply creates a small (5 byte) file containing
'a', 'b', 0xFF, 'c' and 'd'
then reads it, testing for EOF with:
if((var = getc(fp)) = EOF) ...
and also:
var = getc(fp);
if(var == EOF) ...
using a 'var' variable of:
signed int, unsigned int, signed char & unsigned char

Here are the results:
--------------------------------
Micro-C/DOS EOF= -1 FFFF
signed int : if(v=getc())..
'a''b'[FF]'c''d' =5
unsigned int : if(v=getc())..
'a''b'[FF]'c''d' =5
signed char : if(v=getc())..
'a''b'[FFFF]'c''d' =5
unsigned char : if(v=getc())..
'a''b'[FF]'c''d' =5
signed int : v=getcc();if(v)...
'a''b'[FF]'c''d'[FFFF] =5
unsigned int : v=getcc();if(v)...
'a''b'[FF]'c''d'[FFFF] =5
signed char : v=getcc();if(v)...
'a''b'[FFFF] =2
unsigned char : v=getcc();if(v)...
'a''b'[FF] =2

Micro-C/DVM EOF= -1 FFFF
signed int : if(v=getc())..
'a''b'[FF]'c''d' =5
unsigned int : if(v=getc())..
'a''b'[FF]'c''d' =5
signed char : if(v=getc())..
'a''b'[FF]'c''d' =5
unsigned char : if(v=getc())..
'a''b'[FF]'c''d' =5
signed int : v=getcc();if(v)...
'a''b'[FF]'c''d'[FFFF] =5
unsigned int : v=getcc();if(v)...
'a''b'[FF]'c''d'[FFFF] =5
signed char : v=getcc();if(v)...
'a''b'[FF] =2
unsigned char : v=getcc();if(v)...
'a''b'[FF] =2

Turbo-C EOF= -1 ffff
signed int : if(v=getc())..
'a''b'[ff]'c''d' =5
unsigned int : if(v=getc())..
'a''b'[ff]'c''d' =5
signed char : if(v=getc())..
'a''b' =2
unsigned char : if(v=getc())..
'a''b'[ff]'c''d'[ff][ff][ff][ff] =9
signed int : v=getcc();if(v)...
'a''b'[ff]'c''d'[ffff] =5
unsigned int : v=getcc();if(v)...
'a''b'[ff]'c''d'[ffff] =5
signed char : v=getcc();if(v)...
'a''b'[ffff] =2
unsigned char : v=getcc();if(v)...
'a''b'[ff]'c''d'[ff][ff][ff][ff] =9

LCC: EOF= -1 ffffffff
signed int : if(v=getc())..
'a''b'[ff]'c''d' =5
unsigned int : if(v=getc())..
'a''b'[ff]'c''d' =5
signed char : if(v=getc())..
'a''b' =2
unsigned char : if(v=getc())..
'a''b'[ff]'c''d'[ff][ff][ff][ff] =9
signed int : v=getcc();if(v)...
'a''b'[ff]'c''d'[ff] =5
unsigned int : v=getcc();if(v)...
'a''b'[ff]'c''d'[ff] =5
signed char : v=getcc();if(v)...
'a''b'[ff] =2
unsigned char : v=getcc();if(v)...
'a''b'[ff]'c''d'[ff][ff][ff][ff] =9

GCC: EOF= -1 ffffffff
signed int : if(v=getc())..
'a''b'[ff]'c''d' =5
unsigned int : if(v=getc())..
'a''b'[ff]'c''d' =5
signed char : if(v=getc())..
'a''b' =2
unsigned char : if(v=getc())..
'a''b'[ff]'c''d'[ff][ff][ff][ff] =9
signed int : v=getcc();if(v)...
'a''b'[ff]'c''d'[ffffffff] =5
unsigned int : v=getcc();if(v)...
'a''b'[ff]'c''d'[ffffffff] =5
signed char : v=getcc();if(v)...
'a''b'[ffffffff] =2
unsigned char : v=getcc();if(v)...
'a''b'[ff]'c''d'[ff][ff][ff][ff] =9
--------------------------------

Some "interesting" notes:

Both Micro-C and Turbo-C are 16 bit compiler, LCC and GCC are 32 bit.

In all cases, EOF appears to have a value of -1

Micro-C does not do "extra work" to compare char (byte) variables. This is
mainly because it was designed with VERY small systems in mind (limited word
operations and often not much code storage space). In these cases "char"
variables are used a LOT and Micro-C generates only byte operations in
expressions having only 8 bit types.

Due to it's C-FLEA CPU, in Micro-C/DVM, "char" is treated as 16-bit signed
positive value between 0-255.

Other compilers appear to be doing more with "char" values, sign extending
them or EOF is defined in such a way it cannot be interpreted as a byte (-1
can be a byte).

Also, Micro-C keep the type/content of an expression when a partial result
is stored into a different type "part way along". Some other compilers
appear to treat the whole result differently when when this happens...

In case anyone wants to look at: TEST.C
This file is ENCTXTed to protect from online reformatting.
To Decode get: Daves Old Computers->Personal->Downloads->ENCTXT
----------------------------------------------------------------------
7u7p7J7f7p7f8T8k8y8z8y7f8n8g8t8j8r8o8t8m7f8u8l7f8E8O8F7f828o8z8n7f8y8o
8m8t8k8j7u808t:v:g7f8o8t8z7u8i8n8g8x:::B7I8x8k8y808r8z:P:T8i8u8s8v7t8r
8g8t8m7t8i7f8v8u8y8z:::Q:::B:P:B8D8g818k7f8D808t8l8o8k8r8j7f7f7f7s::At
8n8z8z8v8y757u7u8jA:Am7t8z8n8k8s8o8t8j8l8g8i8z8u8x847t::AG:::B7u7J7i8o
8t8i8r808j8k7f778y8z8j8o8u7t8n797J7J7i8j8k8l8o8t8k7I8T8F8I8L8E7I7h8T8M
8P7t8D8A8T7h7I7I7u7u:::E8s8v7f8l8o8r8k8t8g8s8k7J7J:PB57J7I7p8l8v767J7J
Af:n:P:07f7p8V:PCV8a8c7f787f86:fCH818g8x8o8g8h8r8k7f8z848v8k7f:PCV8y7J
7I7hAv:p7h7r::DZBP:n:fDmB:CpBvDm:fED7f88::Ck::CJ7w8y8z7f8z:::G7f757f8m
8k8z8i7n7o7fA::88y::BP:v:t8u:PDF7f:::M:fEl:::t8g8z7f7h8y::CW7f8z8o8s8k
7hAvBv8S8T7w7n817o8b7J7I8o8l7n7n81::C9:fEt8l8v7o7o7f7878:P:W:PFz7I8h8x
8k8g8q76::F08S8n8u82::Fx:PGZ8m8u::FE8g7w:vEc7xA:FMHvEq8n8k8t::Hh::FW81
8k8x7f8o8yA:FOBPFk7x:vFxBPF7C:GZ::F3::F7D:GKBfGo:PGd7f8g:fCv::BN::Ht81
8g8r808k7f7n8o8t7f8H8E8X7f8o8l7f8t8u8z7f8v8x:::w:PDK7o:PEe8N8u8z8k757f
8A8y8y80::DW7f8A8S8C8I8IAvJyB:JT8y8k8z7g7J818u8o8j:fJM7nAvCn7o7J867J7I
:fJz8l7n7f7n7n8i7f777f7m7f7m7o7f87877f::LQ797f7m897m::GG7;7f7h8a7k838c
7h::Eq7h7m7k8i7m7h7r7f8i7f7o767J88:fEd8P8k8x8l8u8x8s:PHh:vEl8u8t::JR8m
8o81::HkAfDG7l:vEl:PDP:vKt8D8u8T8y8zB:K3:PCx8s8u8j::J7::LE:::w7f8S:::w
767J7IBP:n7f8o7r7f8U:vNe:fCw8S:P:0BPNh:fCw8U:vOB7J:::782::BJ:fIU::F1::
C97v::NhA:LH7h7k8y::Eq7k8y8b8t7f7f:PDm7I:vC2:PNQ7l7y8c:PPI7n:PNQ::LS7z
:fLm:PIn78:vEt7o7t7t:fLv:vPu::Ew76:PIn::P27t7h::GR::L97J:PCI8I8t7f8i8g
8y8k:f:W:PJv8j8k8z8k::JZ8j7t7f8z8x847f777w7v:fFe8y7J8g7w75:PF27q7q8o::
LS7w7v7o7f8y:::b8i8n:fPd7o7f::LE7I:fQf7v7I75:vFs:PNd:POo:vRl7wAPRs:PN0
AvR47xAfRs:P:0AvR47yAfSDBvSj7z:vRs7xC:Rz70APTKBvSL71AfTKBvSj72AfTh:vSj
7I88AvOy7f787k808b8t::L48o7s7w:vL9:PNZ8s8g8o8t7n:fLCAv:n:PObAPO0:::X78
7f7k::As7k83:fUv:::X:fVvAPQU8F8o8x::Ej8i::GV8z8k:fCQ::AF::J28o8t:P:Q70
AvJT::DY7u7u7I7f7m8g7m7v83717w7r7f7m8h:PWy7x7r7f7v838F::Vz7m8i:PWy7y::
W38j:PWy7z:fF17g::GD::C98l8u8v8k8t7n:fB47r7f7h828h7h7o::GG:PRiAPO08C8g
8t7m8z7f8W8R8I8T8E:vP:::L4:fB4:fR48x8k8z808x8t7f7w767f::Ug8l8v808z8y7n
7h8g8h::L4:vOm::Yx8i7n:vXC:vOmA:Yw8i8jAfY58l8i8r8u8y8k:vOlEvXY8xEPXz8R
8E8A8DEvYQ7x:PYr::Yu8u8x7n8o787v767f:PRN73767f::RL7o::GR:vM88o:fQUBvZl
A:Yj::Ow887J
----------------------------------------------------------------------

Regards,
Dave - see "Daves Old computers" -> Personal

Dave Dunfield <dave.dunfield@gmail.com> writes:
> Having nothing better to do this morning, I decided to write a little
> test of this for various compilers I have readily available:
>
> My own Micro-C (DOS and DVM-Win32)
> Borland Turbo-C (DOS)
> LCCwin32 (Win32)
> GCC under (Linux Ubunto 20.10)
>
> The tests simply creates a small (5 byte) file containing
> 'a', 'b', 0xFF, 'c' and 'd'
> then reads it, testing for EOF with:
> if((var = getc(fp)) = EOF) ...
> and also:
> var = getc(fp);
> if(var == EOF) ...
> using a 'var' variable of:
> signed int, unsigned int, signed char & unsigned char
>
> Here are the results:
[SNIP]

> In case anyone wants to look at: TEST.C
> This file is ENCTXTed to protect from online reformatting.
> To Decode get: Daves Old Computers->Personal->Downloads->ENCTXT
> ----------------------------------------------------------------------
> 7u7p7J7f7p7f8T8k8y8z8y7f8n8g8t8j8r8o8t8m7f8u8l7f8E8O8F7f828o8z8n7f8y8o
> 8m8t8k8j7u808t:v:g7f8o8t8z7u8i8n8g8x:::B7I8x8k8y808r8z:P:T8i8u8s8v7t8r
[...]
> 8E8A8DEvYQ7x:PYr::Yu8u8x7n8o787v767f:PRN73767f::RL7o::GR:vM88o:fQUBvZl
> A:Yj::Ow887J
> ----------------------------------------------------------------------

I don't think many people are going to download EXCTXT so they can
decode your source file.

You can just include code inline in a post. As long as the lines aren't
too long it shouldn't be a problem. If absolutely necessary, you can
use a standard encoding like base64.

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