time to get rid of unsigned?

[Claudio Puviani]

Remember that the following are also embedded system:
Pacemakers
{Lung} Ventilators
MRI
CAT
X-RAY
Cruise Control for cars
Airplane guidance systems

We wouldn't want them having problems now, would we?

Which is why people tend to hire programmers with enough intelligence to use
their programming language correctly. If anyone who gets lost in the distinction
between signed and unsigned is put to work on a safety-critical system, that's
grounds for a law suit, not for changing the language. Just give it up, dude.
You have no ground to stand on.

Claudio Puviani

 

[Claudio Puviani]

Remember that the following are also embedded system:
Pacemakers
{Lung} Ventilators
MRI
CAT
X-RAY
Cruise Control for cars
Airplane guidance systems

We wouldn't want them having problems now, would we?

Sorry, Tom. I missed the sarcasm and thought this was yet another one of John
Harrison's attempts to justify absurdity. Many apologies.

Claudio Puviani

 

[Thomas Matthews]

I knew that unsigned integral data types were the cause of scads of mostly
spurious warning messages, but I didn't realise that they were a security
risk too (see here
http://www.securitytracker.com/alerts/2004/Feb/1009067.html). All for one
measly extra bit.

So has the time come for C++ to deprecate unsigned integral types?

john

I vote to keep the unsigned and signed integral types.

As I posted elsewhere, using unsigned for quantities,
distances, and positive (incrementing) counts allows
the compiler to perform type-check to reduce the
run-time problems; although there are conversions
between the two which screws things up.

When it comes to arithmetic, unsigned is undoubtedly
the easier form to use. Many processor instructions
have to "sign-extend" the signed quantities, such
as shifting or rotating a number (especialling in
the right direction).

My current escape goat on this topic is Borland.
They have used signed integers in their Windows
libraries where unsigned should be used (can a
control have a negative length?). So I am having
to perform casts on my code to be compatible with
their library.

If I writing an application for a {lung} ventilator,
and I need breaths per second, I cannot have a
negative quantity, so I will use an unsigned integer.
I don't want to have the risk of the controlling
variable to go into negative breaths per second.
Also, can one have a negative volume of air filled
into the lungs (can we say implosion?).

I also discussed that signed integers require at
least one bit for the sign, thus loosing one bit.
I'm working on an embedded system now that has
32 sources of interrupts. Not 31, but 32. So
we represent the register as an unsigned quantity
so we can access all 32 bits.

I belive that the signed and unsigned issue is one
of discipline. If one should drop unsigned integers
due to poor usage, then one should drop the entire
language because it can be very obscure without
discipline by programmers. Blame the programmers,
not the language. Does one fault a leaning house
on the tools or the developer?

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

 

[lilburne]

My current escape goat on this topic is Borland.
They have used signed integers in their Windows
libraries where unsigned should be used (can a
control have a negative length?). So I am having
to perform casts on my code to be compatible with
their library.

Do you want a control whose width is 4294967295?

If I writing an application for a {lung} ventilator,
and I need breaths per second, I cannot have a
negative quantity, so I will use an unsigned integer.
I don't want to have the risk of the controlling
variable to go into negative breaths per second.
Also, can one have a negative volume of air filled
into the lungs (can we say implosion?).

How about one that is 4294967295 breaths per second?

 

[=?ISO-8859-1?Q?Christian_Engstr=F6m?=]

Thomas Matthews wrote:

I propose we keep the unsigned types. Many embbeded applications use
all the bits of an integer type and don't consider them as signed.

The unsigned types as such wouldn't harm anybody, as long as the
implicit conversions to and from signed integers were removed.

If the standard was changed in this way we could still use unsigned
where they make sense (like in bit masks), but avoid the kind of
programming mistakes that resulted in the bug that started this thread.

Of course, a change like that would have to be introduced very gently
(through optional compiler warnings etc.) since it would break a lot of
existing code, so I wonder how keen the committee would be.

By the way, if the change was made (against all odds) I think it would
be a great opportunity to declare char as unsigned at the same time, to
separate them from the signed integers, and because negative characters
don't really make any sense in the first place.

Just my 2 cent.

/Christian

 

[Gavin Deane]

Do you want a control whose width is 4294967295?


How about one that is 4294967295 breaths per second?

Exactly.

If you think you risk introducing negative-volume-of-air bugs using
signed integers, then all unsigned does is convert that to a risk of
ridiculously large positive-volume-of-air bugs. You have gained
precisely nothing. The fact that your patients have exploded instead
of imploded is an irrelevant detail. It's the same bug and they are
just as dead.

 

[Gavin Deane]

They didn't believe this. They didn't calculate it!
For them it was simply silly to take away more then there is.
They were practical people: "You have 2 sheep. If you take away
3 sheep, with how many sheep are you left. Stupid! You can't
calculate that, because if you take away 2 sheep, there is
nothing left to take away! Sit down, F"

That's my point. Unsigned arithmetic as practised by C++
implementations is not the same thing as the unsigned arithmetic that
predates signed arithmetic by thousands of years. So the analogy is
not valid.

 

[Jeff Schwab]

That's my point. Unsigned arithmetic as practised by C++
implementations is not the same thing as the unsigned arithmetic that
predates signed arithmetic by thousands of years. So the analogy is
not valid.

Your complaint, then, is about the fact that integers overflow. It has
nothing to do with whether the types involved are signed.


#include <iostream>
#include <limits>

int main( )
{
signed s = std::numeric_limits< signed >::max( );

std::cout << s << " + 1 = " << ( s + 1 ) << " ?\n";
}

 

[David Harmon]

Ancient Babylonian mathematicians (or whoever it was) believed that 2
- 3 == 4294967295 ??? I don't think so.

Of course not. They thought it would throw an exception.

 

[Claudio Puviani]

lilburne <[email protected]> wrote in message

Exactly.

If you think you risk introducing negative-volume-of-air bugs using
signed integers, then all unsigned does is convert that to a risk of
ridiculously large positive-volume-of-air bugs. You have gained
precisely nothing. The fact that your patients have exploded instead
of imploded is an irrelevant detail. It's the same bug and they are
just as dead.

We can't forget practical considerations: there's less to clean up if the
patient implodes than if the patient explodes. ;-)

