GNU bug report logs - #49261
28.0.50; File Locking Breaks Presumptuous Toolchains

Previous Next

Full log

Message #320 received at 49261 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 49261 <at> debbugs.gnu.org
Subject: Re: bug#49261: Segfault during loadup
Date: Wed, 14 Jul 2021 17:24:37 -0500

[Message part 1 (text/plain, inline)]

On 7/14/21 7:36 AM, Eli Zaretskii wrote:
> You are saying that there's some fundamental difference between
>
>    INT_MAX + 1
>
> and
>
>    (USE_LSB_TAG ? - (1 << GCTYPEBITS) : VAL_MAX)

Yes there's a fundamental difference. INT_MAX + 1 has a signed integer 
overflow that violates the C standard. Obviously GCC should diagnose it.

The other expression conforms to the C standard and there is no error or 
overflow there. There's no reason -Woverflow should provoke a diagnostic 
for it.

> Or between an expression 'x = FOO' and 'mask = BAR'?
I don't know what x, mask, FOO, and BAR refer to.

> the warning was valid, as the
> assignment loses significant bits.
I originally wrote it as "uintptr_t mask = VALMASK;" because I would 
rather avoid C casts when possible (they're too powerful and allow too 
many bugs to go undetected). I dislike the workaround that I installed 
because of (a) its unnecessary cast and (b) the lack of clarity that 
it's intended that we want to discard any bits outside UINTPTR_MAX ((b) 
was a problem with my original code too).

To try to fix both (a) and (b) I installed the attached further patch. 
It is a bit more verbose than what C requires, but the verbosity should 
help explain that masking with UINTPTR_MAX is intended, and the 
verbosity shouldn't hurt efficiency.

[0001-Pacify-gcc-Woverflow-more-clearly.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.