🚀 go-pugleaf

In article <23261@watmath.waterloo.edu> rbutterworth@watmath.waterloo.edu (Ray Butterworth) writes:
>The minor change to the standard (i.e. valid input is EOF or the low order
>byte of the argument), would at worst require that the implementation
>increase the size of the table used by macros by 50% (e.g. -128 to 255, plus
>EOF)

In order to make that guarantee, and continue to implement the routines as
safe macros, I believe you'd have to change your wording.  You can have '\200'
represented as both 0x80 and 0xFFFFFF80, but I don't see any way to make
`islower(0x12345680)' also work (in this worst-case scenario).

(The following is from an article that I started to write but decided not to
post.  I think.  If I did post it, you may have already seen this.)

The real problem, as I see it, predates the very existence of unsigned char.
The getchar() function has a return type that logically should be `char', but
instead is `int'.  If not for this use of an OOB value to flag the error
condition, there would be no need for the macro EOF, and the isxxx() routines
could have their domain defined as simply `char'.  I suspect that there
wouldn't even have been any need for signed/unsigned char at all, except for
arithmetic, and in that case it could have used the less misleading name
`[unsigned] short short int'.

That would still leave the problem of how to detect the error condition.  I
won't go into that, because I don't want to get involved% in the flame war
that would inevitably result.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
________
% Not today, anyway.