autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AC_*/AM_* macros for options


From: Jeffrey Walton
Subject: Re: AC_*/AM_* macros for options
Date: Wed, 30 Oct 2013 17:24:19 -0400

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

On x86 systems, the compiler generates different machine code for
signed vs unsigned compares (for example, '>' (the greater symbol) is
either a "jump above" ('ja') or "jump greater" ('jg') instruction. Ja
or jg takes the branch based on different flag bits.

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

>> the Linux kernel guys don't feel the C language rules apply to them.
>
> That's a separate issue, surely.  They don't use Autoconf, and this is
> the Autoconf mailing list.
Their code is sometimes included in userland projects. To me (perhaps
in naiveness), I don't care if its a makefile project, autotools
project, or where the sources came from. I only care that its correct
and reasonably secure.

>> I was able to write 15 or so negative test cases
>> that broke that parser based on that one warning.
>
> 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? I usually find I can provide a negative test
case to produce an incorrect result.

If the negative case was handled, a cast usually clears the warning.
(Obviously, we want to avoid a blind cast to quell a warning if it
does not fix anything).

> Requiring it for an entire project would often be the
> wrong thing to do.  Having Autoconf make it the default for
> all projects sounds like it'd be a mistake.
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).

Jeff



reply via email to

[Prev in Thread] Current Thread [Next in Thread]