Claudio Puviani

 

[lilburne]

Your complaint, then, is about the fact that integers overflow. It has
nothing to do with whether the types involved are signed.

I suspect that most people don't encounter signed int overflow during
normal usage of integer values, because they aren't using integer values
in the Gb range. They will mostly encounter underflow of unsigned values
in mixed signed/unsigned expressions. Sometimes unexpectedly so for
example when size_t is unsigned:

std::vector<int> vec;
int x = 10;
if (x < vec.size() - 1) {
cout << "x in bounds" << endl;
}

 

[Gavin Deane]

We can't forget practical considerations: there's less to clean up if the
patient implodes than if the patient explodes. ;-)

Oh, I dunno. If you manage to pump in 4294967295 millilitres of air,
the bits might be so small you that wouldn't need to bother cleaning
up.

 

[Gavin Deane]

Your complaint, then, is about the fact that integers overflow. It has
nothing to do with whether the types involved are signed.

The difference is that the counterintuitive behaviour with signed
integers only happens at places like 2147483647 + 1. I can't remember
the last time I needed to count 2147483647 of something.

In contrast, with unsigned, the counterintuitive behaviour happens
with the sort of numbers I deal with all the time (2 - 3, for
example).

I'm not supporting the view that unsigned ought to go (and I'm fairly
sure that John Harrison wasn't wholly serious about it either). But I
don't feel I have anything to gain by using unsigned because having -1
silently munged into 4294967295 doesn't help me get my code correct.
The -1 should never have been there in the first place.

GJD

 

[Thomas Matthews]

Do you want a control whose width is 4294967295?

I don't understand what you are implying. (Perhaps
that -1 is a large value when converted to unsigned).
I also don't understand why such a large number.
For example, if a short int holds 16 bits, and the
control width is a short unsigned int, then I am allowed
to have a with that is 65535. Which is fine.

Just explain to me what a control looks like that
has a width of -3 and a height of -10.

How about one that is 4294967295 breaths per second?

I believe you are assuming 32 bits per integer.
Let us assume 8 bits per integer. Then you are claiming
"How about 255 breaths per second." But what does this
have to do with signed or unsigned?

You comment doesn't have any place in either section.
Functions that use integral numbers should have range
checking. For example, one could state that the upper
limit is 50 breaths per second. Using an 8-bit signed
integer allows a range of -128 to +127. So if the
function for calculating breath rates uses a signed
8-bit integer, then a negative value is possible.
Using unsigned integers, a negative value would be
rejected (providing there is no automatic conversion)
by the compiler. One cannot have -5 breaths per second.

If I use a signed value for breaths per second then I
would have to use an addition lower bound check to make
sure that a value less than zero was not passed. One
could have zero breaths per second (such as when the
the machine is disconnected). Again, how can one
have a negative breath per second or a breath per
negative second?

My point is that when a range is in the domain of positive
integral values, one should use an unsigned data type.
When the range is allowed to go into the domain of negative
and positive integral values, one should use a signed
data type. One never counts negative chickens or apples.
However, an index in a decrementing loop may be decremented
past zero, depending on whether zero is a valid index and
when the decrementing takes place.


--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

 

[Ron Natalie]

.

The difference is that the counterintuitive behaviour with signed
integers only happens at places like 2147483647 + 1. I can't remember
the last time I needed to count 2147483647 of something.

No it doesn't, it happens any time you add two numbers that add to more
than numeric_limits<int>::max().

The specific example would have just as easily blown if the bitmap size
was a bigger signed integer. Something implementation specific would have
happened on the conversion from a "larger than can be represented in int"
value to int, possibly truncation leaving a smaller value than the limit check
was checking for.

 

