time to get rid of unsigned?

[John Harrison]

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

 

[Ron Natalie]

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?

Actually it looks like just the opposite problem. If the calculation was
all unsigned, it wouldn't be a problem.

 

[Claudio Puviani]

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?

You don't deprecate features because some people are too incompetent to use them
correctly. If you did, you'd also remove pointers, references, side-effects and
aliasing, etc. and end up with a completely different language that would
probably look a lot like ML. C++ is a power tool and needs to be used with the
appropriate caution and training. Any programming error is the fault of the
programmer, not the language.

Claudio Puviani

 

[John Harrison]

Actually it looks like just the opposite problem. If the calculation was
all unsigned, it wouldn't be a problem.

If it was all int it wouldn't be an issue either, the problem is the mix of
the two and the overflows that can result. Since I don't guess anyone is
proposing to remove signed integers, I'm proposing that we should drop
unsigned. Except maybe for character types.

john

 

[John Harrison]

You don't deprecate features because some people are too incompetent to use them
correctly. If you did, you'd also remove pointers, references, side-effects and
aliasing, etc. and end up with a completely different language that would
probably look a lot like ML. C++ is a power tool and needs to be used with the
appropriate caution and training. Any programming error is the fault of the
programmer, not the language.

Claudio Puviani

It's fair comment of course, but my point is that unsigned integers seem to
add so little to the language (unlike the other features you mention). I
would do without them completely myself, but when I try to interface with
the standard library or third party libraries and I start to get warnings
about signed/unsigned conflicts etc. so I weaken in my resolve and start to
use them a little.

john

 

[Jeff Schwab]

use them


side-effects and



It's fair comment of course, but my point is that unsigned integers seem to
add so little to the language (unlike the other features you mention). I
would do without them completely myself, but when I try to interface with
the standard library or third party libraries and I start to get warnings
about signed/unsigned conflicts etc. so I weaken in my resolve and start to
use them a little.

Why would you do without them? There is nothing wrong with using
unsigned integers. Programmers don't use them to get "one measly extra
bit." It's not an extra bit; an unsigned integer typically has the same
number of bits as its signed counterpart. The difference is just how
the bits are interpreted. To use a signed type in a context where
negative numbers are not meaningful is an odd design decision, to say
the least. To blame unsigned integers for overflow-related security
holes is just silly.

 

[Pete Becker]

It's fair comment of course, but my point is that unsigned integers seem to
add so little to the language (unlike the other features you mention). I
would do without them completely myself, but when I try to interface with
the standard library or third party libraries and I start to get warnings
about signed/unsigned conflicts etc. so I weaken in my resolve and start to
use them a little.

I wrote a multiple-precision math package in Java, using its signed
integral types. Quite an exercise, having to mask the result of every
operation to avoid sign extensions. It would have been much easier with
unsigned types.

 

[John Harrison]

Why would you do without them? There is nothing wrong with using
unsigned integers. Programmers don't use them to get "one measly extra
bit."

What I mean is that if we were forced to use signed integers, then the range
of representable positive integers would halve, i.e. we'd loose one bit.

It's not an extra bit; an unsigned integer typically has the same
number of bits as its signed counterpart.

I realise that.

The difference is just how
the bits are interpreted.

I realise that too.

To use a signed type in a context where
negative numbers are not meaningful is an odd design decision, to say
the least.

Many languages get along pertfectly well without unsigned integers.
Programmers in these languages are not forced to make odd design decisions
because of the lack of unsigned integers.

To blame unsigned integers for overflow-related security
holes is just silly.

That particular overflow could not have happened but for the existence of
unsigned integers. Had the negative number passed to the Read function not
been silently converted to a large positive number the problem wouldn't
exist. It seems quite reasonable to blame the existence of unsigned integers
for that bug. The programmer takes some blame too of course.

john

 

[Jeff Schwab]

What I mean is that if we were forced to use signed integers, then the range
of representable positive integers would halve, i.e. we'd loose one bit.

