Re: AC_HEADER_STDC

[Paul Eggert]

Bruno Haible <address@hidden> 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.