Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #162767 > unrolled thread
| Started by | Mehdi Amini <atorrses@gmail.com> |
|---|---|
| First post | 2021-09-20 10:54 +0430 |
| Last post | 2021-10-21 13:15 +0200 |
| Articles | 20 on this page of 119 — 23 participants |
Back to article view | Back to comp.lang.c
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
Page 1 of 6 [1] 2 3 4 5 6 Next page →
| From | Mehdi Amini <atorrses@gmail.com> |
|---|---|
| Date | 2021-09-20 10:54 +0430 |
| Subject | C23 (C2x) changes |
| Message-ID | <si99fr$ma4$1@dont-email.me> |
Hi, It seems these are some of changes for C23(C2x) standard taken from draft documents: https://en.cppreference.com/w/c/23 https://thephd.dev/c-the-improvements-june-september-virtual-c-meeting What do you think of changes ? One minor suggestion for me is to have format specifier for bool type in printf function. Even though currently the fix is a trivial one.
[toc] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-20 09:35 +0200 |
| Message-ID | <si9dkd$sfs$1@dont-email.me> |
| In reply to | #162767 |
On 20/09/2021 08:24, Mehdi Amini wrote: > Hi, > > It seems these are some of changes for C23(C2x) standard taken from > draft documents: > > https://en.cppreference.com/w/c/23 > https://thephd.dev/c-the-improvements-june-september-virtual-c-meeting > > What do you think of changes ? > > One minor suggestion for me is to have format specifier for bool type in > printf function. Even though currently the fix is a trivial one. I like the binary literals and digit separators (apostrophes were the best option available for C++, and consistency with C++ is IMHO more important than, say, using underscores would be). Printf formatting characters for binary are a nice idea, but they will be a bit limited if there is no support for digit separators in the output. And if we can write "%w32u" in printf instead of using the PRIu32 macro, then that will be a noticeable improvement. The "thephd.dev" page makes the usual mistake of thinking that defined and guaranteed incorrect results for integer overflow are better than undefined behaviour that can be found using debugging aids, but it's nice to see gcc's __builtin_overflow functions get standardised so that code can be made more portable. I don't see _BitInt(n) being nearly as big a change to embedded development as the webpage author suggests. Part of that is the conservatism common in embedded development - people are still writing /new/ code to C90 standard. The other is that integral promotions are not as difficult to understand as he makes out (though I personally would be happier without them in most situations). It's nice to see old-style function declarations /finally/ being removed. That will turn a lot of bad source code into compile-time broken code, instead of bad binaries. And there are a number of small improvements. All in all, I will be happy to switch to C23. There are plenty of things there that I have no interest in (but presumably others want), and nothing game-changing, but some things that are a little nicer, and that's good.
[toc] | [prev] | [next] | [standalone]
| From | Mehdi Amini <atorrses@gmail.com> |
|---|---|
| Date | 2021-09-21 11:01 +0430 |
| Message-ID | <sibu8b$v2r$1@dont-email.me> |
| In reply to | #162768 |
On 9/20/21 12:05 PM, David Brown wrote: > On 20/09/2021 08:24, Mehdi Amini wrote: >> Hi, >> >> It seems these are some of changes for C23(C2x) standard taken from >> draft documents: >> >> https://en.cppreference.com/w/c/23 >> https://thephd.dev/c-the-improvements-june-september-virtual-c-meeting >> >> What do you think of changes ? >> >> One minor suggestion for me is to have format specifier for bool type in >> printf function. Even though currently the fix is a trivial one. > > I like the binary literals and digit separators (apostrophes were the > best option available for C++, and consistency with C++ is IMHO more > important than, say, using underscores would be). Printf formatting > characters for binary are a nice idea, but they will be a bit limited if > there is no support for digit separators in the output. And if we can > write "%w32u" in printf instead of using the PRIu32 macro, then that > will be a noticeable improvement. > Without digit separators I had to count digits one by one and that was tough to do. So it is an improvement for me. Also PRI macros divide the the printf's first argument. I do not like the look of it. So I agree with you here. [...] > It's nice to see old-style function declarations /finally/ being > removed. That will turn a lot of bad source code into compile-time > broken code, instead of bad binaries. And there are a number of small > improvements. Maybe "late better than never" holds here. > > All in all, I will be happy to switch to C23. There are plenty of > things there that I have no interest in (but presumably others want), > and nothing game-changing, but some things that are a little nicer, and > that's good. > > C23 could be a progress compared to previous C standards. Thank you for detailed answer.
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2021-09-20 10:41 -0500 |
| Message-ID | <siaa3b$t76$1@dont-email.me> |
| In reply to | #162767 |
On 9/20/21 1:24 AM, Mehdi Amini wrote:
> Hi,
>
> It seems these are some of changes for C23(C2x) standard taken from
> draft documents:
>
> https://en.cppreference.com/w/c/23
> https://thephd.dev/c-the-improvements-june-september-virtual-c-meeting
>
> What do you think of changes ?
>
> One minor suggestion for me is to have format specifier for bool type in
> printf function. Even though currently the fix is a trivial one.
Support for decimal floating point will come in handy for those of us
doing financial calculations.
Attribute support looks interesting - I don't do a lot of stuff that
uses __attribute__ or __declspec, but it would be nice to have a
unified syntax for that stuff.
Allowing unnamed function parameters looks weird, but I can immediately
see one place they'd be useful - if you have a lookup table of
functions, they all have to have the same signature:
void (*lookup[])(int *, char *, double) = { foo, bar, bletch, ... };
foo and bar may use all three parameters, but bletch may only need to
use one of them. So instead of bletch having to reference the unused
parameters to avoid a "defined but not used" diagnostic, a la:
void bletch( int *p, char *s, double f )
{
(void) *p;
(void) *s;
// do something with f
}
it could simply just not name them:
void bletch( int *, char *, double f )
{
// do something with f
}
and avoid that altogether.
Shitcanning old-style function definitions is long overdue - yes, I'm
sure this will break a non-trivial amount of legacy code, but dammit,
a lot of that code *needs* to be broken so it can be properly updated.
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?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-20 18:17 +0200 |
| Message-ID | <siac7m$8r0$1@dont-email.me> |
| In reply to | #162769 |
On 20/09/2021 17:41, John Bode wrote:
> On 9/20/21 1:24 AM, Mehdi Amini wrote:
>> Hi,
>>
>> It seems these are some of changes for C23(C2x) standard taken from
>> draft documents:
>>
>> https://en.cppreference.com/w/c/23
>> https://thephd.dev/c-the-improvements-june-september-virtual-c-meeting
>>
>> What do you think of changes ?
>>
>> One minor suggestion for me is to have format specifier for bool type
>> in printf function. Even though currently the fix is a trivial one.
>
> Support for decimal floating point will come in handy for those of us
> doing financial calculations.
>
> Attribute support looks interesting - I don't do a lot of stuff that
> uses __attribute__ or __declspec, but it would be nice to have a
> unified syntax for that stuff.
>
> Allowing unnamed function parameters looks weird, but I can immediately
> see one place they'd be useful - if you have a lookup table of
> functions, they all have to have the same signature:
>
> void (*lookup[])(int *, char *, double) = { foo, bar, bletch, ... };
>
> foo and bar may use all three parameters, but bletch may only need to
> use one of them. So instead of bletch having to reference the unused
> parameters to avoid a "defined but not used" diagnostic, a la:
>
> void bletch( int *p, char *s, double f )
> {
> (void) *p;
> (void) *s;
>
> // do something with f
> }
>
> it could simply just not name them:
>
> void bletch( int *, char *, double f )
> {
> // do something with f
> }
>
> and avoid that altogether.
Yes, I believe that is the main point. It is also a cheap and easy
feature that increases compatibility with C++ slightly, which is never a
bad thing (as long as it doesn't hinder good C coding, of course). It
is not as important a feature in C as it is in C++, where the unnamed
parameter still takes part in overload resolution.
>
> Shitcanning old-style function definitions is long overdue - yes, I'm
> sure this will break a non-trivial amount of legacy code, but dammit,
> a lot of that code *needs* to be broken so it can be properly updated.
>
It's about 30 years overdue - once C had a hugely better way of
declaring functions in C90, it should have been pushed /fast/ - first
compiler warnings, then rejecting the code. Compilers could have had
flags to support compilation of old code. (I'm all in favour of
supporting old code in new tools, but we don't want people to keep
writing new old code!)
> 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.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-20 18:55 +0100 |
| Message-ID | <siahul$tb8$1@dont-email.me> |
| In reply to | #162770 |
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! 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.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-09-20 18:21 +0000 |
| Message-ID | <ri42J.35641$rsCb.24772@fx01.iad> |
| In reply to | #162771 |
Bart <bc@freeuk.com> writes: >On 20/09/2021 17:17, David Brown wrote: >> On 20/09/2021 17:41, John Bode wrote: >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! What makes sense is that programmers should understand the domain they're programming in, understand the constraints placed on that domain by their choice of programming language, and write their program accordingly. Which means they would never add 1 to a pile of 2^32 apples because is it a senseless thing to do.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-20 21:39 +0200 |
| Message-ID | <siao15$qbr$1@dont-email.me> |
| In reply to | #162771 |
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?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-20 21:07 +0100 |
| Message-ID | <siaplj$r7d$1@dont-email.me> |
| In reply to | #162775 |
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? Note that with (uint32.max + 1) - 1, it seems to be acceptable to get an intermediate out-of-range result.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-20 22:59 +0200 |
| Message-ID | <siasoc$m4t$1@dont-email.me> |
| In reply to | #162778 |
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. > 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.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-20 22:29 +0100 |
| Message-ID | <siaufp$mhq$1@dont-email.me> |
| In reply to | #162779 |
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?
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.
The next two are also always different except with gcc (at any
optimisation level).
So you now have a program whose behaviour depends on compiler.
(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.
The reason: intermediate results are 64 bits not 32. I won't see the
same issue until the numbers are 4 billion times bigger in magnitude.)
>> 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.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-09-20 17:43 -0700 |
| Message-ID | <877dfapxlg.fsf@nosuchdomain.example.com> |
| In reply to | #162780 |
Bart <bc@freeuk.com> writes:
[...]
> 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. The behavior is well defined for unsigned intefers, and
turning *6/3 into *2 would result in incorrect code (unless the compiler
can prove that the value cannot wrap, which is not the case here).
> The next two are also always different except with gcc (at any
> optimisation level).
>
> So you now have a program whose behaviour depends on compiler.
You have a program whose behavior is undefined.
[...]
> So, a cop-out. Just define similar behaviour with signed values.
No.
The way C defines integer arithmetic is a compromise, largely guided by
(and guiding) how hardware arithmetic works. It might be useful to have
signed integers with well defined behavior on overflow, unsigned
integers that trap on overflow, and a number of other combinations. A
larger language might allow the programmer to define integer types with
attributes that specify that kind of thing. C doesn't.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-21 17:56 +0200 |
| Message-ID | <sicvbp$m4m$1@dont-email.me> |
| In reply to | #162780 |
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?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-21 18:05 +0100 |
| Message-ID | <sid3cs$ls5$1@dont-email.me> |
| In reply to | #162797 |
On 21/09/2021 16:56, David Brown wrote: > On 20/09/2021 23:29, Bart wrote: >> On 20/09/2021 21:59, David Brown wrote: >> 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. clang and MSVC failed to do that optimisation. (I think icc did, but only on godbolt.) Plus four other compilers. > 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. If your code is compiled by someone else, then you don't know what compiler they will use and which options. >> (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. In the case of my language, no actual overflow occurs, since I'm using 64-bit intermediates even with int32 types. So the results are correct, as they are in range by the time the result is stored into the 32-bit destination. > (On the other hand, I /do/ see the appeal of using 64-bit types on > 64-bit systems.) You don't necessarily need to use 64-bit types; just so long as calculations are done as 64 bits. C's sticking with 32 bits means massively more opportunities for overflow which would be considerably rarer with 64 bits. >> So, a cop-out. Just define similar behaviour with signed values. >> > > Unsigned integer arithmetic is defined differently in C. It's a design > decision. Do you have a link to say that this is what the designers had in mind when they added unsigned integers? Because it sounds more like this modulo business was conveniently defined much later on. > (Often I'd prefer unsigned integers overflow to be undefined > too, as overflow is usually a bug in the code. Exactly. Sometimes wraparound is intentional, but on both signed and unsigned. And it can be unintentional - on both. > 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? The practical use is not having to care. Usually the numbers will sort themselves out in the same way they do for unsigned. And actually, the real uses are not up to me; my language says wrapping signed integers is well-defined; so does the target hardware. But if I happen to be using intermediate C, now suddenly it can screw everything up. Somebody using my language will need see the behaviour that is promised. If any overflow is inadvertent, and causes a problem, then I will see a bug in my program, which /might/ be traced to getting a negative value when it should be positive. But if the code is passed through an optimising C compiler, I might not see that, and the bug will be more subtle.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-09-21 11:42 -0700 |
| Message-ID | <87pmt1ojmu.fsf@nosuchdomain.example.com> |
| In reply to | #162798 |
Bart <bc@freeuk.com> writes:
> On 21/09/2021 16:56, David Brown wrote:
[...]
> If your code is compiled by someone else, then you don't know what
> compiler they will use and which options.
An excellent reason to avoid writing code whose behavior may be
undefined.
[...]
> In the case of my language, no actual overflow occurs, since I'm using
> 64-bit intermediates even with int32 types. So the results are
> correct, as they are in range by the time the result is stored into
> the 32-bit destination.
Good for you. C doesn't do that.
[...]
> You don't necessarily need to use 64-bit types; just so long as
> calculations are done as 64 bits. C's sticking with 32 bits means
> massively more opportunities for overflow which would be considerably
> rarer with 64 bits.
Presumably your language does *something* on overflow when the user
actually uses 64-bit types. (I'm not asking what that is.)
C did not stick with 32 bits. Most C implementations did (for reasons
I've discussed before). I've used C compilers with 64-bit int.
[...]
>> Unsigned integer arithmetic is defined differently in C. It's a
>> design
>> decision.
>
> Do you have a link to say that this is what the designers had in mind
> when they added unsigned integers? Because it sounds more like this
> modulo business was conveniently defined much later on.
I haven't found one. I believe it was deliberate, but I'm not certain.
Given that it's now unambiguously defined that way, it doesn't matter
much to me whether it was deliberate or not.
>> (Often I'd prefer unsigned integers overflow to be undefined
>> too, as overflow is usually a bug in the code.
>
> Exactly. Sometimes wraparound is intentional, but on both signed and
> unsigned. And it can be unintentional - on both.
>
>> 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?
>
> The practical use is not having to care. Usually the numbers will sort
> themselves out in the same way they do for unsigned.
Oh? If you have a counter whose current value is UINT_MAX and you
increment it, it goes to 0. How does that sort itself out?
You just have to be aware of how signed and unsigned types work.
> And actually, the real uses are not up to me; my language says
> wrapping signed integers is well-defined; so does the target
> hardware. But if I happen to be using intermediate C, now suddenly it
> can screw everything up.
>
> Somebody using my language will need see the behaviour that is promised.
Right. If your source language and your target language have
different semantics, you'll need to do some extra work to make sure
that the resulting code has the desired behavior. I sympathize
with your difficulties, but C is not going to change to meet your
requirements no matter how much you complain.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-22 11:37 +0200 |
| Message-ID | <sietha$or3$1@dont-email.me> |
| In reply to | #162798 |
On 21/09/2021 19:05, Bart wrote: > On 21/09/2021 16:56, David Brown wrote: >> On 20/09/2021 23:29, Bart wrote: >>> On 20/09/2021 21:59, David Brown wrote: > >>> 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. > > clang and MSVC failed to do that optimisation. (I think icc did, but > only on godbolt.) Plus four other compilers. > It doesn't matter what particular optimisations or output you get from code that does not have defined behaviour. It might happen to do exactly what you expect (whatever that might be), or something entirely different. The point is that you cannot take a simple example like that and extrapolate from it that "most" C compilers have wrapping signed integers or don't do a particular optimisation. That is pure nonsense. If you want wrapping signed integers, stick to a compiler that /documents/ it supports them. MSVC is not such a compiler, nor are clang, gcc or icc. Both gcc and clang (and maybe also icc, I haven't checked) support a "-fwrapv" flag to give you a mode that /does/ wrap signed integers. MSVC has no such official option, merely an undocumented flag (see <https://devblogs.microsoft.com/cppblog/new-code-optimizer/>). > > >> 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. > > If your code is compiled by someone else, then you don't know what > compiler they will use and which options. That means it is usually a good idea to write code that has defined behaviour according to the C standard, rather than relying on imagined and undocumented behaviour. That way you get the same results, every time and from every compiler (baring implementation-defined behaviour). > >>> So, a cop-out. Just define similar behaviour with signed values. >>> >> >> Unsigned integer arithmetic is defined differently in C. It's a design >> decision. > > Do you have a link to say that this is what the designers had in mind > when they added unsigned integers? Because it sounds more like this > modulo business was conveniently defined much later on. > The introduction of unsigned integers predates K&R version 1 C, and I don't know the history. > >> (Often I'd prefer unsigned integers overflow to be undefined >> too, as overflow is usually a bug in the code. > > Exactly. Sometimes wraparound is intentional, but on both signed and > unsigned. And it can be unintentional - on both. > Yes. But as you failed to come up with even a single example of why signed wraparound would be useful, I think it is safe to suggest that almost all signed overflows are errors in the code. Modulo behaviour on unsigned types is useful on occasion when you are modelling the lower bits of a counter or timer, or when implementing arithmetic routines for larger types. Still, overflow on unsigned types is also usually an error. >> 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? > > The practical use is not having to care. Usually the numbers will sort > themselves out in the same way they do for unsigned. > Right - no practical uses that you can describe.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-22 11:55 +0100 |
| Message-ID | <sif23j$nho$1@dont-email.me> |
| In reply to | #162812 |
On 22/09/2021 10:37, David Brown wrote:
> On 21/09/2021 19:05, Bart wrote:
>> On 21/09/2021 16:56, David Brown wrote:
>>> On 20/09/2021 23:29, Bart wrote:
>>>> On 20/09/2021 21:59, David Brown wrote:
>>
>>>> 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.
>>
>> clang and MSVC failed to do that optimisation. (I think icc did, but
>> only on godbolt.) Plus four other compilers.
>>
>
> It doesn't matter what particular optimisations or output you get from
> code that does not have defined behaviour. It might happen to do
> exactly what you expect (whatever that might be), or something entirely
> different.
>
> The point is that you cannot take a simple example like that and
> extrapolate from it that "most" C compilers have wrapping signed
> integers or don't do a particular optimisation. That is pure nonsense.
I would MUCH rather that all compilers had consistent behaviour. I WANT
those last two lines of my example to be different - guaranteed. Only
gcc (and maybe icc) are the exceptions.
> If you want wrapping signed integers, stick to a compiler that
> /documents/ it supports them. MSVC is not such a compiler, nor are
> clang, gcc or icc. Both gcc and clang (and maybe also icc, I haven't
> checked) support a "-fwrapv" flag to give you a mode that /does/ wrap
> signed integers.
Why? What practical use is that, since you postulate that there is none?
>> If your code is compiled by someone else, then you don't know what
>> compiler they will use and which options.
>
> That means it is usually a good idea to write code that has defined
> behaviour according to the C standard,
You mean according to tables like this, which tells you if a result is
signed or unsigned:
u8 u16 u32 u64 i8 i16 i32 i64
u8 S S U U S S S S
u16 S S U U S S S S
u32 U U U U U U U S
u64 U U U U U U U U
i8 S S U U S S S S
i16 S S U U S S S S
i32 S S U U S S S S
i64 S S S U S S S S
Actually I do do something like that in my latest attempt at a C
backend, but it only uses 2 of those 64 combinations (u64/u64 or
i64/i64). It generates this code for 'a:=b+c':
u64 S1, S2;
i64 a;
i64 b;
i64 c;
S1 = b;
S2 = c;
*(i64*)&S1 += (i64)S2;
a = S1;
Lovely.
>> The practical use is not having to care. Usually the numbers will sort
>> themselves out in the same way they do for unsigned.
>>
>
> Right - no practical uses that you can describe.
Well, look at evaluating -(-a)) when a has type int64 and has the value
int64.min.
Technically you will get overflow part-way through, but it will sort
itself out in the end, as I said. That's if it even does the
calculation, as the compiler may turn two negates into unary plus, which
is a no-op.
You just shouldn't need to worry about what happens in these edge
cases; you should have confidence that it will work out. Either that you
end up with a valid in-range result; or an expected overflow result that
you might need to do something about; or an expected overflow result
that you know you can ignore.
You shouldn't have to keep looking over your shoulder at the compiler
and trying to double-guess what /it/ might end up doing.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-09-22 14:21 +0200 |
| Message-ID | <sif758$rd8$1@dont-email.me> |
| In reply to | #162813 |
On 22/09/2021 12:55, Bart wrote:
> On 22/09/2021 10:37, David Brown wrote:
>> On 21/09/2021 19:05, Bart wrote:
>>> On 21/09/2021 16:56, David Brown wrote:
>>>> On 20/09/2021 23:29, Bart wrote:
>>>>> On 20/09/2021 21:59, David Brown wrote:
>>>
>>>>> 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.
>>>
>>> clang and MSVC failed to do that optimisation. (I think icc did, but
>>> only on godbolt.) Plus four other compilers.
>>>
>>
>> It doesn't matter what particular optimisations or output you get from
>> code that does not have defined behaviour. It might happen to do
>> exactly what you expect (whatever that might be), or something entirely
>> different.
>>
>> The point is that you cannot take a simple example like that and
>> extrapolate from it that "most" C compilers have wrapping signed
>> integers or don't do a particular optimisation. That is pure nonsense.
>
> I would MUCH rather that all compilers had consistent behaviour. I WANT
> those last two lines of my example to be different - guaranteed. Only
> gcc (and maybe icc) are the exceptions.
I understand that's what you want - although I still can't understand
/why/ such things are important to you. It's like telling people that
you once ran across the road, got knocked down, and broke your left leg
- and now you want traffic regulations and car driving to be changed to
ensure that every time you run across the road, you /always/ get knocked
down and /always/ break your left leg. It is simply bizarre to me - the
language rules say "don't let your signed integer arithmetic overflow",
so don't do that - and don't expect any particular given result if /you/
choose to do something stupid.
>
>> If you want wrapping signed integers, stick to a compiler that
>> /documents/ it supports them. MSVC is not such a compiler, nor are
>> clang, gcc or icc. Both gcc and clang (and maybe also icc, I haven't
>> checked) support a "-fwrapv" flag to give you a mode that /does/ wrap
>> signed integers.
>
> Why? What practical use is that, since you postulate that there is none?
>
/I/ don't see a good reason for using it. But other people /do/
sometimes write code that relies on wrapping overflow. Ironically, one
of the common uses is for determining if there was an overflow. To me,
that's like jumping off a wall without looking and judging its height by
the injuries you get - which you expect to be consistent. I'd prefer to
look first, and only jump if it is safe. But /if/ you have a compiler
that /guarantees/ wrapping behaviour, then of course it is valid to rely
on it in code for that particular compiler.
>
>>> If your code is compiled by someone else, then you don't know what
>>> compiler they will use and which options.
>>
>> That means it is usually a good idea to write code that has defined
>> behaviour according to the C standard,
>
> You mean according to tables like this, which tells you if a result is
> signed or unsigned:
>
> u8 u16 u32 u64 i8 i16 i32 i64
>
> u8 S S U U S S S S
> u16 S S U U S S S S
> u32 U U U U U U U S
> u64 U U U U U U U U
>
> i8 S S U U S S S S
> i16 S S U U S S S S
> i32 S S U U S S S S
> i64 S S S U S S S S
>
You use whatever types, operations and rules are defined by the
language. And if you personally don't like the rules for particular
combinations, don't write code that uses those combinations. (I avoid
mixing signed and unsigned types in expressions, baring a few simple cases.)
Really, the main thing is not whether you like the complete set of rules
for a language or not - but that you know what they are, and write code
that follows them.
The most insane option is to learn the rules of the language, realise
that your own preferences are for slightly different rules, and then
write code in the language as though it were your own rules that applied.
> Actually I do do something like that in my latest attempt at a C
> backend, but it only uses 2 of those 64 combinations (u64/u64 or
> i64/i64). It generates this code for 'a:=b+c':
>
> u64 S1, S2;
> i64 a;
> i64 b;
> i64 c;
> S1 = b;
> S2 = c;
> *(i64*)&S1 += (i64)S2;
> a = S1;
>
> Lovely.
And silly.
If you have two 64-bit signed integers "b" and "c", and want to add them
with guaranteed two's complement wrapping on a "normal" system (i.e.,
not some ones' complement dinosaur or a 24-bit DSP with saturating
arithmetic, or anything odd) then the code you want is a support function:
static inline int64_t _add_64(int64_t x, int64_t y) {
return (uint64_t) x + (uint64_t) y;
}
Then the code to generate for "a := b + c" is :
a = _add_64(b, c);
But that would be too easy - making it overly complicated is better for
your martyr complex.
>
>>> The practical use is not having to care. Usually the numbers will sort
>>> themselves out in the same way they do for unsigned.
>>>
>>
>> Right - no practical uses that you can describe.
>
> Well, look at evaluating -(-a)) when a has type int64 and has the value
> int64.min.
>
Why look at that? When would that ever occur in real practical code?
>
> You shouldn't have to keep looking over your shoulder at the compiler
> and trying to double-guess what /it/ might end up doing.
>
I don't keep guessing and worrying - only /you/ seem to do that. I
write code that makes sense, and my arithmetic does not overflow. I
never guess (or care) what the compiler might do when faced with signed
overflows or other undefined behaviour - I don't write code with
undefined behaviour.
(Well, except for bugs in my code - I don't get everything right first
time! But if the mistakes result in undefined behaviour rather than
meaningless but defined behaviour, then I have a better chance of the
mistakes being found automatically by my tools rather than during
lengthy testing and debugging.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-09-22 13:58 +0100 |
| Message-ID | <sif99a$bed$1@dont-email.me> |
| In reply to | #162814 |
On 22/09/2021 13:21, David Brown wrote:
> On 22/09/2021 12:55, Bart wrote:
>> Actually I do do something like that in my latest attempt at a C
>> backend, but it only uses 2 of those 64 combinations (u64/u64 or
>> i64/i64). It generates this code for 'a:=b+c':
>>
>> u64 S1, S2;
>> i64 a;
>> i64 b;
>> i64 c;
>> S1 = b;
>> S2 = c;
>> *(i64*)&S1 += (i64)S2;
>> a = S1;
>>
>> Lovely.
>
> And silly.
>
> If you have two 64-bit signed integers "b" and "c", and want to add them
> with guaranteed two's complement wrapping on a "normal" system (i.e.,
> not some ones' complement dinosaur or a 24-bit DSP with saturating
> arithmetic, or anything odd) then the code you want is a support function:
>
> static inline int64_t _add_64(int64_t x, int64_t y) {
> return (uint64_t) x + (uint64_t) y;
> }
>
> Then the code to generate for "a := b + c" is :
>
> a = _add_64(b, c);
>
>
> But that would be too easy - making it overly complicated is better for
> your martyr complex.
This is the input code for that C backend:
local a i64
local b i64
local c i64
push b i64
push c i64
add i64
pop a i64
It's a linear, stack-based, typed bytecode. The translation to C is done
an instruction at a time with no knowledge of what came before or what
come next.
The only context is the stack, which is a nominal array of u64 values.
In my example the stack is represented by the locals S1 and S2, which
are always u64.
The 'add i64' operation has to perform: S1 = S1 + S2, but using signed
semantics.
The resulting mess of C source requires, unusually, a heavyweight
optimiser to remove all the redunduncies.
Using approaches like your _add_i64() function might work, but doesn't
reduce the line count, and it would add to the compiler's burden.
It becomes tricky with _add_f64() since type punning would be needed (on
the arguments, and the resuls): the arguments will still be u64 types.
[toc] | [prev] | [next] | [standalone]
| From | Ian Pilcher <arequipeno@gmail.com> |
|---|---|
| Date | 2021-09-22 12:02 -0500 |
| Message-ID | <sifnk0$nvi$1@dont-email.me> |
| In reply to | #162797 |
On 9/21/21 10:56, David Brown wrote: > What do you see as the practical uses of having wrapping in signed > integers? I haven't seen this mentioned, so ... after the fact overflow detection seems like a nice thing that we can't currently have. -- ======================================================================== Ian Pilcher arequipeno@gmail.com -------- "I grew up before Mark Zuckerberg invented friendship" -------- ========================================================================
[toc] | [prev] | [next] | [standalone]
Page 1 of 6 [1] 2 3 4 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web