Ian Pilcher <arequipeno@gmail.com> writes:
>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.

ADD ORDER-QUANTITY TO CUSTOMER-TOTAL-ORDERS ON OVERFLOW PERFORM HANDLE-QTY-OVERFLOW.

Sometimes the task defines the choice of language.

Le 20/09/2021 à 08:24, Mehdi Amini a écrit :
> 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 ?

Dunno - not that impressive. Don't get me wrong, I prefer the
conservative approach of the C std committee to the approach of the C++
one, which yields monsters.

But this looks like relatively minor improvements to me.

What I would like to see in a new C revision:
- Modules;
- Tagged blocks/tagged loop constructs.

The tagged loop thing could look like this:

outer_loop: for (i = 0; i < n; i++)
{ for (j = 0; j < i; j++)
{
...
if (...)
break outer_loop;
}
}

That would be more elegant and easier to statically analyze than goto's.
The syntax could be different, it's just to show the point. In
particular, to avoid confusion with goto labels, it could instead be
something like:

for outer_loop (i = 0; i < n; i++)
....

As to modules, that could be taken from C++20(?) modules, although I
think those are not that great, but that's a start.

Am 22.09.21 um 20:27 schrieb Guillaume:

> - Tagged blocks/tagged loop constructs.
>
>[…]
>
> That would be more elegant and easier to statically analyze than goto's.

No. It would not be better than goto. Neither for users nor for static
analysis. AFAIK this has been proposed and rejected multiple times
before (e.g. N1989 at the London 2016 WG14 meeting).

Regarding analysis (and likely also code readability), one important
parameter is the tree-width of the control-flow graph. For C this is
bounded by a constant plus the number of labels for goto used per
function. The situation is similar for many other languages. And at
least for tree-width, it has been proven that unlimited use of labeled
break / labeled continue, like Java has, would be just as bad as
unlimited use of goto.

If you need to get out of an inner loop, just use goto. Avoiding goto by
introducing another variant of goto that just isn't called goto won't
make the standard better.

Philipp Klaus Krause <pkk@spth.de> writes:
> Am 22.09.21 um 20:27 schrieb Guillaume:
>
>> - Tagged blocks/tagged loop constructs.
>>
>>[…]
>>
>> That would be more elegant and easier to statically analyze than goto's.
>
> No. It would not be better than goto. Neither for users nor for static
> analysis. AFAIK this has been proposed and rejected multiple times
> before (e.g. N1989 at the London 2016 WG14 meeting).
>
> Regarding analysis (and likely also code readability), one important
> parameter is the tree-width of the control-flow graph. For C this is
> bounded by a constant plus the number of labels for goto used per
> function. The situation is similar for many other languages. And at
> least for tree-width, it has been proven that unlimited use of labeled
> break / labeled continue, like Java has, would be just as bad as
> unlimited use of goto.
>
> If you need to get out of an inner loop, just use goto. Avoiding goto by
> introducing another variant of goto that just isn't called goto won't
> make the standard better.

The proposal in N1989
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1989.htm
was to have "break 2;" break out of two enclosing loops. (The Bourne
shell has this feature.) Personally, I dislike this. It's easy to
forget to update the number when the code is rearranged, and it forces
the programmer and reader to count nesting levels -- and counting, after
all, is something that computers are really really good at.

What I'd like to see is *named* loops, with "break" and "continue"
optionally taking an argument that names the loop to be operated on.
I've used other languages with this feature, and I've found it quite
useful.

It would, of course, be equivalent to a goto targeting a point after the
end of the loop ("continue" might be a little more complicated), but the
point is that it's restricted ("break foo" can't jump to an arbitrary
location) and it documents what it's doing.

I think of "break foo" as an operation on the loop named "foo", not an
operation that refers to a specific location in the code.

It would make no difference to static analysis, but in my opinion it
would make for more legible code in the (perhaps not very common) case
where you want to break out of nested loops.

Ada has this feature. It uses a deliberately heavy syntax for goto
labels:

<< LABEL >>
-- ...
goto LABEL;

but a simple identifier followed by a colon for labeled loops:

Loop_Name:
for I in 1..10 loop
-- ...
exit Loop_Name; -- Ada spells "break" as "exit"
end loop;

Perl uses the same syntax for goto labels and loop names, which means if
you see a loop name you can't be sure without checking that there isn't
a goto somewhere that targets it. I haven't found that to be a problem
in practice:

Loop_Name:
for my $i (1 .. 10) {
# ...
last Loop_Name; # Perl spells "break" as "last"
}

