Re: AC_*/AM_* macros for options

[Jeffrey Walton]

On Wed, Oct 30, 2013 at 7:11 PM, Paul Eggert <address@hidden> wrote:
> On 10/30/2013 02:24 PM, Jeffrey Walton wrote:
>> On Wed, Oct 30, 2013 at 4:01 PM, Paul Eggert <address@hidden> wrote:
>>> > On 10/30/2013 02:36 AM, Jeffrey Walton wrote:
>>> >
>>>> >> time_t is supposed to be an integer or real
>>>> >> (http://pubs.opengroup.org/onlinepubs/009696699/basedefs/sys/types.h.html).
>>> >
>>> > Unsigned integers are integers, so an unsigned time_t
>> Negative. On all systems, the C standard tells us signed integer
>> overflow is undefined and unsigned integer wrap is implementation
>> defined (or is it well defined).
>
> It's well defined to wrap around, for unsigned integer types that are
> not narrower than 'int'.  But my comment was about POSIX terminology,
> not about your terminology, and according to POSIX unsigned integers
> are indeed integers.
Oh, my bad.

>> > Sure, *sometimes* the warning is useful, just as even a
>> > clock that's stopped is right twice a day.  But in the code
>> > I deal with, the warning is a false alarm more often than
>> > not.
>> Are you certain of that?
>
> Sure, and I gave an example.  Compile it in an artificial environment
> where time_t is unsigned, and TIME_T_MAX is UINT_MAX and TIME_T_MIN
> is ((unsigned) 0), and you'll get a warning that's bogus.  And there's
> no good way to rewrite the code to avoid the warning.
>> I'd like to say turn it off for the functions in question (like the
>> timt_t example), but I know that can be painful in the free software
>> world (we've had the ability for 15 years or so in the MS world).
>
> We can also do it in the free software world, but it's typically not worth
> the maintenance hassle, at least, not for this particular warning, which
> is a false alarm way too often.
Perhaps I'm approaching this the wrong way (I probably don't have your
experience with the platform). When Linux/Unix folks turn off
-Wconversion, what do they use to find the bad conversions?

Jeff