No, it wouldn't, and no, we wouldn't. N bits can represent exactly 2^N
discrete values. Whether you call them -pow(2,N-1) through pow(2,
N-1)-1, as you do when you use a signed integer, or 0 through
pow(2,N)-1, as you do when you use an unsigned integer, does not affect
the number of values you can represent.

I realise that.


I realise that too.


Many languages get along pertfectly well without unsigned integers.
Programmers in these languages are not forced to make odd design decisions
because of the lack of unsigned integers.

Those languages aren't C++.

That particular overflow could not have happened but for the existence of
unsigned integers. Had the negative number passed to the Read function not
been silently converted to a large positive number the problem wouldn't
exist. It seems quite reasonable

to you

to blame the existence of unsigned integers
for that bug. The programmer takes some blame too of course.

Well, it doesn't seem reasonable to me. It seems absurd. Anyway, if a
language problem did contribute to this flaw, it's the set of silent
conversion rules common to C and C++. The fact that a signed int can be
converted quietly to an unsigned int with a different numeric value is a
bit of a wart, IMHO. It's not new, though, and one might (naively)
think programmers would have learned to avoid its pitfalls by now <sigh/>.

 

[Ron Natalie]

That particular overflow could not have happened but for the existence of
unsigned integers. Had the negative number passed to the Read function not
been silently converted to a large positive number the problem wouldn't
exist. It seems quite reasonable to blame the existence of unsigned integers
for that bug. The programmer takes some blame too of course.

That's not how I read the code. What happened is that a large unsigned number
was converted tosigned negative allowing the test to be bypassed. The same thing
would have happened if the code was written with signed values that had a larger range
than the read routine was prepared to accept.

Overflow pure and simple.

 

[Jeff Schwab]

No, it wouldn't, and no, we wouldn't. N bits can represent exactly 2^N
discrete values. Whether you call them -pow(2,N-1) through pow(2,
N-1)-1, as you do when you use a signed integer, or 0 through
pow(2,N)-1, as you do when you use an unsigned integer, does not affect
the number of values you can represent.

Sorry, I need to correct myself before someone else does so less kindly.
You are correct that the range of representable, *positive* integers
would be halved. Perhaps you should be even more upset about the
existence of integer types with different numbers of bits; for example,
do you realize that a short int often holds only 1/65536 as many values
as a long int???

 

[Andre Kostur]

Many languages get along pertfectly well without unsigned integers.
Programmers in these languages are not forced to make odd design
decisions because of the lack of unsigned integers.

Arguably they do make odd design decisions. Or more accurately, they are
prohibited from making the "correct" design decision, and make do with
what the language provides. An unsigned variable is self-documenting in
a way. It tells other programmers that this negative values are
completely invalid. Like the size of an array. If that size were
represented as a signed integer, then it implicitly states that an array
may have a negative size.

That particular overflow could not have happened but for the existence
of unsigned integers. Had the negative number passed to the Read
function not been silently converted to a large positive number the
problem wouldn't exist. It seems quite reasonable to blame the
existence of unsigned integers for that bug. The programmer takes some
blame too of course.

That particular overflow could not have happened but for the existence of
signed integers. It seems quite reasonable to blame the programmer for
ignoring compiler warnings. Around here (where I work), the mandate is
that you crank the compiler warnings as high as you can bear (when the
compiler starts complaining about it's own header files... time to stop
cranking the warnings....), and your compile must have no warnings.

 

[John Harrison]

That's not how I read the code. What happened is that a large unsigned number
was converted tosigned negative allowing the test to be bypassed. The same thing
would have happened if the code was written with signed values that had a larger range
than the read routine was prepared to accept.

Overflow pure and simple.

_bmfh.bfOffBits is an unsigned type. The bug lies in the different treatment
of cbRead here

while (_bmfh.bfOffBits > (unsigned)cbRead)

and here

cbSkip = _bmfh.bfOffBits - cbRead;

Superficially the condition in the while loop prevents cbSkip going
negative. But because of the mix of signed and unsigned types it does no
such thing. If nothing else removing unsigned types would mean that the
meaning of arithmetical expressions would be closer to people intuitions.

john

 

[John Harrison]