[lilburne]

I don't understand what you are implying. (Perhaps
that -1 is a large value when converted to unsigned).
I also don't understand why such a large number.
For example, if a short int holds 16 bits, and the
control width is a short unsigned int, then I am allowed
to have a with that is 65535. Which is fine.

Just explain to me what a control looks like that
has a width of -3 and a height of -10.

IMO it usually looks as bad as one that is 65535 high or wide.

I believe you are assuming 32 bits per integer.
Let us assume 8 bits per integer. Then you are claiming
"How about 255 breaths per second." But what does this
have to do with signed or unsigned?

You comment doesn't have any place in either section.
Functions that use integral numbers should have range
checking.

Exactly. Using unsigned doesn't negate the fact that the
range should be checked.

If I use a signed value for breaths per second then I
would have to use an addition lower bound check to make
sure that a value less than zero was not passed. One
could have zero breaths per second (such as when the
the machine is disconnected). Again, how can one
have a negative breath per second or a breath per
negative second?

if (x >= 0) {}

is on most machines a single test instruction and a
conditional jump. Example:

testl %eax, %eax
js L3

which is pretty quick.

My point is that when a range is in the domain of positive
integral values, one should use an unsigned data type.
When the range is allowed to go into the domain of negative
and positive integral values, one should use a signed
data type. One never counts negative chickens or apples.
However, an index in a decrementing loop may be decremented
past zero, depending on whether zero is a valid index and
when the decrementing takes place.

The trouble with using unsigned in an interface is that one
will encounter mixed signed/unsigned expressions, if for no
other reason than that 'int' is easier to type then
'unsigned'. Though you can usually get the compiler to warn
you about such things, the problem is most acute when
functions return unsigned, because the behaviour is often
surprising:

#include <iostream>
#include <vector>

int main ()
{
std::vector<int> vec;
int x = 0;
if (x < vec.size() - 1) {
std::cout << "in range" << std::endl;
}
return 0;
}

of course 'int x = 10;' ought to be 'size_t x = 0;' and one
learns to write such, but the trap always lies in wait.

 

[Gavin Deane]

My point is that when a range is in the domain of positive
integral values, one should use an unsigned data type.

Not if you ever want to subtract one such value from another, for
example, and get a meaningful result, because 2 - 3, when the
variables holding 2 and 3 are unsigned, doesn't give -1.

I need a very good reason to use an integral type for which 2 - 3 !=
-1. The fact that the language rules remove the need for a (value >=
0) range check when I still have to check (value < max_allowed) is not
reason enough for me.

 

[Risto Lankinen]

Hi!

I need a very good reason to use an integral type for which 2 - 3 !=
-1. The fact that the language rules remove the need for a (value >=
0) range check when I still have to check (value < max_allowed) is not
reason enough for me.

The discussion seems to be concentrating on whether, as a
bogus result of a buggy calculation, -1 is better than 4G. To
me they're both just plain wrong, which strongly hints that
some kind of a guard should be inserted before the potentially
buggy calculation:

SOME_int a,b,result;

if( a<b ) throw SillyArgs(a,b);
result = a-b;

Now, if you agree with me so far (and I¨'d like to hear why,
if not), then isn't unsigned just a plain simple extension of the
allowable range of results, more than doubling from 2G-1 to
4G-1 (in systems where int = 32-bit)? For most applications
this probably doesn't make a big difference, but the point is
that for some others it will!

Finally, if 2-3 != 4G bothers you now, then won't 2 / 3 != 0
bother you next? There is a reason for why we don't use
Complex<double> for everything, though it apparently would
let us forget about number domain problems for good (but
only apparently).

- Risto -

 

[Tõnu Aas]

I need a very good reason to use an integral type for which 2 - 3 != -1.

Offset for example.
There big amount of viruses that used this type of calculations for
stack trashing. Microsoft "programmers" used in many places int
instead of unsigned and the result is OS with many many holes for viruses.

There are many places where you cant use int-s instead of unsigned.

Tõnu.

 

[Jeff Schwab]

I suspect that most people don't encounter signed int overflow during
normal usage of integer values, because they aren't using integer values
in the Gb range. They will mostly encounter underflow of unsigned values
in mixed signed/unsigned expressions. Sometimes unexpectedly so for
example when size_t is unsigned:

std::vector<int> vec;
int x = 10;
if (x < vec.size() - 1) {
cout << "x in bounds" << endl;
}

You've chosen an excellent example, in which a signed type is necessary
to make the code "work." However, this is just blurring the line
between the responsibility of the programmer and the responsibility of
the language. Subtraction is not a closed operation over the unsigned
integers; to subtract two without checking for underflow may be risky.
It is the responsibility of the programmer, not the C++ language, to
determine when such risks are reasonable.

Btw, I agree completely with Risto's opinion later in this thread. I'm
afraid I don't have the time or the eloquence to express the point as
well as he does.