Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #162797
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: C23 (C2x) changes |
| Date | 2021-09-21 17:56 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <sicvbp$m4m$1@dont-email.me> (permalink) |
| References | (3 earlier) <siahul$tb8$1@dont-email.me> <siao15$qbr$1@dont-email.me> <siaplj$r7d$1@dont-email.me> <siasoc$m4t$1@dont-email.me> <siaufp$mhq$1@dont-email.me> |
On 20/09/2021 23:29, Bart wrote:
> On 20/09/2021 21:59, David Brown wrote:
>> On 20/09/2021 22:07, Bart wrote:
>>> On 20/09/2021 20:39, David Brown wrote:
>>>> On 20/09/2021 19:55, Bart wrote:
>>>>> On 20/09/2021 17:17, David Brown wrote:
>>>>>> On 20/09/2021 17:41, John Bode wrote:
>>>>>
>>>>>>> If signed integer representations other than two's complement will
>>>>>>> no longer be supported, does this mean signed integer overflow can
>>>>>>> have a well-defined behavior? Or will it still be left undefined
>>>>>>> to allow for optimizations? Or could that be controlled with one
>>>>>>> of these newfangled attribute thingies?
>>>>>>
>>>>>>
>>>>>> No, signed integer overflow is still undefined behaviour - for
>>>>>> which I
>>>>>> am very glad. Defining it is terrible, IMHO, since any definition
>>>>>> you
>>>>>> give will be the wrong answer. Some would want it defined as
>>>>>> wrapping
>>>>>> ($DEITY knows why, since it is the silliest of all definitions
>>>>>> despite
>>>>>> being fairly efficient to implement), some would want it as an
>>>>>> error or
>>>>>> a trap, some would want saturation, some would want a NaN, some would
>>>>>> want errno to be set.
>>>>>>
>>>>>> For those that think it makes sense to have a pile of 2147483647
>>>>>> apples,
>>>>>> add another apple to the pile, and end up with -2147483648 apples,
>>>>>> gcc
>>>>>> still has the "-fwrapv" option.
>>>>>
>>>>> Of course it makes perfect sense to have a pile of 4294967295 apples,
>>>>> add another apple to the pile, and suddenly end up with 0 apples!
>>>>
>>>> I don't think it does make sense - although it is a good deal less
>>>> silly
>>>> than wrapping signed integers. Unsigned types in C model modulo
>>>> arithmetic precisely - signed types model integer arithmetic with size
>>>> limitations. In integer arithmetic, and in C signed arithmetic, you
>>>> can't add two positive numbers and get a negative number. That seems
>>>> pretty obvious and sensible to me.
>>>>
>>>>>
>>>>> Meanwhile, someone could remove that extra apple from the pile of
>>>>> -2147483648, to restore the original 2147483647, however that's too
>>>>> late: the overflow police have already been, and will do so again even
>>>>> when it becomes legal.
>>>>>
>>>>
>>>> "Someone could remove an apple from a pile of -2147483648 apples" ? Do
>>>> you not see how nonsensical that is?
>>>>
>>>
>>> Well, that's how it's defined with twos complement 32-bit arithmetic.
>>>
>>> You add 1 to the pile of 0x7FFF'FFFF (int32.max) to get the bit-pattern
>>> 0x8000'0000 (which represents int32.min). You can subtract 1 again to
>>> get back to 0x7FFF'FFFF.
>>>
>>> You can evaluate int32.max + (1 - 1) with no problem, but you can't do
>>> (int32.max + 1) - 1, which yields exactly the same result on two's
>>> complement hardware, for what reason?
>>>
>>
>> There is no defined behaviour for signed integer overflows in C
>> precisely so that you can get sensible results for sensible inputs, and
>> the compiler can apply sensible mathematical identities to get efficient
>> code. So in C, "x * 6 / 3" can be simplified to "x * 2" - that doesn't
>> happen with two's complement wrapping.
>
> Except no compiler seems to do that (of the 7 I tried on Windows) except
> gcc. So is this just for the benefit of one or two compilers?
>
There are perhaps half a dozen serious C compilers that have Windows
versions, and a few more that are *nix only. gcc, clang, MSVC, icc are
the main ones. For all of these, signed integer overflow is undefined
behaviour. "Cheap and cheerful" compliers like tcc might have their
uses - judging C behaviour is not one of them.
> Here is my test program:
>
> ---------------------------------------
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(void) {
> unsigned int a=1234567891;
>
> printf("%u\n", a*6/3);
> printf("%u\n", a*2);
>
> int b=534567891;
>
> printf("%d\n", b*6/3);
> printf("%d\n", b*2);
> }
> ---------------------------------------
>
> The first two results are always different: it can't turn *6/3 into *2
> for unsigned anyway.
>
Of course - unsigned integers are modulo types in C.
> The next two are also always different except with gcc (at any
> optimisation level).
The next one is undefined behaviour. No one - at least, no C programmer
who isn't either ignorant of the way C works or intentionally trolling -
expects any particular results here.
>
> So you now have a program whose behaviour depends on compiler.
Of course. The compiler can do anything here, including print a message
suggesting the programmer reads a beginner's book on C - either at
compile time, or at run time. My preference (and I'm disappointed not
to see this without adding a "const" to "b") would be a warning message
about the overflow.
Adding "-fsanitize=undefined" to gcc (or clang) gives a run-time error.
>
> (BTW if I run the equivalent in my language, with the same numbers, then
> I always get both pairs identical. That's because my types are 64 bits.
> But even if I change them to 32 bits, I still get the same results.
>
I fail to see the great appeal in consistently getting incorrect
results. I'd rather get a warning about the bug in the code.
(On the other hand, I /do/ see the appeal of using 64-bit types on
64-bit systems.)
>
>>> Note that with (uint32.max + 1) - 1, it seems to be acceptable to get an
>>> intermediate out-of-range result.
>>
>> There is no out of range intermediate result with modulo arithmetic. It
>> is not that "overflow is defined as wrapping" - the operations are
>> defined in a way that precludes overflow.
>
> So, a cop-out. Just define similar behaviour with signed values.
>
Unsigned integer arithmetic is defined differently in C. It's a design
decision. (Often I'd prefer unsigned integers overflow to be undefined
too, as overflow is usually a bug in the code. But it is useful to have
support for modulo arithmetic in a language, and supporting both
flavours of unsigned types would mean a more sophisticated type system.)
What do you see as the practical uses of having wrapping in signed
integers? Can you give /real/ code in which it is necessary to get the
correct answer?
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
C23 (C2x) changes Mehdi Amini <atorrses@gmail.com> - 2021-09-20 10:54 +0430
Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-20 09:35 +0200
Re: C23 (C2x) changes Mehdi Amini <atorrses@gmail.com> - 2021-09-21 11:01 +0430
Re: C23 (C2x) changes John Bode <jfbode1029@gmail.com> - 2021-09-20 10:41 -0500
Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-20 18:17 +0200
Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-20 18:55 +0100
Re: C23 (C2x) changes scott@slp53.sl.home (Scott Lurndal) - 2021-09-20 18:21 +0000
Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-20 21:39 +0200
Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-20 21:07 +0100
Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-20 22:59 +0200
Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-20 22:29 +0100
Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-20 17:43 -0700
Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-21 17:56 +0200
Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-21 18:05 +0100
Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-21 11:42 -0700
Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-22 11:37 +0200
Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-22 11:55 +0100
Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-22 14:21 +0200
Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-22 13:58 +0100
Re: C23 (C2x) changes Ian Pilcher <arequipeno@gmail.com> - 2021-09-22 12:02 -0500
Re: C23 (C2x) changes scott@slp53.sl.home (Scott Lurndal) - 2021-09-22 17:19 +0000
Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-20 23:05 +0100
Re: C23 (C2x) changes scott@slp53.sl.home (Scott Lurndal) - 2021-09-20 22:47 +0000
Re: C23 (C2x) changes Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-09-20 22:58 +0000
Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-02 07:16 -0700
Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-02 15:15 +0000
Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-20 17:45 -0700
Re: C23 (C2x) changes Manfred <noname@add.invalid> - 2021-09-27 17:15 +0200
Re: C23 (C2x) changes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-09-27 17:38 +0100
Re: C23 (C2x) changes Manfred <noname@add.invalid> - 2021-09-27 23:18 +0200
Re: C23 (C2x) changes antispam@math.uni.wroc.pl - 2021-09-28 13:53 +0000
Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-02 08:07 -0700
Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-02 15:18 +0000
Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-02 15:04 -0700
Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-03 01:58 +0000
Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-02 22:06 -0700
Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-03 10:43 +0000
Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-03 13:30 -0700
Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 05:04 +0000
Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-03 23:24 -0700
Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 06:54 +0000
Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-10-04 09:58 +0200
Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 15:52 +0000
Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-04 10:45 -0700
Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 20:30 +0000
Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-06 03:57 -0700
Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-06 12:27 +0000
Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-29 03:38 +0000
Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-10-15 11:35 +0100
Re: C23 (C2x) changes Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-10-15 18:27 +0000
Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-10-15 20:08 +0100
Re: C23 (C2x) changes Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-10-15 19:20 +0000
Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-10-15 21:50 +0100
Re: C23 (C2x) changes Florian Weimer <fw@deneb.enyo.de> - 2021-10-03 09:43 +0200
Re: C23 (C2x) changes Guillaume <message@bottle.org> - 2021-10-03 18:53 +0200
Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-03 13:55 -0700
Re: C23 (C2x) changes William Ahern <william@25thandClement.com> - 2021-09-21 22:57 -0700
Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-02 08:55 -0700
Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-02 16:36 +0000
Re: C23 (C2x) changes Guillaume <message@bottle.org> - 2021-09-22 20:27 +0200
Re: C23 (C2x) changes Philipp Klaus Krause <pkk@spth.de> - 2021-09-22 22:25 +0200
Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-22 14:05 -0700
Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-09-22 23:24 +0100
Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-09-22 18:49 -0700
Re: C23 (C2x) changes Guillaume <message@bottle.org> - 2021-09-23 18:47 +0200
Static bounds checking (was Re: C23 (C2x) changes) William Ahern <william@25thandClement.com> - 2021-09-23 21:11 -0700
Re: Static bounds checking (was Re: C23 (C2x) changes) David Brown <david.brown@hesbynett.no> - 2021-09-24 08:51 +0200
Re: Static bounds checking (was Re: C23 (C2x) changes) Philipp Klaus Krause <pkk@spth.de> - 2021-09-24 09:30 +0200
Re: Static bounds checking (was Re: C23 (C2x) changes) Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-24 07:52 +0000
Re: Static bounds checking (was Re: C23 (C2x) changes) Philipp Klaus Krause <pkk@spth.de> - 2021-09-24 12:32 +0200
Re: Static bounds checking (was Re: C23 (C2x) changes) Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-24 10:49 +0000
Re: Static bounds checking (was Re: C23 (C2x) changes) Philipp Klaus Krause <pkk@spth.de> - 2021-09-24 14:46 +0200
Re: Static bounds checking (was Re: C23 (C2x) changes) Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-24 18:14 +0200
Re: Static bounds checking (was Re: C23 (C2x) changes) Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 01:00 +0000
Re: Static bounds checking (was Re: C23 (C2x) changes) Philipp Klaus Krause <pkk@spth.de> - 2021-09-25 07:44 +0200
Re: Static bounds checking (was Re: C23 (C2x) changes) Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 11:28 +0000
Re: Static bounds checking (was Re: C23 (C2x) changes) antispam@math.uni.wroc.pl - 2021-09-28 10:56 +0000
Re: Static bounds checking (was Re: C23 (C2x) changes) Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-25 09:48 +0200
Re: Static bounds checking (was Re: C23 (C2x) changes) Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-25 11:30 +0000
Re: Static bounds checking (was Re: C23 (C2x) changes) Kaz Kylheku <480-992-1380@kylheku.com> - 2021-09-25 20:49 +0000
Re: Static bounds checking (was Re: C23 (C2x) changes) Branimir Maksimovic <branimir.maksimovic@gmail.com> - 2021-09-26 00:04 +0000
Re: Static bounds checking (was Re: C23 (C2x) changes) Bonita Montero <Bonita.Montero@gmail.com> - 2021-09-26 06:56 +0200
Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-09-27 10:15 -0700
Re: C23 (C2x) changes Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-09-27 11:15 -0700
Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-09-27 22:11 +0200
Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-09-27 14:20 -0700
Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-09-27 14:31 -0700
Re: C23 (C2x) changes Mehdi Amini <atorrses@gmail.com> - 2021-09-28 10:43 +0330
Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-06 04:01 -0700
Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-10-06 04:42 -0700
Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-29 04:04 -0700
Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-10-29 16:34 +0200
Re: C23 (C2x) changes Guillaume <message@bottle.org> - 2021-10-06 19:07 +0200
Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-10-07 11:06 +0200
Re: C23 (C2x) changes Guillaume <message@bottle.org> - 2021-10-07 19:31 +0200
Re: C23 (C2x) changes David Brown <david.brown@hesbynett.no> - 2021-10-07 22:14 +0200
Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-10-08 06:18 -0700
Re: C23 (C2x) changes Thiago Adams <thiago.adams@gmail.com> - 2021-10-08 06:21 -0700
Re: C23 (C2x) changes Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-29 04:01 -0700
Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-15 12:59 +0200
Re: C23 (C2x) changes Jim Jackson <jj@franjam.org.uk> - 2021-10-15 16:50 +0000
Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-16 07:51 +0200
Re: C23 (C2x) changes "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-16 11:50 -0700
Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-16 21:28 +0200
Re: C23 (C2x) changes Jim Jackson <jj@franjam.org.uk> - 2021-10-17 17:18 +0000
Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-17 20:00 +0200
Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-10-17 19:17 +0100
Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-18 06:49 +0200
Re: C23 (C2x) changes Bart <bc@freeuk.com> - 2021-10-18 11:23 +0100
Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-18 14:09 +0200
Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-21 01:07 +0000
Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-21 01:02 +0000
Re: C23 (C2x) changes Guillaume <message@bottle.org> - 2021-10-16 21:28 +0200
Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-17 06:04 +0200
Re: C23 (C2x) changes Manfred <noname@add.invalid> - 2021-10-17 19:35 +0200
Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-17 20:01 +0200
Re: C23 (C2x) changes "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-17 14:15 -0700
Re: C23 (C2x) changes Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-21 01:02 +0000
Re: C23 (C2x) changes Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-21 13:15 +0200
csiph-web