I wrote a multiple-precision math package in Java, using its signed
integral types. Quite an exercise, having to mask the result of every
operation to avoid sign extensions. It would have been much easier with
unsigned types.

I'll grant you that, but its not something that many people have to do.

john

 

[P.J. Plauger]

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?

I knew that assignments were the cause of most storage alterations, some
of which can be erroneous and result in a security risk. So has the time
come for C++ to deprecate assignments?

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Jeff Schwab]

"Ron Natalie" <[email protected]> wrote in message

<snip> Contortion of Ron's post by Outlook Express </>
<!-- JH basically doesn't like unsigned integers. -->

Please get a news-reader that won't butcher other folks' posts.

<snip> Buggy bit of recently leaked Windows source. </>

If nothing else removing unsigned types would mean that the
meaning of arithmetical expressions would be closer to people intuitions.

By "people intuitions," what exactly do you mean? Unsigned arithmetic
predates signed arithmetic by thousands of years. I don't know about
you, but I certainly learned to count long before I heard of negative
numbers. Anyway, I think you should post your concerns in comp.std.c++.
Floats, unions, and C-style casts have survived this long, but I'm
sure the whole ISO C++ committee would agree that unsigned integers are
just more trouble than they're worth.

 

[John Harrison]

Arguably they do make odd design decisions. Or more accurately, they are
prohibited from making the "correct" design decision, and make do with
what the language provides. An unsigned variable is self-documenting in
a way. It tells other programmers that this negative values are
completely invalid. Like the size of an array. If that size were
represented as a signed integer, then it implicitly states that an array
may have a negative size.

But a similar example would be the size of a block of memory. For instance
memcpy takes an unsigned type for its third parameter presumably since you
cannot copy a negative number of bytes of memory. But this loses the chance
to do some error checking.

For instance I might write some code like this

size_t off = p - q; // p >= q
memcpy(a, p, off);

In this code p and q are pointers to some location with the char array a. I
am assuming the off is a positive or zero quantity. But suppose because of
bugged code that is wrong, memcpy cannot refuse to copy the very large
positive number of bytes that will result, because it is designed to copy
any unsigned quantity. But if memcpy took a signed type as its third
parameter, it could then quite reasonably refuse to copy a meaningless
negative number of bytes, thus reducing the chance of a buffer overflow.

That particular overflow could not have happened but for the existence of
signed integers.

It could not have happened but for the mix. Surely you're not proposing to
ban signed integers. Now that really would be ridiculous!

It seems quite reasonable to blame the programmer for
ignoring compiler warnings.

I think if you look at the code the programmer did not ignore compiler
warnings. I'm guessing of course but I think he did add a cast to the while
loop condition because of a compiler warning, but did not to the subtraction
because that particular compiler does not produce a warning for that.

Of course a better reaction would have been to change the type of cbRead to
unsigned.

Around here (where I work), the mandate is
that you crank the compiler warnings as high as you can bear (when the
compiler starts complaining about it's own header files... time to stop
cranking the warnings....), and your compile must have no warnings.

If only everywhere was so enlightened. But what to you do about bogus
warnings? I've known compiler to warn me about this

if (x == 0 && y <10 || y > 10)

telling me that I really should put brackets around y <10 || y > 10.
Arguably I should but it's a style issue not something a compiler should
warn me about.

john

 

[David Harmon]

I'll grant you that, but its not something that many people have to do.

Perhaps Pete is the only person who has to write it. But everyone who
uses it suffers the overhead of all the masking and shifting that he had
to use.

 

[John Harrison]

I knew that assignments were the cause of most storage alterations, some
of which can be erroneous and result in a security risk. So has the time
come for C++ to deprecate assignments?

Well I think I've covered that one already in another post.

Assignments are useful if dangerous, but of course some people do advocate
banning them on exactly those grounds, ask a functional programming zealot.

Unsigned integers are fairly useless, and somewhat dangerous, in my opinion.

john

 

[Pete Becker]

I'll grant you that, but its not something that many people have to do.

That's a common argument: I don't have to do it, so it's not important.