🚀 go-pugleaf

chinet!rlk writes:
>In article <2233@gitpyr.UUCP> thomps@gitpyr.UUCP writes:
>>[text deleted --kwh]
>Balderdash!!!!!

This is not a very informative comment following a long quote.  Do you
mean that all of the quoted text is balderdash, or just the part you attempt
to refute in the next paragraph?  (I think everything Ken said was correct.)

>K&R declare all chars as ints so that routines that return EOF will
>work correctly regardless of whether chars are signed or unsigned
>in your hardware/software combination.

That's a valid reason for declaring SOME variables "int" -- namely those
that will be used to hold the result of getchar() et al -- but this has no
relevance to the question at hand.  (And whether char is signed or not is
irrelevant to both questions.)

>Your compiler is broken if it will not work as shown in the example,
>and if you define the arg as an int in the subroutine, you \'should\'
>cast the char arg to an int in the calling sequence.  The automatic
>promotion of char to integer only means that everything will probably
>work if you don't do the casting.

What does "probably" mean in this context?  If uncasted char is automatically
promoted to int, and the argument is declared int, how can it fail?  Are you
saying that the cast should be present for documentation/aesthetic reasons?

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint