Richard Damon <Richard@Damon-Family.org> writes:

> On 5/6/21 10:51 AM, Ben Bacarisse wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> On 5/6/21 9:14 AM, Ben Bacarisse wrote:
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>
>>>>> On 06/05/2021 09:35, Oğuz wrote:
>>>>>> I have a function that calculates two values and stores them in
>>>>>> variables x and y, which are of type ssize_t. And by design, neither
>>>>>> value can be less than -1, but they both can be SSIZE_MAX. The
>>>>>> function later subtracts y from x and returns the result. I want to
>>>>>> test if the subtraction would cause an overflow, and abort the
>>>>>> program if it will. Like:
>>>>>>
>>>>>> assert(blah blah);
>>>>>> return x - y;
>>>>>>
>>>>>> And I can't figure out what to put in place of "blah blah" there. So
>>>>>> I'm asking for help.
>>>>>>
>>>>>
>>>>> You are probably over-thinking the problem. Sometimes the obvious
>>>>> solution is perfectly good.
>>>>>
>>>>> if (x >= y) return x - y;
>>>>> abort();
>>>>
>>>> I think you might be under-thinking it! If x == SSIZE_MAX and y == -1
>>>> then this overflows. If I've understood the OP correctly, this is the
>>>> only case that can overflow, so it's the only test needed.
>>>
>>> It can overflow in the positive direection only that way, It is possible
>>> that -1 - SSIZE_MAX might be considered an underflow, it is likely that
>>> it will be the strange value with just the sign bit set that negating
>>> overflows and remains itself.
>>
>> I'd expect -1 - SSIZE_MAX to be representable, but from a formal point
>> of view it depends on who defines the type. POSIX only requires that it
>> be able to represent [-1, SIZE_MAX] but there are no types in C that
>> could be that restrictive.
>
> As I said, -1 - SSIZE_MAX will likely be the value that has just the
> sign bit set. This is a bit of a funny value, even if it is allowed.

