[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] xalloc: avoid GCC 5.1 warning on 32 bit
From: |
Pádraig Brady |
Subject: |
Re: [PATCH] xalloc: avoid GCC 5.1 warning on 32 bit |
Date: |
Sat, 3 Oct 2015 10:51:34 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 |
On 03/10/15 08:39, Paul Eggert wrote:
> Pádraig Brady wrote:
>> xalloc is
>> included into the coreutils compilation units and so
>> needs this guard.
>
> That's a problem in coreutils, not in gnulib.
Right. I missed the fact it applied only to a single use of xnrealloc.
> Please don't give much weight to
> those particular compiler warnings. They're often false alarms, as these
> were.
> There is nothing wrong when a compiler can reason about integer overflow to
> generate better code.
Agreed. I was just ensuring the 32 bit dev build succeeded,
so that automated tests would run.
> Conversely, it is often helpful for an application to use
> signed integer types so that a checking implementation can report integer
> overflow when the appliction is buggy, which means we shouldn't blindly
> substitute unsigned for signed types merely to stop GCC from bleating in this
> way.
Right, if adding explicit checks at runtime, with your macros for example:
http://lists.gnu.org/archive/html/bug-gnulib/2011-05/msg00264.html
> I reverted the gnulib change, and installed the attached coreutils patches to
> pacify 32-bit GCC in a better way. If these sorts of warnings continue to be
> a
> hassle in coreutils, perhaps we should disable the warnings there too.
Ah! I didn't know about assume(), as it wasn't used in coreutils.
http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=28df8b1e
I was considering IF_LINT(assert(...)); but thought that too ugly.
A much better solution.
thanks!
Pádraig.