In both languages, if you omit the label on a break/exit/last statement
it applies to the innermost enclosing loop. Of course C would have to
do the same.

Off the top of my head, I can't think of a good simple syntax for loop
labels that's distinct from the syntax for goto labels, so perhaps a
"break name" construct could just refer to a goto label that's applied
to an iteration or switch statement. "break foo;" where "foo" is a
label that *doesn't* apply to an iteration or switch statement would be
a constraint violation.

--
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 22/09/2021 22:05, Keith Thompson wrote:
> Philipp Klaus Krause <pkk@spth.de> writes:
>> Am 22.09.21 um 20:27 schrieb Guillaume:
>>
>>> - Tagged blocks/tagged loop constructs.
>>>
>>> […]
>>>
>>> That would be more elegant and easier to statically analyze than goto's.
>>
>> No. It would not be better than goto. Neither for users nor for static
>> analysis. AFAIK this has been proposed and rejected multiple times
>> before (e.g. N1989 at the London 2016 WG14 meeting).
>>
>> Regarding analysis (and likely also code readability), one important
>> parameter is the tree-width of the control-flow graph. For C this is
>> bounded by a constant plus the number of labels for goto used per
>> function. The situation is similar for many other languages. And at
>> least for tree-width, it has been proven that unlimited use of labeled
>> break / labeled continue, like Java has, would be just as bad as
>> unlimited use of goto.
>>
>> If you need to get out of an inner loop, just use goto. Avoiding goto by
>> introducing another variant of goto that just isn't called goto won't
>> make the standard better.
>
> The proposal in N1989
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1989.htm
> was to have "break 2;" break out of two enclosing loops. (The Bourne
> shell has this feature.) Personally, I dislike this. It's easy to
> forget to update the number when the code is rearranged, and it forces
> the programmer and reader to count nesting levels -- and counting, after
> all, is something that computers are really really good at.
>
> What I'd like to see is *named* loops, with "break" and "continue"
> optionally taking an argument that names the loop to be operated on.
> I've used other languages with this feature, and I've found it quite
> useful.

Named loops means having to invent names for things, which can be
annoying when the thing you're refering to is right there.

It makes it harder to copy and paste code within the same function,
since the loop names need to be revised. Unless you invent new scope
rules for those names so that they are local to that set of loops.

Also, if your intention is to break out of an entire set of nested
loops, you label the outer one, but then wrap it with an extra loop
level (or copy it into another loop), that 'outer' loop label may no
longer be the outermost.

I say, keep things simple. While I use numbered loops 1 (innermost) to N
(outermost), I also allow 0 to mean the outermost, so that most often
I'd write:

break # defaults to loop 1, innermost
break all # 'all' is a synonym for 0, so outermost

(Although my syntax uses 'exit' not break.)

Breaking out of any in-between loop is rare. For a start, you'd need 3
nested loop levels, itself uncommon.

On Wednesday, September 22, 2021 at 7:24:45 PM UTC-3, Bart wrote:
> On 22/09/2021 22:05, Keith Thompson wrote:
> > Philipp Klaus Krause <p...@spth.de> writes:
> >> Am 22.09.21 um 20:27 schrieb Guillaume:
> >>
> >>> - Tagged blocks/tagged loop constructs.
> >>>
> >>> […]
> >>>
> >>> That would be more elegant and easier to statically analyze than goto's.
> >>
> >> No. It would not be better than goto. Neither for users nor for static
> >> analysis. AFAIK this has been proposed and rejected multiple times
> >> before (e.g. N1989 at the London 2016 WG14 meeting).
> >>
> >> Regarding analysis (and likely also code readability), one important
> >> parameter is the tree-width of the control-flow graph. For C this is
> >> bounded by a constant plus the number of labels for goto used per
> >> function. The situation is similar for many other languages. And at
> >> least for tree-width, it has been proven that unlimited use of labeled
> >> break / labeled continue, like Java has, would be just as bad as
> >> unlimited use of goto.
> >>
> >> If you need to get out of an inner loop, just use goto. Avoiding goto by
> >> introducing another variant of goto that just isn't called goto won't
> >> make the standard better.
> >
> > The proposal in N1989
> > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1989.htm
> > was to have "break 2;" break out of two enclosing loops. (The Bourne
> > shell has this feature.) Personally, I dislike this. It's easy to
> > forget to update the number when the code is rearranged, and it forces
> > the programmer and reader to count nesting levels -- and counting, after
> > all, is something that computers are really really good at.
> >
> > What I'd like to see is *named* loops, with "break" and "continue"
> > optionally taking an argument that names the loop to be operated on.
> > I've used other languages with this feature, and I've found it quite
> > useful.
> Named loops means having to invent names for things, which can be
> annoying when the thing you're refering to is right there.
>
> It makes it harder to copy and paste code within the same function,
> since the loop names need to be revised. Unless you invent new scope
> rules for those names so that they are local to that set of loops.
>
> Also, if your intention is to break out of an entire set of nested
> loops, you label the outer one, but then wrap it with an extra loop
> level (or copy it into another loop), that 'outer' loop label may no
> longer be the outermost.
>
> I say, keep things simple. While I use numbered loops 1 (innermost) to N
> (outermost), I also allow 0 to mean the outermost, so that most often
> I'd write:
>
> break # defaults to loop 1, innermost
> break all # 'all' is a synonym for 0, so outermost
>
> (Although my syntax uses 'exit' not break.)
>
> Breaking out of any in-between loop is rare. For a start, you'd need 3
> nested loop levels, itself uncommon.

