On 10/30/2013 02:24 PM, Jeffrey Walton wrote:
> On Wed, Oct 30, 2013 at 4:01 PM, Paul Eggert <egg...@cs.ucla.edu> 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.

>
> > There's nothing wrong with the code in
> > <http://lists.gnu.org/archive/html/autoconf/2013-10/msg00030.html>
> Yeah, I did not claim there was. I could not produce the warning on OS
> X 10.8, Ubuntu 12.04 or Ubuntu 13.04.
>

That's because time_t is signed on those platforms.  You'll get a warning
only on systems where time_t is unsigned.  This is clearly allowed by POSIX
and is done in practice and there's nothing particularly wrong with it.

>
> > 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.

_______________________________________________
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Reply via email to