Bruno Haible <[EMAIL PROTECTED]> writes: > On a system where 'unsigned char' and 'int' have the same number of > bits, the getc() and fgetc() result EOF would be ambiguous: it could > be EOF or it could be a casted 'unsigned char' value. It sounds very > improbable that such a system exists, now or in the future.
They do exist. Here's one example that I found with a quick Google search: http://www.ecse.rpi.edu/courses/CStudio/Cal_lab/ADI_DSP/21K/INCLUDE/LIMITS.H Typically they're DSPs, so they are freestanding implementations and don't have getc. If they did have getc, getc would probably return something in the range -1..255 anyway, so there would be no ambiguity. Admittedly these are unlikely platforms for coreutils, but they might be used for something like GNU Radio. Since it's an easy fix in this particular case I thought I'd put it in (if only to save time for the next guy who reads the code looking for integer-overflow issues :-). >> * m4/getusershell.m4 (gl_PREREQ_GETUSERSHELL): Remove; no longer needed. >> All uses removed. >> * m4/strtol.m4 (gl_PREREQ_STRTOL): Likewise. >> * m4/strtoul.m4 (gl_PREREQ_STRTOUL): Likewise. > > I find it more maintainable to keep these macros, even when they are > currently no-ops. Such as in m4/rename.m4. It's a close call. I see your point, but on the other hand if they're noops and are likely to remain noops I think it's a bit simpler to omit them. I do agree with you that we should try to retain the distinction between the macro which tests whether a replacement function is needed and the macro which prepares for the replacement function itself.