If you have a label it is as bad as goto.

We need more kinds of structured jumps.
I have suggested try throw catch (because I didn't find better name)
that are basically a local jump to catch - doesn't matter if you are inside
loops or not.

Traditional loop operators are so old and all the languages
have the same, so it's hard to get used to new jump names.

Le 22/09/2021 à 23:05, Keith Thompson a écrit :
> Philipp Klaus Krause <pkk@spth.de> writes:
>> Am 22.09.21 um 20:27 schrieb Guillaume:
>>
>>> - Tagged blocks/tagged loop constructs.
>>>
>>> […]
>>>
>>> That would be more elegant and easier to statically analyze than goto's.
>>
>> No. It would not be better than goto. Neither for users nor for static
>> analysis. AFAIK this has been proposed and rejected multiple times
>> before (e.g. N1989 at the London 2016 WG14 meeting).
>>
>> Regarding analysis (and likely also code readability), one important
>> parameter is the tree-width of the control-flow graph. For C this is
>> bounded by a constant plus the number of labels for goto used per
>> function. The situation is similar for many other languages. And at
>> least for tree-width, it has been proven that unlimited use of labeled
>> break / labeled continue, like Java has, would be just as bad as
>> unlimited use of goto.
>>
>> If you need to get out of an inner loop, just use goto. Avoiding goto by
>> introducing another variant of goto that just isn't called goto won't
>> make the standard better.
>
> The proposal in N1989
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1989.htm
> was to have "break 2;" break out of two enclosing loops. (The Bourne
> shell has this feature.) Personally, I dislike this. It's easy to
> forget to update the number when the code is rearranged, and it forces
> the programmer and reader to count nesting levels -- and counting, after
> all, is something that computers are really really good at.

It is indeed atrocious. And nothing like what I suggested.

>
> What I'd like to see is *named* loops, with "break" and "continue"
> optionally taking an argument that names the loop to be operated on.
> I've used other languages with this feature, and I've found it quite
> useful.

Yes, this is exactly what I suggested.
And yes, this is useful, clear to read, and much better than goto's that
are not attached to any structure.

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

Does anybody know how well received have been the various proposals for
improving static bounds checking? Most proposals build on function
declarator VLA syntax. That seems like the path of least resistance. Though,
perhaps the backwards compatibility headaches silently make it the path of
*most* resistance...?

On 24/09/2021 06:11, William Ahern wrote:
> 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
>
> Does anybody know how well received have been the various proposals for
> improving static bounds checking? Most proposals build on function
> declarator VLA syntax. That seems like the path of least resistance. Though,
> perhaps the backwards compatibility headaches silently make it the path of
> *most* resistance...?
>

Have you examples of what you mean here? I don't understand what you
are talking about - perhaps because I am unfamiliar with the relevant
proposals.

If you are thinking of the "Annex K Bounds-checking interface"
functions, that was, AFAIK, a total flop. It is overly complex,
inconvenient, doesn't do what people want, and is unlikely to make
anything safer or more reliable in any way - /if/ any toolchain and
library bothered to implement it. (If anyone has contradictory
arguments, I'd love to hear them.)

Am 24.09.21 um 08:51 schrieb David Brown:
> On 24/09/2021 06:11, William Ahern wrote:
>> 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
>>
>> Does anybody know how well received have been the various proposals for
>> improving static bounds checking? Most proposals build on function
>> declarator VLA syntax. That seems like the path of least resistance. Though,
>> perhaps the backwards compatibility headaches silently make it the path of
>> *most* resistance...?
>>
>
> Have you examples of what you mean here? I don't understand what you
> are talking about - perhaps because I am unfamiliar with the relevant
> proposals.
>

N2660, N2779.

AFAIR due to lack of time it wasn't discusses at this meeting. At the
previous one, there was discussion, but no vote (see the minutes N2802).

Such things should be *optional*, we are not *kids*.

--
7-77-777
\|/
---
/|\
On 2021-09-24, William Ahern <william@25thandClement.com> wrote:
> 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
>
> Does anybody know how well received have been the various proposals for
> improving static bounds checking? Most proposals build on function
> declarator VLA syntax. That seems like the path of least resistance. Though,
> perhaps the backwards compatibility headaches silently make it the path of
> *most* resistance...?
>

--
Evil Sinner!

Am 24.09.21 um 09:52 schrieb Branimir Maksimovic:
> Such things should be *optional*, we are not *kids*.
>

It is optional: You can always use pointer parameters to pass your
arrays to your functions instead of VLA parameters.

Philipp

What's purpose of VLA then? I always used alloca for that?

--
7-77-777
\|/
/|\
On 2021-09-24, Philipp Klaus Krause <pkk@spth.de> wrote:
> Am 24.09.21 um 09:52 schrieb Branimir Maksimovic:
>> Such things should be *optional*, we are not *kids*.
>>
>
> It is optional: You can always use pointer parameters to pass your
> arrays to your functions instead of VLA parameters.
>
> Philipp

--
Evil Sinner!

Am 24.09.21 um 12:49 schrieb Branimir Maksimovic:
> What's purpose of VLA then? I always used alloca for that?
>

Both VLAs and alloca can be used to allocate memory (though alloca is
non-standard, and VLAs are optional since C11).
But VLA types can also be used for other purposes, in particular as the
type of a function parameter, which is the use relevant to this discussion.

Am 24.09.2021 um 09:52 schrieb Branimir Maksimovic:
> Such things should be *optional*, we are not *kids*.

There seem to be a lot of kids since buffer-overflow-errors are very
common in C. C++ in contrast provides []-operator and iterators which
have very convenient debug-boundschecking.

>
> --
> 7-77-777
> \|/
> ---
> /|\
> On 2021-09-24, William Ahern <william@25thandClement.com> wrote:
>> 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
>>
>> Does anybody know how well received have been the various proposals for
>> improving static bounds checking? Most proposals build on function
>> declarator VLA syntax. That seems like the path of least resistance. Though,
>> perhaps the backwards compatibility headaches silently make it the path of
>> *most* resistance...?
>>
>
>

Look, bounds checking is costly, if done in run time, and people think that
using to_string is not efficient :P

--
7-77-777
\|/
---
/|\
On 2021-09-24, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 24.09.2021 um 09:52 schrieb Branimir Maksimovic:
>> Such things should be *optional*, we are not *kids*.
>
> There seem to be a lot of kids since buffer-overflow-errors are very
> common in C. C++ in contrast provides []-operator and iterators which
> have very convenient debug-boundschecking.
>
>>
>> --
>> 7-77-777
>> \|/
>> ---
>> /|\
>> On 2021-09-24, William Ahern <william@25thandClement.com> wrote:
>>> 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
>>>
>>> Does anybody know how well received have been the various proposals for
>>> improving static bounds checking? Most proposals build on function
>>> declarator VLA syntax. That seems like the path of least resistance. Though,
>>> perhaps the backwards compatibility headaches silently make it the path of
>>> *most* resistance...?
>>>
>>
>>
>

--
Evil Sinner!

Am 25.09.21 um 03:00 schrieb Branimir Maksimovic:
> Look, bounds checking is costly, if done in run time, […]

Yes. But unlike Annex K, which is about runtime bounds checking, the
features now discussed for C23 are about improving static bounds
checking, i.e. compile-time bounds checking. Via array types, including
VLA types, as function parameters. This could allow both improved
diagnostics and optimization in the callee.

AFAIR the main problem is that the syntax already has a meaning (an
array currently just decays to a pointer). But maybe actual use is
uncommen enough that it can still be changed.

> Look, bounds checking is costly, if done in run time, and people think that
> using to_string is not efficient :P

Bounds-checking is only costly when you have random-access array access.
If you iterate linearely the loop will be split in three passes by the
optimizer: the part before the begin of the array, the part within the
array and the part afterwards; that's how Java and Rust do it. And Rust
isn't significantly slower than C or c++.

On 2021-09-25, Philipp Klaus Krause <pkk@spth.de> wrote:
> Am 25.09.21 um 03:00 schrieb Branimir Maksimovic:
>> Look, bounds checking is costly, if done in run time, […]
>
> Yes. But unlike Annex K, which is about runtime bounds checking, the
> features now discussed for C23 are about improving static bounds
> checking, i.e. compile-time bounds checking. Via array types, including
> VLA types, as function parameters. This could allow both improved
> diagnostics and optimization in the callee.
>
> AFAIR the main problem is that the syntax already has a meaning (an
> array currently just decays to a pointer). But maybe actual use is
> uncommen enough that it can still be changed.

Problem is that, in order that to work, how you can check, when using
malloc or passing array to library function?

--
7-77-777
Evil Sinner!

On 2021-09-25, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Look, bounds checking is costly, if done in run time, and people think that
>> using to_string is not efficient :P
>
> Bounds-checking is only costly when you have random-access array access.
> If you iterate linearely the loop will be split in three passes by the
> optimizer: the part before the begin of the array, the part within the
> array and the part afterwards; that's how Java and Rust do it. And Rust
> isn't significantly slower than C or c++.
>

That's costly.
Fact when iterating over array hides it (because of cache), but not all accesses
are sequential.

--
7-77-777
Evil Sinner!

On 2021-09-25, Branimir Maksimovic <branimir.maksimovic@gmail.com> wrote:
> On 2021-09-25, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Look, bounds checking is costly, if done in run time, and people think that
>>> using to_string is not efficient :P
>>
>> Bounds-checking is only costly when you have random-access array access.
>> If you iterate linearely the loop will be split in three passes by the
>> optimizer: the part before the begin of the array, the part within the
>> array and the part afterwards; that's how Java and Rust do it. And Rust
>> isn't significantly slower than C or c++.
>>
>
> That's costly.
> Fact when iterating over array hides it (because of cache), but not all accesses
> are sequential.

Never mind caching; when you're iterating over an array, you can hoist
the bounds check out of the loop (if you know that the loop has no
termination condition other than the array bounds).

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 2021-09-25, Kaz Kylheku <480-992-1380@kylheku.com> wrote:
>>> optimizer: the part before the begin of the array, the part within the
>>> array and the part afterwards; that's how Java and Rust do it. And Rust
>>> isn't significantly slower than C or c++.
>>>
>>
>> That's costly.
>> Fact when iterating over array hides it (because of cache), but not all accesses
>> are sequential.
>
> Never mind caching; when you're iterating over an array, you can hoist
> the bounds check out of the loop (if you know that the loop has no
> termination condition other than the array bounds).
>
Thanks, I'll remember that.

--

7-77-777
Evil Sinner!

Am 25.09.2021 um 13:30 schrieb Branimir Maksimovic:
> On 2021-09-25, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Look, bounds checking is costly, if done in run time, and people think that
>>> using to_string is not efficient :P
>>
>> Bounds-checking is only costly when you have random-access array access.
>> If you iterate linearely the loop will be split in three passes by the
>> optimizer: the part before the begin of the array, the part within the
>> array and the part afterwards; that's how Java and Rust do it. And Rust
>> isn't significantly slower than C or c++.
>>
>
> That's costly.

No, this linear optimization almost costs nothing. The loops before
and afterwards are only there to throw out of bounds exceptions if
array-elements are actually touched.

On 9/20/2021 7:55 PM, 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!
>
> 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.
>

It's all about modeling a problem domain.
In mathematics, /integer/ arithmetic (the one you use a.o. to add and
subtract things) is /signed/ (for any serious work, at least).
The tool that C offers to model this domain is signed integers - with
the unavoidable limitations of limited size.

Unsigned integers are the tool that C offers for /binary/ arithmetic. In
this context wrapping is one of the features that makes them useful.

Manfred <noname@add.invalid> writes:

> On 9/20/2021 7:55 PM, Bart 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!
>> 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.
>>
>
> It's all about modeling a problem domain.
> In mathematics, /integer/ arithmetic (the one you use a.o. to add and
> subtract things) is /signed/ (for any serious work, at least). The
> tool that C offers to model this domain is signed integers - with the
> unavoidable limitations of limited size.
>
> Unsigned integers are the tool that C offers for /binary/
> arithmetic. In this context wrapping is one of the features that makes
> them useful.

Some mathematics concerns the natural numbers. Unsigned integer types
would be an entirely natural (no pun intended) choice for these cases.

--
Ben.