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.

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.

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?

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.

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.

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.

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?

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.

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.

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.

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:

>>> 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?

Try this program, where the number of applies is represented with an
8-bit value:

int8_t apples;

apples = 127;
printf("Initial pile of apples: %d\n",apples);
apples += 1;
printf("After adding one more apple: %d\n",apples);
apples -= 1;
printf("After removing an apple: %d\n",apples);

The number of apples goes from 127 to -128, and back to 127, just like
my example using 32 bits.

Yet, this is not NOT undefined behaviour, and is suddenly sensible in
the eyes of C?

Same with 16 bits. And same with 32 bits IF C had adopted a 64-bit int.

All I see is inconsistency if you say one is UB but not another.

Bart <bc@freeuk.com> writes:
>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:
>
>>>> 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?
>
>Try this program, where the number of applies is represented with an
>8-bit value:
>
> int8_t apples;
>
> apples = 127;
> printf("Initial pile of apples: %d\n",apples);
if (apples < CHAR_MAX) {
> apples += 1;
} else {
panic("Logic error by the unqualified C programmer\n");
}

fixed it for you.

On Mon, 20 Sep 2021 22:47:23 +0000, Scott Lurndal wrote:

> Bart <bc@freeuk.com> writes:
[snip]
>>Try this program, where the number of applies is represented with an
>>8-bit value:
>>
>> int8_t apples;
>>
>> apples = 127;
>> printf("Initial pile of apples: %d\n",apples);
> if (apples < CHAR_MAX) {
>> apples += 1;
> } else {
> panic("Logic error by the unqualified C programmer\n");
> }
>
> fixed it for you.

Oh, snap!

--
Lew Pitcher
"In Skills, We Trust"

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 */

Bart <bc@freeuk.com> writes:
[...]
> All I see is inconsistency if you say one is UB but not another.

That's all you want to see.

--
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 */

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.

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?

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.

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 */

Mehdi Amini <atorrses@gmail.com> 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.

The addition of #elifdef and #elifndef is just unnecessary complexity. Some
people seem to dislike using defined() because there are some relatively
modern coding style guides that prohibit use of defined or even any other
preprocessor operators; instead they limit preprocessor usage to simple
directives like #include and #ifdef. These style guides have created a
narrative that complex use of the preprocessor should be categorically
avoided. There's more than a little irony in adding preprocessor complexity
at the behest of folks who fundamentally abhor the preprocessor.

I do like the addition of __has_include for improving the ability to perform
feature checking directly from the preprocessor. But IME at least as
important as __has_include for preprocessor-based feature checking, if not
more important, is the ability to use the defined operator in macros. For
example,

#ifndef HAVE_STRUCT_STAT_ST_ATIMESPEC
#define HAVE_STRUCT_STAT_ST_ATIMESPEC (__APPLE__ || defined st_atimespec || defined st_atimensec)
#endif

Using HAVE_STRUCT_STAT_ST_ATIMESPEC in another preprocess conditional isn't
well-defined C, although it's widely supported (Visual Studio being a major
outlier). Instead you have to do

#if __APPLE__ || defined st_atimespec || defined st_atimensec
#define HAVE_STRUCT_STAT_ST_ATIMESPEC 1
#else
#define HAVE_STRUCT_STAT_ST_ATIMESPEC 0
#endif

which nearly doubles the lines of code needed for a simple feature check.
(NOTE: Unlike autoconf, I conditionally define HAVE macros in my code so
that the build engineer can choose to override the feature detection by
predefining the macro value.)

More importantly, the former evaluates lazily at point of use, while the
latter evaluates immediately, requiring the compilation unit to have already
#include'd <sys/stat.h>. That makes it very difficult to put a bunch of
generic preprocessor checks in a separate header library as you either need
to rely on the user including the correct headers or the feature check
header must include them unconditionally, polluting the namespace and
possibly changing semantics.

I maintain a project where I version some pure preprocessor-based feature
checks for common Unix platforms:

https://github.com/wahern/autoguess

I once tried refactoring everything to standard C after clang default
enabled its -Wexpansion-to-defined warning, but the refactor proved too
unwieldly and, more importantly, ultimately unworkable given the need to
implicitly include problematic headers like <pthread.h> in the absence of
lazy evaluation. (There are some implicit #include's, but __has_include
would have helped rid some of them.)

Even better than well-defined defined operator expansions would be the
ability to test the presence of function definitions, type definitions, and
aggregate members, but that's probably a bridge too far.

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.

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.

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.)

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.

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" --------
========================================================================