[PATCH] Replace int -> uint to avoid signed integer overflow

Kang-Che Sung explorer09 at gmail.com
Mon Feb 6 08:50:51 UTC 2017


On Mon, Feb 6, 2017 at 3:22 PM, Rob Landley <rob at landley.net> wrote:
> On 02/05/2017 09:10 PM, Kang-Che Sung wrote:
>> On Mon, Feb 6, 2017 at 8:52 AM, Rob Landley <rob at landley.net> wrote:
>>> What's an archive input that actually fails? What's an example of a
>>> processor machine language that doesn't produce 0x80000000 for 1<<31?
>>>
>>> Where does this actually cause a problem?
>>
>> I think at least this silences a "undefined behavior" warning, and that's
>> enough for the patch.
>
> So the problem _is_ the warning? There's no real issue, just a noisy
> compiler?

Technically yes. It's "-Wshift-overflow=2" although it's off by default and
little people care about these days.

>
> Which is why we have more than one standard: Posix, LP64, LSB, ELF...
> Posix requires a machine to handle two's complement here:
>
>   http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdint.h.html
>

And C++14.

> Could you give me an example of an architecture from this century that
> _doesn't_ use two's complement? The IBM S/360 (introduced in 1964) used
> two's complement. The first minicomputer (PDP-8 in 1965) used two's
> complement. The first microcomputer (Altair, 1975) used two's complement
> (altair basic manual page 28 says so)...

I have never been arguing about this. Your point stands. Yes, there are no
architectures today that would use anything else than two's complement
for signed arithmetic. But it's the standard that wished to be more
conservative. (C standard has not yet been updated despite POSIX and
C++14)

Now I don't like to argue with this further. This patch breaks nothing changes
nothing in machine code, just to silence a warning. If it's me then
I'll merge it
because it wouldn't hurt anyway.


More information about the busybox mailing list