On Mon, Feb 6, 2017 at 3:22 PM, Rob Landley <[email protected]> wrote: > On 02/05/2017 09:10 PM, Kang-Che Sung wrote: >> On Mon, Feb 6, 2017 at 8:52 AM, Rob Landley <[email protected]> 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. _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