Yes, it is not necessarily a representable value (i.e. it is permitted
to be trap representation, even on a 2's-complement system).

> C DOES allow for signed types to be limited in the range of MAX ... -MAX
> and not include the -MAX-1 value.

Yup, even on 2's-complement systems. But that last case is, in my
experience, very rare. I've not worked with sign+magnitude and
1's-complement machines for decades, but I've never see the latter.

> This comes naturally as a limit on
> ancient machines that used 1's complement or signed magnitude, which as
> far as I know are still allowed. (They can't be used for the optional
> types like int16_t)

--
Ben.

On Thursday, May 6, 2021 at 11:40:26 PM UTC+3, Ben Bacarisse wrote:
> Oğuz <oguzism...@gmail.com> writes:
>
> > On Thursday, May 6, 2021 at 6:05:21 PM UTC+3, Ben Bacarisse wrote:
> >> Oğuz <oguzism...@gmail.com> writes:
> >>
> >> > On Thursday, May 6, 2021 at 4:14:44 PM UTC+3, Ben Bacarisse wrote:
> >> >> David Brown <david...@hesbynett.no> writes:
> >> >>
> >> >> > On 06/05/2021 09:35, Oğuz wrote:
> >> >> >> I have a function that calculates two values and stores them in
> >> >> >> variables x and y, which are of type ssize_t. And by design, neither
> >> >> >> value can be less than -1, but they both can be SSIZE_MAX. The
> >> >> >> function later subtracts y from x and returns the result. I want to
> >> >> >> test if the subtraction would cause an overflow, and abort the
> >> >> >> program if it will. Like:
> >> >> >>
> >> >> >> assert(blah blah);
> >> >> >> return x - y;
> >> >> >>
> >> >> >> And I can't figure out what to put in place of "blah blah" there.. So
> >> >> >> I'm asking for help.
> >> >> >>
> >> >> >
> >> >> > You are probably over-thinking the problem. Sometimes the obvious
> >> >> > solution is perfectly good.
> >> >> >
> >> >> > if (x >= y) return x - y;
> >> >> > abort();
> >> >> I think you might be under-thinking it! If x == SSIZE_MAX and y == -1
> >> >> then this overflows. If I've understood the OP correctly, this is the
> >> >> only case that can overflow, so it's the only test needed.
> >> >
> >> > I thought overflow meant both overflow and underflow, sorry.
> >> No, you are right. It usually does include both, and I took it to mean
> >> that.
> >> > As
> >> > Richard pointed out -1 - SSIZE_MAX was also a case I wanted to avoid
> >> > initially,
> >> But that's not likely to overflow (or undeflow f you prefer) since -1 -
> >> SSIZE_MAX will be representable on all the hardware you are likely to
> >> come across.
> >>
> >> You may want to rule it out for other reasons, but it won't technically
> >> be an overflow.
> >> > but then I realized that the guaranteed minimum value for
> >> > ssize_t is -1 and there is no such thing as SSIZE_MIN.
> >> Yes, but then you run into the fact that no C type can be that
> >> restrictive, so question becomes what you mean by overflow. -1 - 1 does
> >> not overflow in the C sense of the word for any integer type, but the
> >> result is out of range for what POSIX says about ssize_t.
> >
> > And that is what bothers me.
> OK.
> >> If you mean that you want to detect when the result is outside the range
> >> [-1, SSIZE_MAX] then the test becomes more complicated.
> >> > So I changed
> >> > the code to use int instead, and used `assert(x < INT_MAX || y >= 0)',
> >> > assuming -INT_MAX > INT_MIN (not sure if this is true everywhere
> >> > though).
> >> Hmm... but now you've introduced a whole new set of issues. Are you
> >> happy to use a type that may well be half the size of the original?
> >
> > Yes. The x and y rarely grow that big.
> >
> >> As for signed integers using 2s-complement (so that -INT_MAX ==
> >> INT_MIN+1) I /think/ POSIX mandates this, but my memory is fuzzy on this
> >> point. The C standard, on the other hand, does not. Mind you, are you
> >> worried about coming across a system with sign-magnitude or
> >> 1s-complement signed integers?
> >
> > Are such systems common?
> No, quite rare these days, though it depends what kind of code you
> write. I'm sure the folks at the computer museum worry about them every
> day!
> > Can't I just do
> > #if -INT_MAX <= INT_MIN
> > #error
> > #endif
> > and rule them out?
> Technically, no. C permits a 2's-complement machine to treat the bit
> pattern with sign bit set and all value bits zero as a trap
> representation. INT_MIN would be -INT_MAX on such a system.
>
> I say "technically" because I think such implementations are even rarer,
> but also because you don't care. Any C implementation that fails that
> test will overflow on -1 - INT_MAX. Of course, it may be a harmless
> overflow but we've got into the technical weeds here.
>
> Because of the switch to int, I'm not 100% sure what you need now. You
> want to exit if x - y is outside of the range [-1, INT_MAX], despite
> ssize_t possibly being a wider type than int?

Well I don't need anything now that I know I don't have to worry about -INT_MAX being equal to or less than INT_MIN. Thank you all

>
> --
> Ben.

On 5/6/2021 12:35 AM, Oğuz wrote:
> I have a function that calculates two values and stores them in variables x and y, which are of type ssize_t. And by design, neither value can be less than -1, but they both can be SSIZE_MAX. The function later subtracts y from x and returns the result. I want to test if the subtraction would cause an overflow, and abort the program if it will. Like:
>
> assert(blah blah);
> return x - y;
>
> And I can't figure out what to put in place of "blah blah" there. So I'm asking for help.
>

Just don't to that. Do not allow it with some rules. Check this out:

https://vorbrodt.blog/2019/02/14/read-write-mutex/

> Checking for overflows with signed types can't be done with the
> standard-ways because signed-overflows arent defined in the stan-
> dard and you've to rely on implementation-defined behaviour. But
> you can also trick something with convertion to unsigned and back
> and checking the sign-changes.

You could check for overflows with signed values like this:

inline
bint32_t operator +( bint32_t left, bint32_t right )
{ bool signChange = ((left + right) ^ left) >> 31;
bool carry = (uint32_t)left + (uint32_t)right < (uint32_t)left;
bool overflow = signChange & !carry;
if( overflow )
throw range_error( "bint32_t add-overflow" );
return left.m_value + right.m_value;
}

On 07/05/2021 09:44, Bonita Montero wrote:
>> Checking for overflows with signed types can't be done with the
>> standard-ways because signed-overflows arent defined in the stan-
>> dard and you've to rely on implementation-defined behaviour. But
>> you can also trick something with convertion to unsigned and back
>> and checking the sign-changes.
>
> You could check for overflows with signed values like this:
>
> inline
> bint32_t operator +( bint32_t left, bint32_t right )
> {
>     bool     signChange = ((left + right) ^ left) >> 31;

This is presumably missing the casts to uint32_t. As it stands, you
have a recursive loop.

>     bool     carry      = (uint32_t)left + (uint32_t)right <
> (uint32_t)left;
>     bool     overflow   = signChange & !carry;
>     if( overflow )
>         throw range_error( "bint32_t add-overflow" );
>     return left.m_value + right.m_value;
> }

The class you gave earlier was buint32_t, with the underlying type being
unsigned (uint32_t). Now you have switched to bint32_t, but it is not
clear if your underlying arithmetic is done using signed or unsigned types.

On 5/6/2021 10:26 PM, Chris M. Thomasson wrote:
> On 5/6/2021 12:35 AM, Oğuz wrote:
>> I have a function that calculates two values and stores them in
>> variables x and y, which are of type ssize_t. And by design, neither
>> value can be less than -1, but they both can be SSIZE_MAX. The
>> function later subtracts y from x and returns the result. I want to
>> test if the subtraction would cause an overflow, and abort the program
>> if it will. Like:
>>
>> assert(blah blah);
>> return x - y;
>>
>> And I can't figure out what to put in place of "blah blah" there. So
>> I'm asking for help.
>>
>
> Just don't to that. Do not allow it with some rules. Check this out:
>
> https://vorbrodt.blog/2019/02/14/read-write-mutex/
>

Let shit bite the dust? Well, get ready for a shit storm:

https://youtu.be/W2QIlGorKUg?list=PLsPMOz2-mpmPVQVxqhIU31jzmlD5-osq4

>> bool signChange = ((left + right) ^ left) >> 31;
> This is presumably missing the casts to uint32_t. As it stands, you
> have a recursive loop.

No, the values should remain signeds to result -1 or 0,
converted to truw or fase.

>> bool carry = (uint32_t)left + (uint32_t)right <
>> (uint32_t)left;
>> bool overflow = signChange & !carry;
>> if( overflow )
>> throw range_error( "bint32_t add-overflow" );
>> return left.m_value + right.m_value;
>> }
>
> The class you gave earlier was buint32_t, with the underlying type being
> unsigned (uint32_t). Now you have switched to bint32_t, but it is not
> clear if your underlying arithmetic is done using signed or unsigned
types.

I just wanted to give an exampe how a oveflow-test would look like
for a signed version of my class.

On 07/05/2021 10:11, Bonita Montero wrote:
>>>      bool     signChange = ((left + right) ^ left) >> 31;
>> This is presumably missing the casts to uint32_t.  As it stands, you
>> have a recursive loop.
>
> No, the values should remain signeds to result -1 or 0,
> converted to truw or fase.
>
>>>      bool     carry      = (uint32_t)left + (uint32_t)right <
>>> (uint32_t)left;
>>>      bool     overflow   = signChange & !carry;
>>>      if( overflow )
>>>          throw range_error( "bint32_t add-overflow" );
>>>      return left.m_value + right.m_value;
>>> }
>>
>> The class you gave earlier was buint32_t, with the underlying type being
>> unsigned (uint32_t).  Now you have switched to bint32_t, but it is not
>> clear if your underlying arithmetic is done using signed or unsigned
> types.
>
> I just wanted to give an exampe how a oveflow-test would look like
> for a signed version of my class.
>

One of your overflow tests also performed the arithmetic using 64-bit
types. Which is a bit of a cheat.

It could also have been used in the original requirement, although the
likelihood is that ssize_t was already 64 bits anyway, which means that
your code would have needed uint128_t arithmetic.

> One of your overflow tests also performed the arithmetic using 64-bit
> types. Which is a bit of a cheat.

No, it's not cheating, it's the only way to test for x * y overflow.
The compiler internally doesn't really do a 64 * 64 multiplication
as it does see the higher halfes of the 32 bit words are zero.

> It could also have been used in the original requirement, although the
> likelihood is that ssize_t was already 64 bits anyway, which means that
> your code would have needed uint128_t arithmetic.

There are usually intrinsics which give you the upper
half of a 64 * 64 multiplication.

On 07/05/2021 11:11, Bonita Montero wrote:
>>>      bool     signChange = ((left + right) ^ left) >> 31;
>> This is presumably missing the casts to uint32_t.  As it stands, you
>> have a recursive loop.
>
> No, the values should remain signeds to result -1 or 0,
> converted to truw or fase.

If you didn't keep snipping context, maybe you would understand what you
wrote and see your mistakes:

inline
bint32_t operator +( bint32_t left, bint32_t right )
{ bool signChange = ((left + right) ^ left) >> 31;
bool carry = (uint32_t)left + (uint32_t)right < (uint32_t)left;
bool overflow = signChange & !carry;
if( overflow )
throw range_error( "bint32_t add-overflow" );
return left.m_value + right.m_value;
}

"left" and "right" are type bint32_t. When you write "(left + write)",
it will call the operator "+" for those types - the very function you
are trying to define. It is infinite recursion and getting nowhere.

If you meant to use the "int32_t" member, or cast these to "int32_t",
then you have another mistake - adding signed integers has undefined
behaviour on overflow (assuming int is 32-bit or smaller here). You
cannot rely on two's complement wrapping behaviour, unless you have a
compiler that guarantees that. (And if you are using MSVC, as I believe
you usually do, it very much does /not/ guarantee two's complement
wrapping on signed integer overflow.)

Cast your "left" and "right" to uint32_t, and the code will be correct.
It would be better to use logical && rather than bitwise & for
calculating "overflow", but it will work anyway.

>
>>>      bool     carry      = (uint32_t)left + (uint32_t)right <
>>> (uint32_t)left;
>>>      bool     overflow   = signChange & !carry;
>>>      if( overflow )
>>>          throw range_error( "bint32_t add-overflow" );
>>>      return left.m_value + right.m_value;
>>> }
>>
>> The class you gave earlier was buint32_t, with the underlying type being
>> unsigned (uint32_t).  Now you have switched to bint32_t, but it is not
>> clear if your underlying arithmetic is done using signed or unsigned
> types.
>
> I just wanted to give an exampe how a oveflow-test would look like
> for a signed version of my class.
>

It was a fine example of how you can write things incorrectly, or in
ways that might seem okay in initial testing but fail later, if that was
your aim.

> "left" and "right" are type bint32_t. When you write "(left + write)",
> it will call the operator "+" for those types - the very function you
> are trying to define. It is infinite recursion and getting nowhere.

Yes, I should have used the members. I never compiled the code,
it was just to say how checking for overflows might work.

> If you meant to use the "int32_t" member, or cast these to "int32_t",
> then you have another mistake - adding signed integers has undefined
> behaviour on overflow (assuming int is 32-bit or smaller here).

That doesn't matter as all platforms behave identically here and
platorms which don't use 2-complement arent existing for decades.

> You cannot rely on two's complement wrapping behaviour, unless you have a
> compiler that guarantees that. ...

All compilers actually do that.

On 5/7/2021 8:20 AM, Bonita Montero wrote:
>> "left" and "right" are type bint32_t.  When you write "(left + write)",
>> it will call the operator "+" for those types - the very function you
>> are trying to define.  It is infinite recursion and getting nowhere.
>
> Yes, I should have used the members. I never compiled the code,
> it was just to say how checking for overflows might work.
>
>> If you meant to use the "int32_t" member, or cast these to "int32_t",
>> then you have another mistake - adding signed integers has undefined
>> behaviour on overflow (assuming int is 32-bit or smaller here).
>
> That doesn't matter as all platforms behave identically here and
> platorms which don't use 2-complement arent existing for decades.
>
>> You cannot rely on two's complement wrapping behaviour, unless you have a
>> compiler that guarantees that. ...
>
> All compilers actually do that.
>

https://godbolt.org

On 2021-05-07, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> "left" and "right" are type bint32_t. When you write "(left + write)",
>> it will call the operator "+" for those types - the very function you
>> are trying to define. It is infinite recursion and getting nowhere.
>
> Yes, I should have used the members. I never compiled the code,
> it was just to say how checking for overflows might work.
>
>> If you meant to use the "int32_t" member, or cast these to "int32_t",
>> then you have another mistake - adding signed integers has undefined
>> behaviour on overflow (assuming int is 32-bit or smaller here).
>
> That doesn't matter as all platforms behave identically here and
> platorms which don't use 2-complement arent existing for decades.
>
>> You cannot rely on two's complement wrapping behaviour, unless you have a
>> compiler that guarantees that. ...
>
> All compilers actually do that.

This is flat-out wrong.

It is simply not a fact.

Modern compilers are making no-undefined-behavior assumptions around
integer overflow and other situations, which will cause the code not to
behave in the expected way.

For instance:

for (int i = 0; i >= 0; i++)
{ }

/* A */

Here point A can be treated as unreachable. The only way execution can
go past the loop guard is if i goes to zero or negative. Since i is
only incremented, the only way that can happen is undefined behavior.

If the only way some statement can be reached is via undefined behavior,
we can throw the programmer under the bus and silently optimize it away
as unreachable code.

This is not theoretical; it is real and happening.

OK, here is a test program:

#include <stdio.h>

int main()
{
for (int i = 0; i >= 0; i++)
{ }
puts("reached");
return 0;
}

I have Ubuntu 18.04 here with gcc 7.5.0 (not shiniest or latest).

When you build the program with gcc -O2, no matter how long you wait,
it will not print "reached".

Here is why:

Disassembly of section .text:

000003b0 <main>:
3b0: eb fe jmp 3b0 <main>

GCC turned it into an infinite loop!

Why? If there is no undefined behavior, i can never go negative. If I
can never go negative, the loop guard is always true. Thus, the loop is
infinite.

And since wood floats on water, it must weight as much as a duck ...

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

On 07/05/2021 23:25, Kaz Kylheku wrote:
> On 2021-05-07, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> "left" and "right" are type bint32_t. When you write "(left + write)",
>>> it will call the operator "+" for those types - the very function you
>>> are trying to define. It is infinite recursion and getting nowhere.
>>
>> Yes, I should have used the members. I never compiled the code,
>> it was just to say how checking for overflows might work.
>>
>>> If you meant to use the "int32_t" member, or cast these to "int32_t",
>>> then you have another mistake - adding signed integers has undefined
>>> behaviour on overflow (assuming int is 32-bit or smaller here).
>>
>> That doesn't matter as all platforms behave identically here and
>> platorms which don't use 2-complement arent existing for decades.
>>
>>> You cannot rely on two's complement wrapping behaviour, unless you have a
>>> compiler that guarantees that. ...
>>
>> All compilers actually do that.
>
> This is flat-out wrong.
>
> It is simply not a fact.
>
> Modern compilers are making no-undefined-behavior assumptions around
> integer overflow and other situations, which will cause the code not to
> behave in the expected way.
>
> For instance:
>
> for (int i = 0; i >= 0; i++)
> { }
>
> /* A */
>
> Here point A can be treated as unreachable. The only way execution can
> go past the loop guard is if i goes to zero or negative. Since i is
> only incremented, the only way that can happen is undefined behavior.
>
> If the only way some statement can be reached is via undefined behavior,
> we can throw the programmer under the bus and silently optimize it away
> as unreachable code.
>
> This is not theoretical; it is real and happening.
>
> OK, here is a test program:
>
> #include <stdio.h>
>
> int main()
> {
> for (int i = 0; i >= 0; i++)
> { }
> puts("reached");
> return 0;
> }
>
> I have Ubuntu 18.04 here with gcc 7.5.0 (not shiniest or latest).
>
> When you build the program with gcc -O2, no matter how long you wait,
> it will not print "reached".
>
> Here is why:
>
> Disassembly of section .text:
>
> 000003b0 <main>:
> 3b0: eb fe jmp 3b0 <main>
>
> GCC turned it into an infinite loop!
>
> Why? If there is no undefined behavior, i can never go negative. If I
> can never go negative, the loop guard is always true. Thus, the loop is
> infinite.
>
> And since wood floats on water, it must weight as much as a duck ...
>

Bad compiler. With this program:

#include <stdio.h>

int main(void) {
int i;
for (i = 0; i >= 0; i++)
{ if (i<10) printf("%d ",i);}
printf("A %d\n",i);
}

Most compilers without optimisition will output:

0 1 2 3 4 5 6 7 8 9 A -2147483648

This is on a machine with well-defined integer overflow. But start to
apply optimations, and some will show:

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 ....

Others will repeat that INT_MIN value. But MSVC gets it right even
optimised.

If I change i to 'short', then all compilers, even with optimising, will
produce:

0 1 2 3 4 5 6 7 8 9 A -32768

Why should something work with i16 and not i32? It's inconsistent.
Apparently integer overflow on i16 is fine!

> Why? If there is no undefined behavior, i can never go negative.

When i is 0x7FFFFFFF, ++i wraps it around to 0x80000000, which is
negative. No undefined behaviour except in the minds of C compilers.
What exactly did they think the programmer wrote that loop for?

On 5/7/2021 3:25 PM, Kaz Kylheku wrote:
> On 2021-05-07, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> "left" and "right" are type bint32_t. When you write "(left + write)",
>>> it will call the operator "+" for those types - the very function you
>>> are trying to define. It is infinite recursion and getting nowhere.
>>
>> Yes, I should have used the members. I never compiled the code,
>> it was just to say how checking for overflows might work.
>>
>>> If you meant to use the "int32_t" member, or cast these to "int32_t",
>>> then you have another mistake - adding signed integers has undefined
>>> behaviour on overflow (assuming int is 32-bit or smaller here).
>>
>> That doesn't matter as all platforms behave identically here and
>> platorms which don't use 2-complement arent existing for decades.
>>
>>> You cannot rely on two's complement wrapping behaviour, unless you have a
>>> compiler that guarantees that. ...
>>
>> All compilers actually do that.
>
> This is flat-out wrong.
>
> It is simply not a fact.
>
> Modern compilers are making no-undefined-behavior assumptions around
> integer overflow and other situations, which will cause the code not to
> behave in the expected way.
>
> For instance:
>
> for (int i = 0; i >= 0; i++)
> { }
>
> /* A */
>
> Here point A can be treated as unreachable. The only way execution can
> go past the loop guard is if i goes to zero or negative. Since i is
> only incremented, the only way that can happen is undefined behavior.
>
> If the only way some statement can be reached is via undefined behavior,
> we can throw the programmer under the bus and silently optimize it away
> as unreachable code.
>
> This is not theoretical; it is real and happening.
>
> OK, here is a test program:
>
> #include <stdio.h>
>
> int main()
> {
> for (int i = 0; i >= 0; i++)
> { }
> puts("reached");
> return 0;
> }
>
> I have Ubuntu 18.04 here with gcc 7.5.0 (not shiniest or latest).
>
> When you build the program with gcc -O2, no matter how long you wait,
> it will not print "reached".
>
> Here is why:
>
> Disassembly of section .text:
>
> 000003b0 <main>:
> 3b0: eb fe jmp 3b0 <main>
>
> GCC turned it into an infinite loop!

Does it halt? lol. sorry.

>
> Why? If there is no undefined behavior, i can never go negative. If I
> can never go negative, the loop guard is always true. Thus, the loop is
> infinite.
>
> And since wood floats on water, it must weight as much as a duck ...
>

On 2021-05-07, Bart <bc@freeuk.com> wrote:
> On 07/05/2021 23:25, Kaz Kylheku wrote:
>> On 2021-05-07, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>> "left" and "right" are type bint32_t. When you write "(left + write)",
>>>> it will call the operator "+" for those types - the very function you
>>>> are trying to define. It is infinite recursion and getting nowhere.
>>>
>>> Yes, I should have used the members. I never compiled the code,
>>> it was just to say how checking for overflows might work.
>>>
>>>> If you meant to use the "int32_t" member, or cast these to "int32_t",
>>>> then you have another mistake - adding signed integers has undefined
>>>> behaviour on overflow (assuming int is 32-bit or smaller here).
>>>
>>> That doesn't matter as all platforms behave identically here and
>>> platorms which don't use 2-complement arent existing for decades.
>>>
>>>> You cannot rely on two's complement wrapping behaviour, unless you have a
>>>> compiler that guarantees that. ...
>>>
>>> All compilers actually do that.
>>
>> This is flat-out wrong.
>>
>> It is simply not a fact.
>>
>> Modern compilers are making no-undefined-behavior assumptions around
>> integer overflow and other situations, which will cause the code not to
>> behave in the expected way.
>>
>> For instance:
>>
>> for (int i = 0; i >= 0; i++)
>> { }
>>
>> /* A */
>>
>> Here point A can be treated as unreachable. The only way execution can
>> go past the loop guard is if i goes to zero or negative. Since i is
>> only incremented, the only way that can happen is undefined behavior.
>>
>> If the only way some statement can be reached is via undefined behavior,
>> we can throw the programmer under the bus and silently optimize it away
>> as unreachable code.
>>
>> This is not theoretical; it is real and happening.
>>
>> OK, here is a test program:
>>
>> #include <stdio.h>
>>
>> int main()
>> {
>> for (int i = 0; i >= 0; i++)
>> { }
>> puts("reached");
>> return 0;
>> }
>>
>> I have Ubuntu 18.04 here with gcc 7.5.0 (not shiniest or latest).
>>
>> When you build the program with gcc -O2, no matter how long you wait,
>> it will not print "reached".
>>
>> Here is why:
>>
>> Disassembly of section .text:
>>
>> 000003b0 <main>:
>> 3b0: eb fe jmp 3b0 <main>
>>
>> GCC turned it into an infinite loop!
>>
>> Why? If there is no undefined behavior, i can never go negative. If I
>> can never go negative, the loop guard is always true. Thus, the loop is
>> infinite.
>>
>> And since wood floats on water, it must weight as much as a duck ...
>>
>
> Bad compiler. With this program:
>
> #include <stdio.h>
>
> int main(void) {
> int i;
> for (i = 0; i >= 0; i++)
> { if (i<10) printf("%d ",i);}
> printf("A %d\n",i);
> }
>
> Most compilers without optimisition will output:
>
> 0 1 2 3 4 5 6 7 8 9 A -2147483648
>
> This is on a machine with well-defined integer overflow. But start to
> apply optimations, and some will show:
>
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 ....
>
> Others will repeat that INT_MIN value. But MSVC gets it right even
> optimised.
>
> If I change i to 'short', then all compilers, even with optimising, will
> produce:
>
> 0 1 2 3 4 5 6 7 8 9 A -32768
>
> Why should something work with i16 and not i32? It's inconsistent.
> Apparently integer overflow on i16 is fine!

This is because if a signed integer expression has a type narrower than int,
then its value is promoted to int.

The expression i++ is treated as i = i + 1 (yielding the old value,
which is discarded and therefore moot).

So what happens when i has reached 32767 is that the i on the r.h.s.
is promoted to int. Then the vaue 32768 (0x8000) of type int is
calculated, without any overflow whatsoever, since int is 32 bits on
that platform.

Then the assignment back to i is out of range. But, importantly, this
has implementation-defined behavior, not undefined!

There is a broad consensus among compilers about how that is handled:
the int vaue is truncated to the lowest 16 bits, and those bits are
shoved into the 16 bit variable. The bit pattern 0x8000 in 16 bit
two's complement is of course -32768.

> > Why? If there is no undefined behavior, i can never go negative.
>
> When i is 0x7FFFFFFF, ++i wraps it around to 0x80000000, which is
> negative. No undefined behaviour except in the minds of C compilers.

Well, the behavior is not defined by ISO C today and never has been
That is incontrovertible.

> What exactly did they think the programmer wrote that loop for?

Indeed it not being defined by the standard doesn't exuse the compiler
writer from writing optimizations that silently throw away a loop guard.

If, under some assumption like "this program is always well-defined",
or any other assumption, a loop guard looks always true, that's almost
certainly a problem: a loop guard is almost certainly intended, which
means that the programmer isn't working under that assumption.

Or is working under an assumption which /looks/ like that assumption
("I am writing a well-defined program"), but that programmer doesn't
have the same idea of what is defined or not!!!

When people think they are writing an infinite loop, they usually write
an always-true loop guard as while (1) or for (;;). People don't write
for (;i >= 0;) when they mean for (;;). Any loop guard that is
plausibly falsifiable on its own likely serves a purposeful intent.
Its substitution with 1 deserves a diagnostic, at least.

Compiler writers need to pay at least /some/ attention to what large
numbers of programmers /think/ is defined. Also, historically, what they
/thought/ was defined. Because that's what is recorded in reams and
reams of existing code, regardless of how the present understanding has
shifted and how well versed programmers are today.

If some retired coder's function did the same thing for the past 27
years, and suddenly breaks, you cannot reasonably go back and blame
that retired coder any more.

The last person to make a change, whether in the compiler or the
application, is the breaker.

If you want to commit a change to a compiler which promotes some
fancy optimization the onus is on you to compile all the applications
and run all their test suites. In parallel with the compiler change,
submit all the compensating changes to all the applications and
libraries so that they keep working with the compiler change.

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

> It is simply not a fact.

Tell me the compiler where this doesn't work.

> For instance:
>
> for (int i = 0; i >= 0; i++)
> { }
>
> /* A */

Where do I do sth. like this, idiot ?

On 08/05/2021 01:02, Kaz Kylheku wrote:
> On 2021-05-07, Bart <bc@freeuk.com> wrote:

>> Why should something work with i16 and not i32? It's inconsistent.
>> Apparently integer overflow on i16 is fine!
>
> This is because if a signed integer expression has a type narrower than int,
> then its value is promoted to int.

I understand the technical reasons. But I'm trying to see it from the
point of view of the programmer.

Adding 1 to the largest value of i16 or u32 is fine, it will wrap to the
smallest value.

But it isn't fine for i32, or even i16 when your program runs on a
machine where 'int' is i16 rather than i32.

And the exact same operation is perfectly OK when run on the /same
hardware/ using an alternative systems language, or even just assembly.

So what's the deal with C?

It gets more bizarre when you find it it runs just fine on most
unoptimised C compilers too.

> Well, the behavior is not defined by ISO C today and never has been
> That is incontrovertible.

Well, I disagree with that. I disagree more with some C compilers taking
advantage of it by making /your/ program behave in a way you didn't intend.

On Saturday, 8 May 2021 at 09:00:08 UTC+3, Bonita Montero wrote:
> > It is simply not a fact.
> Tell me the compiler where this doesn't work.

It is hard to find optimizing compilers that do nowhere take advantage
of assuming that overflow is undefined behavior. The compilers
are compared with benchmarks and some benchmark code benefits
from such optimizations. But you probably know it, asshole.

> > For instance:
> >
> > for (int i = 0; i >= 0; i++)
> > { }
> >
> > /* A */
> Where do I do sth. like this, idiot ?

In this very thread you posted code of infinite loop, major idiot.

> It is hard to find optimizing compilers that do nowhere take
> advantage of assuming that overflow is undefined behavior. ...

I'm not dealing with the overflows Kaz showed.

> In this very thread you posted code of infinite loop, major idiot.

I dind't show code that is related to what Kaz mentioned.
And actually there's no reason why that what I showed shouldn't
work with any current compiler and any compiler in the future.

On 07/05/2021 17:20, Bonita Montero wrote:
>> "left" and "right" are type bint32_t.  When you write "(left + write)",
>> it will call the operator "+" for those types - the very function you
>> are trying to define.  It is infinite recursion and getting nowhere.
>
> Yes, I should have used the members. I never compiled the code,
> it was just to say how checking for overflows might work.
>
>> If you meant to use the "int32_t" member, or cast these to "int32_t",
>> then you have another mistake - adding signed integers has undefined
>> behaviour on overflow (assuming int is 32-bit or smaller here).
>
> That doesn't matter as all platforms behave identically here and
> platorms which don't use 2-complement arent existing for decades.

I agree that two's complement representation is almost universal.

>
>> You cannot rely on two's complement wrapping behaviour, unless you have a
>> compiler that guarantees that. ...
>
> All compilers actually do that.
>

Drivel. Dangerous drivel.

Most optimising compilers will, at times, take advantage of knowing that
signed integer overflow is undefined behaviour and give smaller and
faster code on the assumption that it does not happen. I have seen a
few compilers document that they wrap signed integer arithmetic, but
those were niche tools. gcc documents that it does so if you specify
the "-fwrapv" flag. MSVC has (AFAIK) an /undocumented/ compiler flag
"-d2UndefIntOverflow-" to give you guaranteed wrapping.

For MSVC++, see:

<https://devblogs.microsoft.com/cppblog/new-code-optimizer/>

Look in particular for the section "Taking advantage of signed integer
overflow being undefined".

> Most optimising compilers will, at times, take advantage of knowing that
> signed integer overflow is undefined behaviour and give smaller and
> faster code on the assumption that it does not happen.

Please tell me where I'm relying on signed oveflow !
You haven't really read my code.

On 2021-05-08, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Most optimising compilers will, at times, take advantage of knowing that
>> signed integer overflow is undefined behaviour and give smaller and
>> faster code on the assumption that it does not happen.
>
> Please tell me where I'm relying on signed oveflow !
> You haven't really read my code.

if bin32_t is signed then you do...
>

--
current job title: senior software engineer
skills: x86 aasembler,c++,c,rust,go,nim,haskell...

press any key to continue or any other to quit...

> if bin32_t is signed then you do...

Show me the code-line where I'm relying on signed oveflows ...

On 08/05/2021 13:12, Bart wrote:
> On 08/05/2021 01:02, Kaz Kylheku wrote:
>> On 2021-05-07, Bart <bc@freeuk.com> wrote:
>
>>> Why should something work with i16 and not i32? It's inconsistent.
>>> Apparently integer overflow on i16 is fine!
>>
>> This is because if a signed integer expression has a type narrower
>> than int,
>> then its value is promoted to int.
>
> I understand the technical reasons. But I'm trying to see it from the
> point of view of the programmer.

As a programmer, I want to write my code in a clearly defined language
that acts as a contract between the programmer and the compiler. Then I
want the compiler to generate the smallest and fastest object code it
can (as well as give helpful messages when it sees something wrong). I
expect the compiler to generate correct results from correct source code
- equally, the compiler expects me to have written correct source code.

Would you agree on that as a programmer viewpoint?

We can disagree on the best choices for a language in regard to types,
operations, overflow behaviour, etc. That's a different matter.

C has its rules for integer promotion. It defines the wrapping
behaviour for unsigned operations (on "unsigned int" and bigger - it
does not define any arithmetic operations on smaller unsigned types).
It makes overflow undefined for signed operations (again, there are no
arithmetic operations at all on sizes smaller than int).

As a C programmer, I am expected to know these rules. (They are not
hard.) A C compiler reads the C source code, and assumes the programmer
knows how to write C code - it does not attempt to read the programmer's
mind and guess what he/she had intended to write.

So from this programmer's prospective, at least, I expect the compiler
to assume that my signed arithmetic can't overflow if that lets it
generate better code or do better static analysis.

And I think you'll have a hard time finding any non-programmer who
thinks it makes sense to take a large positive number, add another
positive number, and end up with a negative number. If you tell them,
for example, that they are allowed to use six digits and positive and
negative numbers, then ask what the result of adding 1 to 999999 should
be, they'll say you can't do it. They will /not/ say -999999.

>
> Adding 1 to the largest value of i16 or u32 is fine, it will wrap to the
> smallest value.
>
> But it isn't fine for i32, or even i16 when your program runs on a
> machine where 'int' is i16 rather than i32.
>
> And the exact same operation is perfectly OK when run on the /same
> hardware/ using an alternative systems language, or even just assembly.
>

Some languages defined signed integer overflow, others do not.

Personally, I think it would be more sensible if arithmetic in C was
always defined to use the size of the types (no integer promotion), and
overflow was always undefined (for unsigned types as well as signed
types). Special syntax or functions could be used for the very rare
occasions in which you want wrapping to occur. But that's just my
opinion - when I program in a particular language, I use the rules for
that language.

> So what's the deal with C?
>
> It gets more bizarre when you find it it runs just fine on most
> unoptimised C compilers too.
>

When code does what you want without optimisation, and does something
different with optimisation, the code is not correct. (Or there is a
compiler bug, but that's going to be a lot less common.)

>> Well, the behavior is not defined by ISO C today and never has been
>> That is incontrovertible.
>
> Well, I disagree with that.

I hope you meant to say you /disapprove/ of that - you think the C
language should have been defined differently. It is an
incontrovertible fact that the C language does not and never has (at
least since standardisation) define integer overflow behaviour.

You are welcome to have your opinions on that design choice - but not on
the facts of the matter.

> I disagree more with some C compilers taking
> advantage of it by making /your/ program behave in a way you didn't intend.
>

Again, I assume you are expressing an opinion of how you think compilers
should behave - not disagreeing with the facts of how they /actually/
behave.

It is not uncommon for compilers to have flags or extensions (like gcc's
"-fwrapv") to let you change the language the way you want.