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.

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();

or, if you want to use assert (I avoid it because it's effect typically
depends on compiler or build flags) :

assert(x >= y);
return x - y;

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.

--
Ben.

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.

Use C++, define your own integer-wrappers that generate an exeption
on overflow.

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. As Richard pointed out -1 - SSIZE_MAX was also a case I wanted to avoid initially, but then I realized that the guaranteed minimum value for ssize_t is -1 and there is no such thing as SSIZE_MIN. 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).

>
> --
> Ben.

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.

--
Ben.

Oğuz <oguzismailuysal@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.

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?

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?

--
Ben.

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.

>
> 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? Can't I just do
#if -INT_MAX <= INT_MIN
#error
#endif
and rule them out?

>
> --
> Ben.

=?UTF-8?B?T8SfdXo=?= <oguzismailuysal@gmail.com> writes:
>On Thursday, May 6, 2021 at 4:14:44 PM UTC+3, Ben Bacarisse wrote:
>> David Brown <david...@hesbynett.no> writes:=20

>> I think you might be under-thinking it! If x =3D=3D SSIZE_MAX and y =3D=
>=3D -1=20
>> then this overflows. If I've understood the OP correctly, this is the=20
>> only case that can overflow, so it's the only test needed.=20
>
>I thought overflow meant both overflow and underflow, sorry. As Richard poi=
>nted out -1 - SSIZE_MAX was also a case I wanted to avoid initially, but th=
>en I realized that the guaranteed minimum value for ssize_t is -1 and there=
> is no such thing as SSIZE_MIN. So I changed the code to use int instead, a=
>nd used `assert(x < INT_MAX || y >=3D 0)', assuming -INT_MAX > INT_MIN (not=
> sure if this is true everywhere though).

From Posix P1003.4 Draft 14.1 (May 1993):

ssize_t Used by functions that return a count of bytes (memory space)
or an error indication.

From the rationale (B.2.5):

ssize_t This is intended to be a signed analog of size_t. The
wording is such that an implementation may either choose
to use a longer type or simply use the signed version of
the type that underlies size_t.

It goes on to describe the effects of reads and writes that exceed SSIZE_MAX,
given that the size argument is size_t but the return value is ssize_t.

It's probably not the correct type to use for math.

Look at this:

#include <cstdint>
#include <stdexcept>

using namespace std;

struct buint32_t
{ buint32_t();
buint32_t( uint32_t value );
buint32_t &operator =( uint32_t value );
operator uint32_t();
private:
friend buint32_t operator +( buint32_t left, buint32_t right );
friend buint32_t operator -( buint32_t left, buint32_t right );
friend buint32_t operator *( buint32_t left, buint32_t right );
friend buint32_t operator /( buint32_t left, buint32_t right );
friend buint32_t operator %( buint32_t left, buint32_t right );
uint32_t m_value;
};

inline
buint32_t::buint32_t()
{ }

inline
buint32_t::buint32_t( uint32_t value ) :
m_value( value )
{ }

inline
buint32_t &buint32_t::operator =( uint32_t value )
{ m_value = value;
return *this;
}

inline
buint32_t::operator uint32_t()
{ return m_value;
}

inline
buint32_t operator +( buint32_t left, buint32_t right )
{ if( left.m_value + right.m_value < left.m_value )
throw range_error( "buint32_t add-overflow" );
return buint32_t( left.m_value + right.m_value );
}

inline
buint32_t operator -( buint32_t left, buint32_t right )
{ if( left.m_value - right.m_value > left.m_value )
throw range_error( "buint32_t sub-underflow" );
return buint32_t( left.m_value - right.m_value );
}

inline
buint32_t operator *( buint32_t left, buint32_t right )
{ uint64_t result = (uint64_t)left.m_value * right.m_value;
if( result & (uint64_t)-0x100000000 )
throw range_error( "buint32_t mul-overflow" );
return buint32_t( (uint32_t)result );
}

inline
buint32_t operator /( buint32_t left, buint32_t right )
{ if( right.m_value == 0 )
throw range_error( "buint32_t division by zero" );
return buint32_t( left.m_value / right.m_value );
}

inline
buint32_t operator %( buint32_t left, buint32_t right )
{ if( right.m_value == 0 )
throw range_error( "buint32_t modulo by zero" );
return buint32_t( left.m_value % right.m_value );
}

With this class you can use buint32_t (b is for bounded) like a normal
uint32_t with almose the same performance (usual compilers keep object
with a single value with fits into a register also in a register) like
a uint32_t and you only have to catch errors in a central place and you
wont have to track for errors all over the code.
The class isn't complete but just an example, f.e. it lacks the +=, -=,
*=, /= operators and shifting isnt supported also. It's just an example
to show how more flexible C++ is.

On 06/05/2021 17:12, Bonita Montero wrote:
> Look at this:
>
> #include <cstdint>
> #include <stdexcept>
>
> using namespace std;
>
> struct buint32_t
> {
>     buint32_t();
>     buint32_t( uint32_t value );
>     buint32_t &operator =( uint32_t value );
>     operator uint32_t();
> private:
>     friend buint32_t operator +( buint32_t left, buint32_t right );
>     friend buint32_t operator -( buint32_t left, buint32_t right );
>     friend buint32_t operator *( buint32_t left, buint32_t right );
>     friend buint32_t operator /( buint32_t left, buint32_t right );
>     friend buint32_t operator %( buint32_t left, buint32_t right );
>     uint32_t m_value;
> };
>
> inline
> buint32_t::buint32_t()
> {
> }
>
> inline
> buint32_t::buint32_t( uint32_t value ) :
>     m_value( value )
> {
> }
>
> inline
> buint32_t &buint32_t::operator =( uint32_t value )
> {
>     m_value = value;
>     return *this;
> }
>
> inline
> buint32_t::operator uint32_t()
> {
>     return m_value;
> }
>
> inline
> buint32_t operator +( buint32_t left, buint32_t right )
> {
>     if( left.m_value + right.m_value < left.m_value )
>         throw range_error( "buint32_t add-overflow" );
>     return buint32_t( left.m_value + right.m_value );
> }
>
> inline
> buint32_t operator -( buint32_t left, buint32_t right )
> {
>     if( left.m_value - right.m_value > left.m_value )
>         throw range_error( "buint32_t sub-underflow" );
>     return buint32_t( left.m_value - right.m_value );
> }
>
> inline
> buint32_t operator *( buint32_t left, buint32_t right )
> {
>     uint64_t result = (uint64_t)left.m_value * right.m_value;
>     if( result & (uint64_t)-0x100000000 )
>         throw range_error( "buint32_t mul-overflow" );
>     return buint32_t( (uint32_t)result );
> }
>
> inline
> buint32_t operator /( buint32_t left, buint32_t right )
> {
>     if( right.m_value == 0 )
>         throw range_error( "buint32_t division by zero" );
>     return buint32_t( left.m_value / right.m_value );
> }
>
> inline
> buint32_t operator %( buint32_t left, buint32_t right )
> {
>     if( right.m_value == 0 )
>         throw range_error( "buint32_t modulo by zero" );
>     return buint32_t( left.m_value % right.m_value );
> }
>
> With this class you can use buint32_t (b is for bounded) like a normal
> uint32_t with almose the same performance (usual compilers keep object
> with a single value with fits into a register also in a register) like
> a uint32_t and you only have to catch errors in a central place and you
> wont have to track for errors all over the code.
> The class isn't complete but just an example, f.e. it lacks the +=, -=,
> *=, /= operators and shifting isnt supported also. It's just an example
> to show how more flexible C++ is.

It's an example of how you have to create your own DIY language, and
implement a big chunk of a compiler.

It can only be a toy example because fully supporting such a variation
of a primitive type is a huge amount of work.

For example defining interactions and conversions between this custom
type and standard numeric types; or this type and other custom user
types or different widths of this type.

Or printing this type, or creating literals of it, or just listing them;
how would this look using your type:

buint32_t A = 100;

> It's an example of how you have to create your own DIY language, and
> implement a big chunk of a compiler.

No, it's just defining types and overloading operators.

> It can only be a toy example because fully supporting such a variation
> of a primitive type is a huge amount of work.

Real code isn't far away from what I did.

> For example defining interactions and conversions between this custom
> type and standard numeric types; or this type and other custom user
> types or different widths of this type.

Of course, but a full featured buint32_t-class is only some hundred
lines more.

> Or printing this type, or creating literals of it, or just listing them;
> how would this look using your type:
>  buint32_t A = 100;

It would exacltly look how you wrote it.

Now, that is it:

#include <iostream>
#include <cstdint>
#include <stdexcept>

using namespace std;

struct buint32_t
{ buint32_t();
buint32_t( uint32_t value );
buint32_t &operator =( uint32_t value );
operator uint32_t();
buint32_t &operator +=( buint32_t right );
buint32_t &operator -=( buint32_t right );
buint32_t &operator *=( buint32_t right );
buint32_t &operator /=( buint32_t right );
buint32_t &operator %=( buint32_t right );
private:
friend buint32_t operator +( buint32_t left, buint32_t right );
friend buint32_t operator -( buint32_t left, buint32_t right );
friend buint32_t operator *( buint32_t left, buint32_t right );
friend buint32_t operator /( buint32_t left, buint32_t right );
friend buint32_t operator %( buint32_t left, buint32_t right );
uint32_t m_value;
};

inline
buint32_t::buint32_t()
{ }

inline
buint32_t::buint32_t( uint32_t value ) :
m_value( value )
{ }

inline
buint32_t &buint32_t::operator =( uint32_t value )
{ m_value = value;
return *this;
}

inline
buint32_t::operator uint32_t()
{ return m_value;
}

inline
buint32_t operator +( buint32_t left, buint32_t right )
{ if( left.m_value + right.m_value < left.m_value )
throw range_error( "buint32_t add-overflow" );
return buint32_t( left.m_value + right.m_value );
}

inline
buint32_t operator -( buint32_t left, buint32_t right )
{ if( left.m_value - right.m_value > left.m_value )
throw range_error( "buint32_t sub-underflow" );
return buint32_t( left.m_value - right.m_value );
}

inline
buint32_t operator *( buint32_t left, buint32_t right )
{ uint64_t result = (uint64_t)left.m_value * right.m_value;
if( result & (uint64_t)-0x100000000 )
throw range_error( "buint32_t mul-overflow" );
return buint32_t( (uint32_t)result );
}

inline
buint32_t operator /( buint32_t left, buint32_t right )
{ if( right.m_value == 0 )
throw range_error( "buint32_t division by zero" );
return buint32_t( left.m_value / right.m_value );
}

inline
buint32_t operator %( buint32_t left, buint32_t right )
{ if( right.m_value == 0 )
throw range_error( "buint32_t modulo by zero" );
return buint32_t( left.m_value % right.m_value );
}

inline
buint32_t &buint32_t::operator +=( buint32_t right )
{ if( m_value + right.m_value < m_value )
throw range_error( "buint32_t add-overflow" );
m_value += right.m_value;
return *this;
}

inline
buint32_t &buint32_t::operator -=( buint32_t right )
{ if( m_value - right.m_value > m_value )
throw range_error( "buint32_t add-overflow" );
m_value -= right.m_value;
return *this;
}

inline
buint32_t &buint32_t::operator *=( buint32_t right )
{ uint64_t result = (uint64_t)m_value * right.m_value;
if( result & (uint64_t)-0x100000000 )
throw range_error( "buint32_t mul-overflow" );
m_value = (uint32_t)result;
return *this;
}

inline
buint32_t &buint32_t::operator /=( buint32_t right )
{ if( right.m_value == 0 )
throw range_error( "buint32_t division by zero" );
m_value /= right.m_value;
return *this;
}

inline
buint32_t &buint32_t::operator %=( buint32_t right )
{ if( right.m_value == 0 )
throw range_error( "buint32_t modulo by zero" );
m_value %= right.m_value;
return *this;
}

int main()
{ try
{
buint32_t value = 123;
value *= 10;
value += 0xFFFFFFFFu;
}
catch( range_error &re )
{
cout << re.what() << endl;
}
}

As you can see from above, you can combine buint32_t with normal
unsigned integers as long as they fit into a uin32_t. All conver-
sions to buint32_t on the right side are done automatically.

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.

C DOES allow for signed types to be limited in the range of MAX ... -MAX
and not include the -MAX-1 value. 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)

On 5/6/21 11:27 AM, Oğuz wrote:
> On Thursday, May 6, 2021 at 6:05:21 PM UTC+3, Ben Bacarisse wrote:

>> 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? Can't I just do
> #if -INT_MAX <= INT_MIN
> #error
> #endif
> and rule them out?
>
>>
>> --
>> Ben.

non twos-complement machines are very rare, and if you are using a POSIX
system I believe they are ruled out.

There is talk of dropping full support for them in C in the future.

On 06/05/2021 18:19, Bonita Montero wrote:
> Now, that is it:
>

.....

> int main()
> {
>     try
>     {
>         buint32_t value = 123;
>         value *= 10;
>         value += 0xFFFFFFFFu;
>     }
>     catch( range_error &re )
>     {
>         cout << re.what() << endl;
>     }
> }
>
> As you can see from above, you can combine buint32_t with normal
> unsigned integers as long as they fit into a uin32_t. All conver-
> sions to buint32_t on the right side are done automatically.

This works better than I expected. But there is still lots to do. For
example, value+1 is an ambiguous overload.

Even if this was all done, it might not be the correct approach if you
have several such user-types in mind, as the support framework will
proliferate.

It also doesn't really work if working with an existing API that
requires ssize_t types.

On Thursday, May 6, 2021 at 8:42:44 PM UTC+3, Richard Damon wrote:
> On 5/6/21 11:27 AM, Oğuz wrote:
> > On Thursday, May 6, 2021 at 6:05:21 PM UTC+3, Ben Bacarisse wrote:
>
> >> 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? Can't I just do
> > #if -INT_MAX <= INT_MIN
> > #error
> > #endif
> > and rule them out?
> >
> >>
> >> --
> >> Ben.
> non twos-complement machines are very rare, and if you are using a POSIX
> system I believe they are ruled out.
>
> There is talk of dropping full support for them in C in the future.

Well that's good to know. Thank you

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> 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?

I wasn't able to find a specific requirement for 2's-complement in
POSIX.

POSIX requires int to be at least 32 bits and allows INT_MIN
to be -2147483647. I'm not sure whether that's allowing for
non-2's-complement representations, or for -2147483648 being treated
as a trap representation.

The next edition of the C standard is likely to mandate 2's-complement.
See section 6.2.6.2 of the N2644 draft, dated Jan 20, 2021.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2644.pdf

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

> This works better than I expected. But there is still lots to do. For
> example, value+1 is an ambiguous overload.

Ok, then you've to make the conversion to int32_t explicit:

struct bint32_t
{ ...
explicit operator int32_t();
// ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
};

> Even if this was all done, it might not be the correct approach if
> you have several such user-types in mind, as the support framework
> will proliferate.

Of course a framework with different bint**_t-types which are
convertible to each other are possible.

> It also doesn't really work if working with an existing API that
> requires ssize_t types.

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.

> struct bint32_t
> {
>     ...
> explicit operator int32_t();
explicit operator uint32_t();
> //      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>     ...
> };

On 06/05/2021 15:14, 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.
>

I'd read the specs too quickly - I had read it to mean the numbers could
not be -1 or less.

On 06/05/2021 20:03, Bart wrote:
> On 06/05/2021 18:19, Bonita Montero wrote:
>> Now, that is it:
>>
>
> ....
>
>> int main()
>> {
>>      try
>>      {
>>          buint32_t value = 123;
>>          value *= 10;
>>          value += 0xFFFFFFFFu;
>>      }
>>      catch( range_error &re )
>>      {
>>          cout << re.what() << endl;
>>      }
>> }
>>
>> As you can see from above, you can combine buint32_t with normal
>> unsigned integers as long as they fit into a uin32_t. All conver-
>> sions to buint32_t on the right side are done automatically.
>
> This works better than I expected. But there is still lots to do. For
> example, value+1 is an ambiguous overload.
>
> Even if this was all done, it might not be the correct approach if you
> have several such user-types in mind, as the support framework will
> proliferate.
>

You do this sort of thing with templates, so that you only need to write
it once and have it generate throw-on-overflow types for any underlying
integer type.

> It also doesn't really work if working with an existing API that
> requires ssize_t types.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> [...]
>> 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?
>
> I wasn't able to find a specific requirement for 2's-complement in
> POSIX.

Thanks. Neither could I, but not finding is not the same as finding
not, so I went with my fuzzy memory.

> POSIX requires int to be at least 32 bits and allows INT_MIN
> to be -2147483647. I'm not sure whether that's allowing for
> non-2's-complement representations, or for -2147483648 being treated
> as a trap representation.

Either way, Richard's example would overflow.

--
Ben.

Oğuz <oguzismailuysal@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?

--
Ben.