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

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Dave Dunfield <dave.dunfield@gmail.com> writes:
>>
>>> On Wednesday, December 8, 2021 at 10:23:22 PM UTC-5, Tim Rentsch wrote:
>>>
>>>> (Incidentally, can you explain why you can't set up a news
>>>> account with one of several few news providers, such as
>>>> eternal-september, and avoid the problems of using google
>>>> groups?)
>>>
>>> Just haven't taken the time so far ... looked into setting up some
>>> sort of newsgroup access and spent hours running into various
>>> roadblocks... Along the way I discovered "Google Groups" which
>>> would give me access with little difficulty .. just at the cost of
>>> having everything reformatted in a "code unfriendly" manner...
>>
>> If you want other people to look at what you're doing it's
>> important to provide access in a way that _they_ think is easy.
>>
>>> [...] I've essentially retired and having much more time on my
>>> hands, [...]
>>
>> If you have lots of free time, you might practice writing C code
>> that conforms to the ISO C standard. Good feedback is available
>> using
>>
>> gcc -std=c99 -pedantic-errors
>
> If you have a reasonably modern version of gcc, you can use -std=c11 or
> -std=c17. (C17 was a minor update on top of C11, and the only
> difference between gcc's -std=c11 and -std=c17 options is the value of
> __STDC_VERSION__.)

I deliberately chose C99 because I think it's the best fit
for the suggestion given.

On 2021-11-19, 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---

Not all of this is correct. The conclusion to use int is correct,
but it is incorrect to insinuate that:

- EOF is distinct from values of char (it isn't required to be,
and quite often isn't: char is often signed, and EOF is often #defined
as -1).

- getchar() returns values of char (it doesn't; if a datum is available
from the stream, it returns it as a value from 0 to UCHAR_MAX).

Is the quote verbatim?

Also, the primary reason to capture the return value of getchar, getc
and fgetc using a value of type int is that this is the declared
return type of these functions.

If a function returns int, you capture that with int, or else (if
you have special reasons for it) an integer type whose range is a
superset of int. Your choice need not, and ideally should not, be
justified with the run-time semantics of the function; you know
from the type that you're capturing every value.

(To handle the value futher, you have to know something about its
semantics, like which subset of its range represents a datum and which
value(s) are in-band error signaling.)

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

It is overwhelmingly common for EOF to have a value that is
representable in a char (informally, to "fit" into a char).

And that would be a problem if getchar returned char values,
and one not solved by the int return type.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 12/12/21 1:55 PM, Kaz Kylheku wrote:
....
> Not all of this is correct. The conclusion to use int is correct,
> but it is incorrect to insinuate that:
>
> - EOF is distinct from values of char (it isn't required to be,
> and quite often isn't: char is often signed, and EOF is often #defined
> as -1).

You're quite correct that EOF isn't required to be distinct from valid
values - but it's also much more convenient if it is distinct. I think
you'll find that systems where char is signed are generally also systems
where EOF != -1.

The implementations where there's a real problem are those where it's
not possible for EOF to be a distinct value. For example, that would be
the case if UCHAR_MAX > INT_MAX (which requires that CHAR_BIT >= 16).

All standard I/O is defined as behaving as if it ultimately involves
calls to fputc() or fgetc(). fputc() is defined as converting from int
to unsigned char; fgetc() is defined as reversing that conversion. In
general, conversion a value that's too large to be represented in the
new type either produces an implementation-defined result, or raises an
implementation-defined signal.

However, "Data read in from a binary stream shall compare equal to the
data that were earlier written out to that stream, under the same
implementation." Therefore, if you call fputc(EOF, binary_stream), a
call to fgetc() which reads that byte must return EOF, without actually
being at the end of a file. This is true, regardless of which value the
implementation chooses for EOF. On such systems, you must check feof()
and ferr() to determine whether eis

> - getchar() returns values of char (it doesn't; if a datum is available
> from the stream, it returns it as a value from 0 to UCHAR_MAX).

It's read in as unsigned char, but converted to int; in the unlikely
event that UCHAR_MAX > INT_MAX, that conversion will change the value.

>> 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.
>
> It is overwhelmingly common for EOF to have a value that is
> representable in a char (informally, to "fit" into a char).

Not on systems where char is unsigned.

Dave Dunfield <dave.dunfield@gmail.com> writes:

> [...]

For future reference here is a short C program that does
base64 encoding.

/*** b64e.c - base64 encode stdin to stdout. */
/*** NOTE: This program assumes characters are 8 bits. */

#include <stdio.h>

static char A[] = {
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"
};

int
main( void ){
int c;
unsigned long b = 0, n = 0, k = 0;
char out[ 73 ];

while( c = getchar(), c != EOF ){
b = (b<<8) + c, n += 8;
do {
if( k > 71 ) out[k] = 0, puts( out ), k = 0;
n -= 6;
out[ k++ ] = A[ b >>n &63 ];
} while( n > 5 );
}

if( n > 0 ) out[ k++ ] = A[ b <<(6-n) &63 ];

if( k > 0 ) out[k] = 0, puts( out ), k = 0;
else puts( "====" );

return 0;
}