f



time to get rid of unsigned?

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


0
2/17/2004 9:10:56 PM
comp.lang.c++ 49423 articles. 6 followers. Post Follow

100 Replies
532 Views

Similar Articles

[PageSpeed] 59

"John Harrison" <john_andronicus@hotmail.com> wrote in message news:c0u010$1beu6e$1@ID-196037.news.uni-berlin.de...
> 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.
0
ron156 (1433)
2/17/2004 9:20:53 PM
"John Harrison" <john_andronicus@hotmail.com> wrote
> 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


0
puviani (290)
2/17/2004 9:25:05 PM
"Ron Natalie" <ron@sensor.com> wrote in message
news:40328541$0$165$9a6e19ea@news.newshosting.com...
>
> "John Harrison" <john_andronicus@hotmail.com> wrote in message
news:c0u010$1beu6e$1@ID-196037.news.uni-berlin.de...
> > 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.

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


0
2/17/2004 9:58:59 PM
"Claudio Puviani" <puviani@hotmail.com> wrote in message
news:REvYb.87101$cE3.31206245@news4.srv.hcvlny.cv.net...
> "John Harrison" <john_andronicus@hotmail.com> wrote
> > 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
>

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


0
2/17/2004 10:04:15 PM
John Harrison wrote:
> "Claudio Puviani" <puviani@hotmail.com> wrote in message
> news:REvYb.87101$cE3.31206245@news4.srv.hcvlny.cv.net...
> 
>>"John Harrison" <john_andronicus@hotmail.com> wrote
>>
>>>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
>>
> 
> 
> 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.

0
jeffplus (649)
2/17/2004 10:14:31 PM
John Harrison wrote:
> 
> 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.

-- 

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
0
petebecker (1324)
2/17/2004 10:26:39 PM
"Jeff Schwab" <jeffplus@comcast.net> wrote in message
news:kbSdnZa4VuTGCa_dRVn-uQ@comcast.com...
> John Harrison wrote:
> > "Claudio Puviani" <puviani@hotmail.com> wrote in message
> > news:REvYb.87101$cE3.31206245@news4.srv.hcvlny.cv.net...
> >
> >>"John Harrison" <john_andronicus@hotmail.com> wrote
> >>
> >>>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
> >>
> >
> >
> > 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."

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


0
2/17/2004 10:31:52 PM
<snip> Discussion about whether unsigned int's are inherently unsafe. </>

>>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.

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.

>>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.

Those languages aren't C++.

>>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 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/>.

0
jeffplus (649)
2/17/2004 10:36:24 PM
"John Harrison" <john_andronicus@hotmail.com> wrote in message news:c0u4oo$1bngq1$1@ID-196037.news.uni-berlin.de...
> 
> 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.

0
ron156 (1433)
2/17/2004 10:40:16 PM
Jeff Schwab wrote:
> <snip> Discussion about whether unsigned int's are inherently unsafe. </>
> 
>>> 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.
> 
> 
> 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???

0
jeffplus (649)
2/17/2004 10:41:43 PM
"John Harrison" <john_andronicus@hotmail.com> wrote in
news:c0u4oo$1bngq1$1@ID-196037.news.uni-berlin.de: 

>> 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.

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.
 
>> 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. 

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.
0
nntpspam (752)
2/17/2004 10:49:05 PM
"Ron Natalie" <ron@sensor.com> wrote in message
news:403297da$0$161$9a6e19ea@news.newshosting.com...
>
> "John Harrison" <john_andronicus@hotmail.com> wrote in message
news:c0u4oo$1bngq1$1@ID-196037.news.uni-berlin.de...
> >
> > 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.
>

_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


0
2/17/2004 11:23:40 PM
"Pete Becker" <petebecker@acm.org> wrote in message
news:4032951F.DC51357F@acm.org...
> John Harrison wrote:
> >
> > 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.
>

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

john


0
2/17/2004 11:24:26 PM
"John Harrison" <john_andronicus@hotmail.com> wrote in message
news:c0u010$1beu6e$1@ID-196037.news.uni-berlin.de...

> 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


0
pjp (713)
2/17/2004 11:28:01 PM
John Harrison wrote:
> "Ron Natalie" <ron@sensor.com> 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. </>
<!--   JH blames unsigned integers for Windows bug. </>

> 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.

0
jeffplus (649)
2/17/2004 11:42:30 PM
"Andre Kostur" <nntpspam@kostur.net> wrote in message
news:Xns9492971DCEB24nntpspamkosturnet@206.172.150.14...
> "John Harrison" <john_andronicus@hotmail.com> wrote in
> news:c0u4oo$1bngq1$1@ID-196037.news.uni-berlin.de:
>
> >> 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.
>
> 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.


>
> >> 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.
>
> 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



0
2/17/2004 11:45:49 PM
On Tue, 17 Feb 2004 23:24:26 -0000 in comp.lang.c++, "John Harrison"
<john_andronicus@hotmail.com> was alleged to have written:
>
>"Pete Becker" <petebecker@acm.org> wrote 
>> 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.

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.

0
source (1021)
2/17/2004 11:53:32 PM
"P.J. Plauger" <pjp@dinkumware.com> wrote in message
news:5sxYb.38766$1S1.14468@nwrddc01.gnilink.net...
> "John Harrison" <john_andronicus@hotmail.com> wrote in message
> news:c0u010$1beu6e$1@ID-196037.news.uni-berlin.de...
>
> > 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?

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


0
2/17/2004 11:54:24 PM
John Harrison wrote:
> 
> 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.

-- 

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
0
petebecker (1324)
2/18/2004 12:02:20 AM
"Jeff Schwab" <jeffplus@comcast.net> wrote in message
news:SdudnfRVU-dnNa_dRVn-vg@comcast.com...
> John Harrison wrote:
> > "Ron Natalie" <ron@sensor.com> 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. </>
> <!--   JH blames unsigned integers for Windows bug. </>
>
> > 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.

I said this a few times already but its the MIX that causes the problems.

If we only had signed integer arithmetic things would be simpler. And you
are right, if we only had unsigned integer arithmetic then things would be
simpler still. But while I would be prepared to program in a language that
only had signed integers, I'd find one that only had unsigned rather
difficult.

> 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.

Well I'm not being entirely serious, but this issue is a particular bugbear
of mine, and I thought the Windows source was a good example to back it up.
I don't expect to get much agreement. (But one person agreeing with me would
be nice). At least I haven't been accused of being a troll yet.

john


0
2/18/2004 12:04:16 AM
"Pete Becker" <petebecker@acm.org> wrote in message
news:4032AB8C.36BBD5E@acm.org...
> John Harrison wrote:
> >
> > 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.
>

I didn't say I don't have to do it, in fact writing a large integer library
is one thing I have done (and yes I did use unsigned integers). I said its
not something *many* people have to do.

john


0
2/18/2004 12:09:57 AM
John Harrison wrote:
> 
> "Pete Becker" <petebecker@acm.org> wrote in message
> news:4032AB8C.36BBD5E@acm.org...
> > John Harrison wrote:
> > >
> > > 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.
> >
> 
> I didn't say I don't have to do it, in fact writing a large integer library
> is one thing I have done (and yes I did use unsigned integers). I said its
> not something *many* people have to do.
> 

For some unspecified value of *many*. Still nonsense.

-- 

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
0
petebecker (1324)
2/18/2004 12:14:05 AM
"Pete Becker" <petebecker@acm.org> wrote in message
news:4032AE4D.3F6942C7@acm.org...
> John Harrison wrote:
> >
> > "Pete Becker" <petebecker@acm.org> wrote in message
> > news:4032AB8C.36BBD5E@acm.org...
> > > John Harrison wrote:
> > > >
> > > > 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.
> > >
> >
> > I didn't say I don't have to do it, in fact writing a large integer
library
> > is one thing I have done (and yes I did use unsigned integers). I said
its
> > not something *many* people have to do.
> >
>
> For some unspecified value of *many*. Still nonsense.
>

Huh? I don't understand. Are you saying that most programmers write large
integer libraries?

What I was trying to say that you raised a perfectly good example of when
unsigned integers are useful. I agree with you, but I still think that
example is not enough to change my mind because it doesn't figure in the
work that most programmers do most of the time. Does that make sense? I
don't think it's nonsense.

john


0
2/18/2004 12:20:51 AM
John Harrison wrote:
> 
> Huh? I don't understand. Are you saying that most programmers write large
> integer libraries?

Nope. I'm saying the language shouldn't be designed around what *you*
think is important.

-- 

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
0
petebecker (1324)
2/18/2004 12:27:04 AM
"John Harrison" <john_andronicus@hotmail.com> wrote in message
news:c0u010$1beu6e$1@ID-196037.news.uni-berlin.de...
> 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 would judge that it's too late to take unsigned integer types out of C or
C++, but I understand and appreciate your point more than many of the other
respondents seem to have done. When I use a language which lacks this
feature I never seem to miss it.

-- 
Cy
http://home.rochester.rr.com/cyhome/


0
cedmunds (352)
2/18/2004 12:32:50 AM
John Harrison wrote:

> 
> 
> I said this a few times already but its the MIX that causes the problems.
> 

The last time I used Modula2 you couldn't mix Integer and 
Cardinal. But that was 12 years ago so it might have changed.

Of course in C++ you don't have to use unsigned, and off 
hand I can't recall doing so myself in the last 10 years. 
Well perhaps once or twice for nefarious bit twiddling. I'm 
certain that none of our libraries use unsigned in any of 
the APIs.

0
lilburne3 (346)
2/18/2004 12:42:02 AM
unsigned integers are commonly used to declare 'count' or 'index' or 'size'*
type variables that will never contain negative values.

signed integers should be used for ingeger math*.

Shouldn't mix the types w/ the purpose, however it does happen.  When writing
self-documenting code, you should use the type that applies.

Deprecating unsigned is essentially saying that the former reason has no
perceived value in the language.

(*other reasons exist, that are not delineated here.)

John Harrison wrote:
> 
> 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

-- 
Bret Pehrson
mailto:bret@infowest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl>>
0
bret (18)
2/18/2004 12:53:40 AM
On Tue, 17 Feb 2004 21:10:56 -0000, "John Harrison"
<john_andronicus@hotmail.com> wrote in comp.lang.c++:

> 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

Perhaps you do not have much use for unsigned integer types, but there
are most certainly others who do.

Most of the buffer exploits around have been based on poor
programming, not on the data types used.  This one is no different.

-- 
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
0
jackklein (3930)
2/18/2004 2:44:00 AM
"John Harrison" <john_andronicus@hotmail.com> wrote in
news:c0u93d$18cono$1@ID-196037.news.uni-berlin.de: 

> 
> "Andre Kostur" <nntpspam@kostur.net> wrote in message
> news:Xns9492971DCEB24nntpspamkosturnet@206.172.150.14...
>> "John Harrison" <john_andronicus@hotmail.com> wrote in
>> news:c0u4oo$1bngq1$1@ID-196037.news.uni-berlin.de:
>>
>> >> 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.
>>
>> 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.

This is a good thing:
1) The function signature correctly documents that negative numbers are 
not valid 
2) The called function does not have to waste time performing a 
comparison for invalid data.  The invalid data cannot be represented in 
the parameters.

Or, you may have a strange memcpy which allows you to designate the _end_ 
of the block in interest, and a negative size indicates you want to copy 
the X number of bytes _before_ the pointer.... :)

> For instance I might write some code like this
> 
> size_t off = p - q;    // p >= q
> memcpy(a, p, off);

And then I promptly beat you to a pulp (hypothetically) (OK, I promptly 
explain to you...) for not range checking the relative values of p and q.  
(See pretty much any of the STL algorithms which take two iterators... 
the algorithms don't check to see if they are correctly ordered, that's 
the programmer's responsibility.  Same sort of idea).

> 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. 

Then you would be wasting the great majority of your calls to memcpy 
checking for a condition which _might_ happen only during debugging.  
Probably more effective to link against a debug version of the C runtime 
which would exception on calls to memcpy of blocks larger that 
0x7FFFFFFFUL (assuming 32-bit architecture...).  Once you've determined 
with sufficient certainty that your program is bug-free (HA! :) ), you 
link against the release-mode memcpy which doesn't waste time checking 
for a condition that will never (famous last words....) happen.

>> >> 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.
>>
>> 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!

No more ridiculous than banning unsigned integers...

>> 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. 

Actually, that's worse.  The compiler dutifully warned the programmer 
that there might be a problem here, and the programmer willfully ignored 
the warning and forced the compiler to shut up.

> 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.

Personally I'd prefer to stick in a whole bunch of extra parens in there 
anyway... :) (I like the style.. thus: if ((x == 0) && (y != 10))  )
0
nntpspam (752)
2/18/2004 7:19:27 AM
"Pete Becker" <petebecker@acm.org> wrote in message
news:4032B158.883BCA2A@acm.org...
> John Harrison wrote:
> >
> > Huh? I don't understand. Are you saying that most programmers write
large
> > integer libraries?
>
> Nope. I'm saying the language shouldn't be designed around what *you*
> think is important.
>

OK I understand, and I also agree.

john


0
2/18/2004 7:25:26 AM
"Cy Edmunds" <cedmunds@spamless.rochester.rr.com> wrote in message
news:SoyYb.66886$n62.63454@twister.nyroc.rr.com...
> "John Harrison" <john_andronicus@hotmail.com> wrote in message
> news:c0u010$1beu6e$1@ID-196037.news.uni-berlin.de...
> > 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 would judge that it's too late to take unsigned integer types out of C
or
> C++, but I understand and appreciate your point more than many of the
other
> respondents seem to have done. When I use a language which lacks this
> feature I never seem to miss it.
>

Well I wasn't really being serious, instead just making the point that
unsigned types cause more problems than they solve. I too would very rarely
miss them.

I glad at least one person sees my POV.

john


0
2/18/2004 7:30:34 AM
"John Harrison" <john_andronicus@hotmail.com> wrote
> I said this a few times already but its the MIX that causes the problems.

So don't mix them!

If you write 'double v = 1/3;' v is set to 0.0 because you're mixing integer and
double arithmetic. OMG! Does this mean we should eliminate integers altogether
and only have floating point???

See how ridiculous that logic is? C++ isn't a language that's designed for the
left half of the bell curve. Unsigned ints have many uses and they should not be
removed just to protect people who can't or won't bother to learn the rules of
the language. There are languages that suit those people.

Claudio Puviani


0
puviani (290)
2/18/2004 2:32:45 PM
"John Harrison" <john_andronicus@hotmail.com> wrote in message news:c0ua86$1c9sbl$1@ID-196037.news.uni-berlin.de...

> If we only had signed integer arithmetic things would be simpler.

Just barely.   The problem would have occurred with a larger signed value
as well.

0
ron156 (1433)
2/18/2004 3:29:12 PM
Jeff Schwab <jeffplus@comcast.net> wrote in message news:<SdudnfRVU-dnNa_dRVn-vg@comcast.com>...
> John Harrison wrote:
> > "Ron Natalie" <ron@sensor.com> wrote in message

<snip>

> 
> > 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.

Excuse me?

Ancient Babylonian mathematicians (or whoever it was) believed that 2
- 3 == 4294967295 ???  I don't think so. But that's what my C++
implementation believes. By the time anyone writes their first C++
program, they will be absolutely certain that 2 - 3 == -1.

People understand that the result of subtracting two positive numbers
is not necessarily another positive number. The behaviour of unsigned
does *not* match this intuition. Which is why using unsigned to model
positive numbers is not necessarily helpful.

Often, values for which < 0 makes no sense have upper limits too -
when you want to know what time it is, the value of a 'minutes'
variable has to be between 0 and 59. Would you use unsigned for that?
It prevents you storing -1 minutes past the hour, but 61 minutes past
is still possible. If it's that important not to exceed the limits,
you're best off writing a class to guarantee it. In which case you
lose nothing by using a signed type inside the class.

Apart from interfacing with 3rd party APIs (including the standard
library) I only have a need for unsigned types when I'm bit-twiddling.

-- 
GJD
0
deane_gavin (897)
2/18/2004 3:45:07 PM
John Harrison wrote:

> "Ron Natalie" <ron@sensor.com> wrote in message
> news:40328541$0$165$9a6e19ea@news.newshosting.com...
> 
>>"John Harrison" <john_andronicus@hotmail.com> wrote in message
> 
> news:c0u010$1beu6e$1@ID-196037.news.uni-berlin.de...
> 
>>>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.
> 
> 
> 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
> 

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.
A signed integer has one less bit to use, which may make a difference
in some embedded applications.

-- 
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

0
2/18/2004 4:02:42 PM

Thomas Matthews wrote:

>
> A signed integer has one less bit to use, which may make a difference
> in some embedded applications.
> 

If that means there would be less mobile phones going off around me, 
then I vote "kill the unsigned now".

0
lilburne (87)
2/18/2004 4:18:57 PM
Gavin Deane wrote:
> 

> > By "people intuitions," what exactly do you mean?  Unsigned arithmetic
> > predates signed arithmetic by thousands of years.
> 
> Excuse me?
> 
> Ancient Babylonian mathematicians (or whoever it was) believed that 2
> - 3 == 4294967295 ???  I don't think so.

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"

-- 
Karl Heinz Buchegger
kbuchegg@gascad.at
0
kbuchegg (2095)
2/18/2004 4:54:15 PM
lilburne wrote:

> 
> 
> Thomas Matthews wrote:
> 
>>
>> A signed integer has one less bit to use, which may make a difference
>> in some embedded applications.
>>
> 
> If that means there would be less mobile phones going off around me, 
> then I vote "kill the unsigned now".
> 

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?

-- 
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

0
2/18/2004 5:24:00 PM
Jack Klein wrote:

> On Tue, 17 Feb 2004 21:10:56 -0000, "John Harrison"
> <john_andronicus@hotmail.com> wrote in comp.lang.c++:
> 
> 
>>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
> 
> 
> Perhaps you do not have much use for unsigned integer types, but there
> are most certainly others who do.
> 
> Most of the buffer exploits around have been based on poor
> programming, not on the data types used.  This one is no different.
> 

To add to your response:

Using unsiqned integers to represent quantities (and distances)
allows the compiler to perform type-checking and reduce the
run-time errors.  The caveat to this is that there are conversions
between the two that allow one to use a signed integer to denote
a quantity, such as an array or buffer size.

I vote to keep both.  I believe that much of the problems are
due to a lack of discipline with the programmer.  C and C++
are powerful languages.  With out proper discipline, both
of them become unreadable and unmanageable; yet we still
keep them.

-- 
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

0
2/18/2004 5:33:20 PM
"Thomas Matthews" <Thomas_MatthewsSpitsOnSpamBots@sbcglobal.net> wrote
> lilburne wrote:
>
> >
> >
> > Thomas Matthews wrote:
> >
> >>
> >> A signed integer has one less bit to use, which may make a difference
> >> in some embedded applications.
> >>
> >
> > If that means there would be less mobile phones going off around me,
> > then I vote "kill the unsigned now".
> >
>
> 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


0
puviani (290)
2/18/2004 5:35:22 PM
"Thomas Matthews" <Thomas_MatthewsSpitsOnSpamBots@sbcglobal.net>
wrote$CY7.12889@newssvr33.news.prodigy.com...
> lilburne wrote:
>
> >
> >
> > Thomas Matthews wrote:
> >
> >>
> >> A signed integer has one less bit to use, which may make a difference
> >> in some embedded applications.
> >>
> >
> > If that means there would be less mobile phones going off around me,
> > then I vote "kill the unsigned now".
> >
>
> 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


0
puviani (290)
2/18/2004 5:39:26 PM
John Harrison wrote:

> 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

0
2/18/2004 5:45:39 PM
Thomas Matthews wrote:

> 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?

0
lilburne3 (346)
2/18/2004 9:28:15 PM
>> John Harrison wrote:
>> 
>> So has the time come for C++ to deprecate unsigned integral types?
>>
>
> 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

0
2/19/2004 10:01:41 AM
lilburne <lilburne@godzilla.net> wrote in message news:<c10lef$1cjr9a$1@ID-179504.news.uni-berlin.de>...
> Thomas Matthews wrote:
> 
> > 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?

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.

-- 
GJD
0
deane_gavin (897)
2/19/2004 11:40:54 AM
Karl Heinz Buchegger <kbuchegg@gascad.at> wrote in message news:<403398B7.3A8AF87B@gascad.at>...
> Gavin Deane wrote:
> > 
>  
> > > By "people intuitions," what exactly do you mean?  Unsigned arithmetic
> > > predates signed arithmetic by thousands of years.
> > 
> > Excuse me?
> > 
> > Ancient Babylonian mathematicians (or whoever it was) believed that 2
> > - 3 == 4294967295 ???  I don't think so.
> 
> 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.

-- 
GJD
0
deane_gavin (897)
2/19/2004 11:45:52 AM
Gavin Deane wrote:
> Karl Heinz Buchegger <kbuchegg@gascad.at> wrote in message news:<403398B7.3A8AF87B@gascad.at>...
> 
>>Gavin Deane wrote:
>>
>> 
>>
>>>>By "people intuitions," what exactly do you mean?  Unsigned arithmetic
>>>>predates signed arithmetic by thousands of years.
>>>
>>>Excuse me?
>>>
>>>Ancient Babylonian mathematicians (or whoever it was) believed that 2
>>>- 3 == 4294967295 ???  I don't think so.
>>
>>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.
> 

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";
}

0
jeffplus (649)
2/19/2004 1:14:06 PM
On 18 Feb 2004 07:45:07 -0800 in comp.lang.c++, deane_gavin@hotmail.com
(Gavin Deane) was alleged to have written:
>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.

0
source (1021)
2/19/2004 2:05:29 PM
"Gavin Deane" <deane_gavin@hotmail.com> wrote
> lilburne <lilburne@godzilla.net> wrote in message
news:<c10lef$1cjr9a$1@ID-179504.news.uni-berlin.de>...
> > Thomas Matthews wrote:
> >
> > > 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?
>
> 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


0
puviani (290)
2/19/2004 3:56:24 PM

Jeff Schwab wrote:

> Gavin Deane wrote:
> 
>>
>> 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.
> 

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;
   }

0
lilburne (87)
2/19/2004 4:08:49 PM
"Claudio Puviani" <puviani@hotmail.com> wrote in message news:<I05Zb.1506$ya.833249@news4.srv.hcvlny.cv.net>...
> "Gavin Deane" <deane_gavin@hotmail.com> wrote
> > lilburne <lilburne@godzilla.net> wrote in message
>  news:<c10lef$1cjr9a$1@ID-179504.news.uni-berlin.de>...
> > > Thomas Matthews wrote:
> > >
> > > > 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?
> >
> > 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. ;-)

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. :)
0
deane_gavin (897)
2/19/2004 8:12:02 PM
Jeff Schwab <jeffplus@comcast.net> wrote in message news:<guWdnbig2qJ4JandRVn-ug@comcast.com>...
> Gavin Deane wrote:
> > Karl Heinz Buchegger <kbuchegg@gascad.at> wrote in message news:<403398B7.3A8AF87B@gascad.at>...
> > 
> >>Gavin Deane wrote:
> >>
> >> 
> >>
> >>>>By "people intuitions," what exactly do you mean?  Unsigned arithmetic
> >>>>predates signed arithmetic by thousands of years.
> >>>
> >>>Excuse me?
> >>>
> >>>Ancient Babylonian mathematicians (or whoever it was) believed that 2
> >>>- 3 == 4294967295 ???  I don't think so.
> >>
> >>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.
> > 
> 
> 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
0
deane_gavin (897)
2/19/2004 8:37:35 PM
lilburne wrote:
> Thomas Matthews wrote:
> 
>> 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?

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.


> 
>> 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?

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

0
2/19/2004 8:46:09 PM
"Gavin Deane" <deane_gavin@hotmail.com> wrote in message news:6d8002d0.0402191237.45bca7f2@posting.google.com...
> .
> 
> 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.

> 
0
ron156 (1433)
2/19/2004 10:02:21 PM
Thomas Matthews wrote:

> lilburne wrote:
> 
>> Thomas Matthews wrote:
>>
>>> 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?
> 
> 
> 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.


> 
>>
>>> 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?
> 
> 
> 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.


0
lilburne3 (346)
2/20/2004 12:15:48 AM
Thomas Matthews <Thomas_MatthewsSpitsOnSpamBots@sbcglobal.net> wrote in message news:<lg9Zb.13674$yM3.11117@newssvr31.news.prodigy.com>...
> lilburne wrote:
> > Thomas Matthews wrote:
> 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.

-- 
GJD
0
deane_gavin (897)
2/20/2004 11:55:27 AM
Hi!

"Gavin Deane" <deane_gavin@hotmail.com> wrote in message
news:6d8002d0.0402200355.670a330f@posting.google.com...
>
> 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 -


0
rlankine2 (115)
2/20/2004 12:16:03 PM
> 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.


0
tonu (9)
2/20/2004 1:27:11 PM
lilburne wrote:
> 
> 
> Jeff Schwab wrote:
> 
>> Gavin Deane wrote:
>>
>>>
>>> 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.
>>
> 
> 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. :)

0
jeffplus (649)
2/20/2004 1:35:45 PM

Jeff Schwab wrote:

> lilburne wrote:
> 
>>
>>
>> Jeff Schwab wrote:
>>
>>> Gavin Deane wrote:
>>>
>>>>
>>>> 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.
>>>
>>
>> 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.

Actually I don't think it is a language issue per se. Rather its a 
design decision on what type gets returned from the standard container 
libraries. In this case the descision was that underflow in calculations 
concerning the size of containers, will not be dealt with by using the 
most natural expression form. We really aren't Babylonian's that can't 
conceive of negative values, we live in the 21st Century and are well 
versed in such numbers from our tax returns, and bank statements.


0
lilburne (87)
2/20/2004 3:13:36 PM
Gavin Deane wrote in
news:6d8002d0.0402200355.670a330f@posting.google.com: 

> Thomas Matthews <Thomas_MatthewsSpitsOnSpamBots@sbcglobal.net> wrote
> in message news:<lg9Zb.13674$yM3.11117@newssvr31.news.prodigy.com>... 
>> lilburne wrote:
>> > Thomas Matthews wrote:
>> 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.
> 

In a way it does, that's what modulo arithmatic does:

unsigned f( unsigned a, unsigned b )
{
  unsigned c = a - b;
}

Now we *know* that a == b + f(a, b), we don't get this property 
with signed int.

IOW If the programmer understands that they're doing arithmatic 
mod 2^n, then the result of 2U - 3U is just as meaningful as -1.
 
It also has the advantage that you don't have to worry about that 
pesky sign :).

Rob.
-- 
http://www.victim-prime.dsl.pipex.com/
0
rtw (385)
2/20/2004 3:50:42 PM
On Thu, 19 Feb 2004 20:46:09 GMT in comp.lang.c++, Thomas Matthews
<Thomas_MatthewsSpitsOnSpamBots@sbcglobal.net> was alleged to have
written:
>I believe you are assuming 32 bits per integer.
>Let us assume 8 bits per integer. 

int is required to be at least 16 bits.
But many people would be surprised to see it be less than 32.

If (x-y) is required to be non-negative, then the calculation of it is
preceded in your code with
   assert (x >= y);

So where's the problem?

0
source (1021)
2/20/2004 4:06:10 PM
> My point is that when a range is in the domain of positive
> integral values, one should use an unsigned data type.

Shouldn't have anything to do with range or domain.  If you are doing integer
math, use a signed type.

Thomas Matthews wrote:
> 
> lilburne wrote:
> > Thomas Matthews wrote:
> >
> >> 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?
> 
> 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.
> 
> >
> >> 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?
> 
> 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
0
Julie
2/20/2004 4:22:25 PM
"Gavin Deane" <deane_gavin@hotmail.com> wrote in message
news:6d8002d0.0402190340.159fcbc1@posting.google.com...
> lilburne <lilburne@godzilla.net> wrote in message
news:<c10lef$1cjr9a$1@ID-179504.news.uni-berlin.de>...
> > Thomas Matthews wrote:
> >
> > > 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.
> >

snip snip snippetty snip.

What we really need is a poll here to see the percentage who would like to
get rid of it (or just advocate not using it because
it can never be removed from the language now).
AND
a poll of java users to see how many wish they had it.

java is a more recent language and the designer didn't think it was worth
having.
Mind you he didn't do const either and I think he was wrong on that one.


0
nh002 (175)
2/20/2004 5:49:43 PM
In article <40360b32$1@news.infonet.ee>, T�nu Aas <tonu@ids.ee> wrote:
>> 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.

The problem wasn't unsigned vs. signed.  It was not checking inputs.
-- 
Mark Ping                     
emarkp@soda.CSUA.Berkeley.EDU 
0
emarkp (111)
2/20/2004 6:36:17 PM
Absolutely NO reason to get rid of it.  If you don't want it, globally define:

#define unsigned

or to be more specific

#define unsigned signed

And now unsigned types are effectively removed from your code.  No need to
change the language.

There are very valid reasons for unsigned, such as size and counts where
negative values are illogical.

Nick Hounsome wrote:
> 
> "Gavin Deane" <deane_gavin@hotmail.com> wrote in message
> news:6d8002d0.0402190340.159fcbc1@posting.google.com...
> > lilburne <lilburne@godzilla.net> wrote in message
> news:<c10lef$1cjr9a$1@ID-179504.news.uni-berlin.de>...
> > > Thomas Matthews wrote:
> > >
> > > > 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.
> > >
> 
> snip snip snippetty snip.
> 
> What we really need is a poll here to see the percentage who would like to
> get rid of it (or just advocate not using it because
> it can never be removed from the language now).
> AND
> a poll of java users to see how many wish they had it.
> 
> java is a more recent language and the designer didn't think it was worth
> having.
> Mind you he didn't do const either and I think he was wrong on that one.
0
Julie
2/20/2004 7:10:40 PM
In article <GMrZb.9334$YY6.2686@news-binary.blueyonder.co.uk>,
Nick Hounsome <nh002@blueyonder.co.uk> wrote:
>
>What we really need is a poll here to see the percentage who would like to
>get rid of it (or just advocate not using it because
>it can never be removed from the language now).
>AND
>a poll of java users to see how many wish they had it.

Totally useless.  Such a poll without a measure of competence of the
person answering the question would likely be misleading.
-- 
Mark Ping                     
emarkp@soda.CSUA.Berkeley.EDU 
0
emarkp (111)
2/20/2004 7:19:58 PM
Nick Hounsome wrote:

> What we really need is a poll here to see the percentage who would like to
> get rid of it (or just advocate not using it because
> it can never be removed from the language now).

I don't think anyone is seriously advocating the removal of 
unsigned from the language, because there are obviously 
cases were its use is worthwhile. What is unclear is whether 
the type should be prevelent in public interfaces, because 
you are more likely to encounter underflow with unsigned 
expressions than with signed expressions, and the extra bit 
is rarely useful.

NOTE: none of the above implies that unsigned should never 
be used in an interface, nor that there are no cases where 
the extra bit isn't useful.

0
lilburne3 (346)
2/20/2004 8:42:26 PM
Doesn't have anything to do with interfaces.  If the value being represented is
a count or size (or similar where the range is non-negative), it should be
unsigned; if it is a value to be used in arithmetic (or similar where the range
is positive and negative), it should be signed.

If you are doing arithmetic that requires at least nbits-1, you are using the
wrong type and should use the next larger size (exceptions exist, but are the
exception and not the norm).

I suspect that the main reasons that unsigned doesn't have more mass appeal is
because:

 - programmer is lazy, and doesn't want to type 'unsigned int', when in their
mind, 'int' will do just fine (even though it isn't the appropriate type).

 - programmer doesn't understand differences (or consequences) of
signed/unsigned types, so just uses int 'to be safe'.

 - someone else used int (when it should have been unsigned int, see reasons
above), and the programmer doesn't want to deal with signed/unsigned mismatch
warnings so just uses int as well (again, wrong type).

This thread wouldn't exist if we were all using the types properly.

lilburne wrote:
> 
> Nick Hounsome wrote:
> 
> > What we really need is a poll here to see the percentage who would like to
> > get rid of it (or just advocate not using it because
> > it can never be removed from the language now).
> 
> I don't think anyone is seriously advocating the removal of
> unsigned from the language, because there are obviously
> cases were its use is worthwhile. What is unclear is whether
> the type should be prevelent in public interfaces, because
> you are more likely to encounter underflow with unsigned
> expressions than with signed expressions, and the extra bit
> is rarely useful.
> 
> NOTE: none of the above implies that unsigned should never
> be used in an interface, nor that there are no cases where
> the extra bit isn't useful.
0
Julie
2/20/2004 9:45:16 PM
"Risto Lankinen" <rlankine@hotmail.com> wrote in message news:<7UmZb.9958$g4.201001@news2.nokia.com>...
> Hi!
> 
> "Gavin Deane" <deane_gavin@hotmail.com> wrote in message
> news:6d8002d0.0402200355.670a330f@posting.google.com...
> >
> > 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,

Absolutely. As I have said previously, whether you use signed or
unsigned, if this happens, you have a bug somewhere. Either way, it's
the same bug.

> 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),

I do :)

> 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!

Yes, that's all it is. And that's a special case. If you are using
unsigned in preference to signed because you know you will have values
above 2G-1, you are already into implementation specific details about
the range of the types. But special cases happen, which is why I never
said I wanted unsigned banned.

> 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).

It is not the numerical value I end up with that bothers me. 2 - 3 is
illustrative. The problem I have is that, in the world of arithmetic
that I have grown up with since before I ever saw a computer, the
result of subtracting a positive integer from another positive integer
is not, in general, positive.

Yes, I know how unsigned arithmetic works in C++. But I don't want to
bother with the extra workload of having to think about it, when there
is a signed type available that loses me nothing [*] and behaves the
same way as all integers have always behaved, since I first learnt
about them at school.

[*] outside of special cases like your example above.

-- 
GJD
0
deane_gavin (897)
2/20/2004 10:41:48 PM
>>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).
> 
> 
And how is the 2-3 pathological case any different from the (signed) 
pathological case of (2^31)-1 + 1 = -(2^31)?  You still have a 
pathological case.
0
no.spam9 (2339)
2/20/2004 11:18:53 PM
Julie J. wrote:
> Absolutely NO reason to get rid of it.  If you don't want it, globally define:
> 
> #define unsigned
> 
> or to be more specific
> 
> #define unsigned signed
> 
> And now unsigned types are effectively removed from your code.  No need to
> change the language.

But you are chaging default behavior.  Unexpected users reading the 
standard would be fairly pissed to see that there is no way of declaring 
unsigned types.
0
jorgeri (116)
2/20/2004 11:50:23 PM
In article <rQ%Yb.3$8n5.11688@news.ecrc.de>,
 Christian Engstrom <christian.engstrom@glindra.org> wrote:

> >> John Harrison wrote:
> >> 
> >> So has the time come for C++ to deprecate unsigned integral types?
> >>
> >
> > 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.

   So, you think that the following should be illegal?:

for(unsigned i = 0; i < 20; ++i)
{
   ;
}

0
clarkcox31 (44)
2/21/2004 3:20:02 AM
>
>    So, you think that the following should be illegal?:
>
> for(unsigned i = 0; i < 20; ++i)
> {
>    ;
> }

for(unsigned i = 0U; i < 20U; ++i)

Not too hard (but a bit tedious).

john


0
2/21/2004 8:31:21 AM
"Julie J." <unlisted@.> wrote in message news:40367FEC.9D389036@....
> Doesn't have anything to do with interfaces.  If the value being
represented is
> a count or size (or similar where the range is non-negative), it should be
> unsigned; if it is a value to be used in arithmetic (or similar where the
range
> is positive and negative), it should be signed.

Just about every count and size is used in an arithmetic expression
somewhere so
by your own argument they should be signed.

Even if they are not now there is no gaurantee that they wont be in future -
in particular it
is an implementation decision and it is desirable to design for future
enhancements hence
you appear to be arguing against yourself.

:-)


0
nh002 (175)
2/21/2004 12:41:07 PM
"Nick Hounsome" <nh002@blueyonder.co.uk> wrote
> What we really need is a poll here to see the percentage who would like to
> get rid of it (or just advocate not using it because
> it can never be removed from the language now).

A popular vote is completely irrelevant. Both the standard committee and the
compiler manufacturers are interested in the opinions of those who use C++ (and
therefore understand why unsigned exists), not in the irrational ramblings of
every Tom, Dick, and Harry who misses a feature from BASIC, Pascal, Java, etc.
because they didn't bother to learn C++ to an adequate level of proficiency.

> AND
> a poll of java users to see how many wish they had it.

If you had the slightest clue how little the C++ community gives a da*n about
what the Java community wishes they had or didn't have.

> java is a more recent language

Which only means it has no excuse for the abominations it unleashed on the poor
saps who migrated to it.

> and the designer didn't think it was worth having.

The designer (of Java) didn't think it was worth having pointers either. Or
performance. Or templates. Or contiguous storage of an object's sub-elements.
Java's design is centered around the attempt to stop idiots from doing stupid
things. The goal of C++ is to allow intelligent people to do intelligent things.
Pick your language.

This topic has drifted way into the absurd.

Claudio Puviani


0
puviani (290)
2/21/2004 3:33:11 PM
> Just about every count and size is used in an arithmetic expression
> somewhere so
> by your own argument they should be signed.

Could you please provide some evidence to back up your claim.  I don't feel
that your statement is true.

> Even if they are not now there is no gaurantee that they wont be in future -
> in particular it
> is an implementation decision and it is desirable to design for future
> enhancements hence
> you appear to be arguing against yourself.

This makes no sense.  My point is, and has been, use the proper type for the
situation.  You can't design for infinite future possibilities, however you can
design for the task at hand w/ an eye to the future.

Picking at my statements isn't the point of my response.  As I've mentioned,
use the proper type for the situation.  unsigned is a valid and proper type for
numerous situations, and therefore should be used over its signed counterpart.

Nick Hounsome wrote:
> 
> "Julie J." <unlisted@.> wrote in message news:40367FEC.9D389036@....
> > Doesn't have anything to do with interfaces.  If the value being
> represented is
> > a count or size (or similar where the range is non-negative), it should be
> > unsigned; if it is a value to be used in arithmetic (or similar where the
> range
> > is positive and negative), it should be signed.
> 
> Just about every count and size is used in an arithmetic expression
> somewhere so
> by your own argument they should be signed.
> 
> Even if they are not now there is no gaurantee that they wont be in future -
> in particular it
> is an implementation decision and it is desirable to design for future
> enhancements hence
> you appear to be arguing against yourself.
> 
> :-)
0
Julie
2/21/2004 5:06:50 PM
I was responding to the previous poster's request for a poll.

No need for a poll, if someone doesn't want unsigned in their code, they can
effectively remove it without changing the language.  I don't know what effect
on other users you are referring to.


Jorge Rivera wrote:
> 
> Julie J. wrote:
> > Absolutely NO reason to get rid of it.  If you don't want it, globally define:
> >
> > #define unsigned
> >
> > or to be more specific
> >
> > #define unsigned signed
> >
> > And now unsigned types are effectively removed from your code.  No need to
> > change the language.
> 
> But you are chaging default behavior.  Unexpected users reading the
> standard would be fairly pissed to see that there is no way of declaring
> unsigned types.
0
Julie
2/21/2004 5:10:13 PM
Rob Williscroft wrote:

> unsigned f( unsigned a, unsigned b )
> {
>   unsigned c = a - b;

     return c;

> }
> 
> Now we *know* that a == b + f(a, b), we don't get this property 
> with signed int.

0
jeffplus (649)
2/21/2004 11:15:15 PM
"John Harrison" <john_andronicus@hotmail.com> wrote in message
news:c0u9jg$1cioeb$1@ID-196037.news.uni-berlin.de...
>
> "P.J. Plauger" <pjp@dinkumware.com> wrote in message
> news:5sxYb.38766$1S1.14468@nwrddc01.gnilink.net...
> > "John Harrison" <john_andronicus@hotmail.com> wrote in message
> > news:c0u010$1beu6e$1@ID-196037.news.uni-berlin.de...
> >
> > > 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?
>
> 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.

And yet, you found them useful
    "I didn't say I don't have to do it, in fact writing a large integer
    library is one thing I have done (and yes I did use unsigned
    integers). I said its not something *many* people have to do."

Merely because you find unsigned to be fairly useless, doesn't make it so.
Especially since you did find 'em useful in at least one instance.
Could it be they're useful to other folks, too?
IIRC, you've said that
    "Well I'm not being entirely serious, but this issue is a particular
     bugbear of mine, and I thought the Windows source was a good
    example to back it up. I don't expect to get much agreement.
    (But one person agreeing with me would be nice). "

Found that one person, yet? (who agrees that unsigned should be removed? )

Dennis
>
> john
>
>



0
2/24/2004 2:40:14 PM

Dennis (Icarus) wrote:

> 
> Found that one person, yet? (who agrees that unsigned should be removed? )
> 

 From our coding standard:

   "Avoid the use of unsigned int.
    An unsigned argument may be passed a negative number and C++ will
    silently convert it to a large positive value. Similarly if
    arithmetic is performed on an unsigned value returned from a
    function, the result may unexpectedly be a large positive value."

this is a direct reversal of an earlier policy to use unsigned where the 
value would never be negative. The history of how the change came about 
is a sorry litturgy of code breaking, exhibiting unintended behaviour, 
causing abiguity problems.

So whilst we don't remove it all together, anyone that does use it must 
"Be prepared to defend violations of recommendations."

now you might like to ponder why it is, if unsigned is so useful in the 
public interface, that in <math> there is:

    long abs(long x);

rather than:

    unsigned long abs(long x);



0
lilburne (87)
2/24/2004 3:39:59 PM
abs is a math function.

signed integers should be used for the storage of values that are primarily
used in arithmetic situations.



lilburne wrote:
> 
> Dennis (Icarus) wrote:
> 
> >
> > Found that one person, yet? (who agrees that unsigned should be removed? )
> >
> 
>  From our coding standard:
> 
>    "Avoid the use of unsigned int.
>     An unsigned argument may be passed a negative number and C++ will
>     silently convert it to a large positive value. Similarly if
>     arithmetic is performed on an unsigned value returned from a
>     function, the result may unexpectedly be a large positive value."
> 
> this is a direct reversal of an earlier policy to use unsigned where the
> value would never be negative. The history of how the change came about
> is a sorry litturgy of code breaking, exhibiting unintended behaviour,
> causing abiguity problems.
> 
> So whilst we don't remove it all together, anyone that does use it must
> "Be prepared to defend violations of recommendations."
> 
> now you might like to ponder why it is, if unsigned is so useful in the
> public interface, that in <math> there is:
> 
>     long abs(long x);
> 
> rather than:
> 
>     unsigned long abs(long x);
0
Julie
2/24/2004 4:02:25 PM
"Julie J." <unlisted@.> wrote in message news:403B7591.7A05B64D@....
> abs is a math function.
>
> signed integers should be used for the storage of values that are
primarily
> used in arithmetic situations.
>

I see you've watered down your criteria from last time I replied to you but
my argument still stands:
They might not be PRIMARILY be used in arithmetic situations now but they
might in the future.
Consequently maintainability/enhancability requires that you do not use
unsigned in the interface.
Having dispensed with unsigned in the interface it is only asking for
trouble to use it in the implementation.

Furthermore, how much arithmetic do you have to do on an integer for it to
be PRIMARILY used in arithmetic
situations?

>
>
> lilburne wrote:
> >
> > Dennis (Icarus) wrote:
> >
> > >
> > > Found that one person, yet? (who agrees that unsigned should be
removed? )
> > >
> >
> >  From our coding standard:
> >
> >    "Avoid the use of unsigned int.
> >     An unsigned argument may be passed a negative number and C++ will
> >     silently convert it to a large positive value. Similarly if
> >     arithmetic is performed on an unsigned value returned from a
> >     function, the result may unexpectedly be a large positive value."
> >
> > this is a direct reversal of an earlier policy to use unsigned where the
> > value would never be negative. The history of how the change came about
> > is a sorry litturgy of code breaking, exhibiting unintended behaviour,
> > causing abiguity problems.
> >
> > So whilst we don't remove it all together, anyone that does use it must
> > "Be prepared to defend violations of recommendations."
> >
> > now you might like to ponder why it is, if unsigned is so useful in the
> > public interface, that in <math> there is:
> >
> >     long abs(long x);
> >
> > rather than:
> >
> >     unsigned long abs(long x);


0
nh002 (175)
2/24/2004 5:13:28 PM
"Nick Hounsome" <nh002@blueyonder.co.uk> wrote in message
news:OCL_b.8697$ie6.3308@news-binary.blueyonder.co.uk...

> Consequently maintainability/enhancability requires that you do not use
> unsigned in the interface.
> Having dispensed with unsigned in the interface it is only asking for
> trouble to use it in the implementation.

Uh, no. We use unsigned arithmetic in the implementation of our libraries
all the time, to *avoid* trouble. With it we can model modulus arithmetic,
non-negative arithmetic, and twos complement arithmetic, all with no fear
of undefined behavior due to overflows. I'm inclined to agree that mixing
signed and unsigned arithmetic is error prone, and hence worth avoiding
in interfaces used by civilians. But don't tell us implementors not to
use the best tools we have for getting the job done properly.

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


0
pjp (713)
2/24/2004 5:20:48 PM
Unsigned *should* be used in the interface.

would you prefer

void * allocate(signed int block_size);

?

I greatly prefer

void * allocate(unsigned int block_size);

and it is much more self-documenting.

Nick Hounsome wrote:
> 
> "Julie J." <unlisted@.> wrote in message news:403B7591.7A05B64D@....
> > abs is a math function.
> >
> > signed integers should be used for the storage of values that are
> primarily
> > used in arithmetic situations.
> >
> 
> I see you've watered down your criteria from last time I replied to you but
> my argument still stands:
> They might not be PRIMARILY be used in arithmetic situations now but they
> might in the future.
> Consequently maintainability/enhancability requires that you do not use
> unsigned in the interface.
> Having dispensed with unsigned in the interface it is only asking for
> trouble to use it in the implementation.
> 
> Furthermore, how much arithmetic do you have to do on an integer for it to
> be PRIMARILY used in arithmetic
> situations?
> 
> >
> >
> > lilburne wrote:
> > >
> > > Dennis (Icarus) wrote:
> > >
> > > >
> > > > Found that one person, yet? (who agrees that unsigned should be
> removed? )
> > > >
> > >
> > >  From our coding standard:
> > >
> > >    "Avoid the use of unsigned int.
> > >     An unsigned argument may be passed a negative number and C++ will
> > >     silently convert it to a large positive value. Similarly if
> > >     arithmetic is performed on an unsigned value returned from a
> > >     function, the result may unexpectedly be a large positive value."
> > >
> > > this is a direct reversal of an earlier policy to use unsigned where the
> > > value would never be negative. The history of how the change came about
> > > is a sorry litturgy of code breaking, exhibiting unintended behaviour,
> > > causing abiguity problems.
> > >
> > > So whilst we don't remove it all together, anyone that does use it must
> > > "Be prepared to defend violations of recommendations."
> > >
> > > now you might like to ponder why it is, if unsigned is so useful in the
> > > public interface, that in <math> there is:
> > >
> > >     long abs(long x);
> > >
> > > rather than:
> > >
> > >     unsigned long abs(long x);
0
Julie
2/24/2004 6:03:20 PM
P.J. Plauger wrote:

> "Nick Hounsome" <nh002@blueyonder.co.uk> wrote in message
> news:OCL_b.8697$ie6.3308@news-binary.blueyonder.co.uk...
> 
> 
>>Consequently maintainability/enhancability requires that you do not use
>>unsigned in the interface.
>>Having dispensed with unsigned in the interface it is only asking for
>>trouble to use it in the implementation.
> 
> 
> Uh, no. We use unsigned arithmetic in the implementation of our libraries
> all the time, to *avoid* trouble. With it we can model modulus arithmetic,
> non-negative arithmetic, and twos complement arithmetic, all with no fear
> of undefined behavior due to overflows. I'm inclined to agree that mixing
> signed and unsigned arithmetic is error prone, and hence worth avoiding
> in interfaces used by civilians. But don't tell us implementors not to
> use the best tools we have for getting the job done properly.
> 

I think that the right approach. Isolating unsigned within 
an implementation is fine. Its when it leaks into the public 
interfaces that problems can and do occur.

0
lilburne3 (346)
2/24/2004 7:58:57 PM
"lilburne" <lilburne@godzilla.com> wrote in message
news:c1fr7u$1ickn1$1@ID-179504.news.uni-berlin.de...
>
>
> Dennis (Icarus) wrote:
>
> >
> > Found that one person, yet? (who agrees that unsigned should be
removed? )
> >
>
>  From our coding standard:
>
>    "Avoid the use of unsigned int.
>     An unsigned argument may be passed a negative number and C++ will
>     silently convert it to a large positive value. Similarly if
>     arithmetic is performed on an unsigned value returned from a
>     function, the result may unexpectedly be a large positive value."
>
> this is a direct reversal of an earlier policy to use unsigned where the
> value would never be negative. The history of how the change came about
> is a sorry litturgy of code breaking, exhibiting unintended behaviour,
> causing abiguity problems.
>
> So whilst we don't remove it all together, anyone that does use it must
> "Be prepared to defend violations of recommendations."

So you choose not to use it. Fine & dandy.
Think it should be removed from the language?

Or would you just want to insure that unsigned can't be used as parameters?

Or do you find it useful in some circumstances, problematic if not used
carefully and, givne past history, you want to insure that proper care is
used?

>
> now you might like to ponder why it is, if unsigned is so useful in the
> public interface, that in <math> there is:
>
>     long abs(long x);
>
> rather than:
>
>     unsigned long abs(long x);
>

Sure, and you can take a look at how size_t is defined.

:-)

Dennis
>
>


0
2/25/2004 5:00:11 AM
In article <guWdnbig2qJ4JandRVn-ug@comcast.com>,
Jeff Schwab  <jeffplus@comcast.net> wrote:
>>>
>>>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.
>>
>
>Your complaint, then, is about the fact that integers overflow.  It has
>nothing to do with whether the types involved are signed.

If you think that C/C++ unsigned integers can overflow, you have
a wrong conceptual view of them.
The correct view is
  it is now 18:00 hours
  7 hours later :  1:00 hours
  23 hours earlier : 19:00 hours
  25 hours later : 19:00 hours
The sign (P.M or A.M) is totally irrelevant, and, yes, you can
add or subtract any value you want, even if it doesn't fit in an
unsigned int.

If I were to make a c-compiler the following would trap
on implementation with 16 bits int's :
signed int i;
unsigned int u=0xFFFF;
   i=u; /* Overflow trap! */

Nowadays you could add a (reinterpret_cast) to make at least the
intention clear.

While we are at it we could add traps for any bit-wise operations
on signed ints.

Head when the compiler says
        WARNING: bitwise operation on signed values.

C is an unsafe language. Most warnings are actually errors.

>
>#include <iostream>
>#include <limits>
>
>int main( )
>{
>      signed s = std::numeric_limits< signed >::max( );
>
>      std::cout << s << " + 1 = " << ( s + 1 ) << " ?\n";
                 ^^
                 Don't use bit operators on signed values.
                 You never need/want to do that.
>}

Groetjes Albert
-- 
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
        One man-hour to invent,
                One man-week to implement,
                        One lawyer-year to patent.
0
albert37 (3001)
2/25/2004 4:02:36 PM
"Julie J." <unlisted@.> wrote in message news:403B91E8.33EBA2E5@....
> Unsigned *should* be used in the interface.
>
> would you prefer
>
> void * allocate(signed int block_size);
>
> ?
>
> I greatly prefer
>
> void * allocate(unsigned int block_size);
>
> and it is much more self-documenting.

If you are just going to say allocate(42) fine but what about allocate(s-10)
where s <10?

Do you prefer:

void* allocate(int size)
{
    if( size < 0 ) throw domain_error("its negative stupid!");
    ...
}

or void* allocate(unsigned size)
{
    // no way of checking
}

I'm only arguing your own point here - YOU said to use int when used in
arithmetic
expressions and you don't know when your clients are going to use arithmetic
expressions.

>
> Nick Hounsome wrote:
> >
> > "Julie J." <unlisted@.> wrote in message news:403B7591.7A05B64D@....
> > > abs is a math function.
> > >
> > > signed integers should be used for the storage of values that are
> > primarily
> > > used in arithmetic situations.
> > >
> >
> > I see you've watered down your criteria from last time I replied to you
but
> > my argument still stands:
> > They might not be PRIMARILY be used in arithmetic situations now but
they
> > might in the future.
> > Consequently maintainability/enhancability requires that you do not use
> > unsigned in the interface.
> > Having dispensed with unsigned in the interface it is only asking for
> > trouble to use it in the implementation.
> >
> > Furthermore, how much arithmetic do you have to do on an integer for it
to
> > be PRIMARILY used in arithmetic
> > situations?
> >
> > >
> > >
> > > lilburne wrote:
> > > >
> > > > Dennis (Icarus) wrote:
> > > >
> > > > >
> > > > > Found that one person, yet? (who agrees that unsigned should be
> > removed? )
> > > > >
> > > >
> > > >  From our coding standard:
> > > >
> > > >    "Avoid the use of unsigned int.
> > > >     An unsigned argument may be passed a negative number and C++
will
> > > >     silently convert it to a large positive value. Similarly if
> > > >     arithmetic is performed on an unsigned value returned from a
> > > >     function, the result may unexpectedly be a large positive
value."
> > > >
> > > > this is a direct reversal of an earlier policy to use unsigned where
the
> > > > value would never be negative. The history of how the change came
about
> > > > is a sorry litturgy of code breaking, exhibiting unintended
behaviour,
> > > > causing abiguity problems.
> > > >
> > > > So whilst we don't remove it all together, anyone that does use it
must
> > > > "Be prepared to defend violations of recommendations."
> > > >
> > > > now you might like to ponder why it is, if unsigned is so useful in
the
> > > > public interface, that in <math> there is:
> > > >
> > > >     long abs(long x);
> > > >
> > > > rather than:
> > > >
> > > >     unsigned long abs(long x);


0
nh002 (175)
2/25/2004 4:18:26 PM
In article <4032B794.DAE61B1@infowest.com>,
Bret Pehrson  <bret@infowest.com> wrote:
>unsigned integers are commonly used to declare 'count' or 'index' or 'size'*
>type variables that will never contain negative values.

This is not correct use however. This usage is not in
correspondence with the conceptual meaning of unsigned. If you
have an array of length 10, do you then only use unsigned char
to index into the array? Unsigned is proper for circular
arithmetic, like a time stamp counter that goes on and on, and
for bit fields. Note that in algol 68 ``signed int'' is called
``int'' and ``unsigned int'' called ``bytes''. Then it comes as
a bit of a surprise that you could calculate somewhat with those
``bytes''. The naming of C makes only sense for people who
started their career in assembly programming, switching to a
high level language after three years.

It is an incidental consequence of the lowly ancestry of c++
that arrays cannot be like algol a[2000:2004] or
juliusyears[-41,23] .

If you want typing for your indices by all means do
typedef int INDEX_FOR_PATH_STRINGS;
and then have an ASSERT_IFPS() macro.
(If you want do it really well, you might consider switching to
ADA.)

Using unsigned for an index only serves the unintended purpose
of preventing any problems with negative values to be signaled.
An other poster has elaborated on this beautifully, stating
their new coding standards.

>signed integers should be used for ingeger math*.
>
>Shouldn't mix the types w/ the purpose, however it does happen.  When writing
>self-documenting code, you should use the type that applies.
>
>Deprecating unsigned is essentially saying that the former reason has no
>perceived value in the language.

The type ``bytes'' or in c-parlance ``unsigned int'' for
manipulating raw machine words is invaluable for those of us
writing compilers and other system programs. Those who are not,
should be careful with their comment. See also the comment of
Plauger.

>(*other reasons exist, that are not delineated here.)
>
>John Harrison wrote:
>>
>> 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?

Hell no. The time has come for you to not use them, because you
have no business using them. Glad you discovered that. You are
not in writing compilers, assemblers, or high performance
bit-field codes, bignum packages.

>>
>> john
>
>--
>Bret Pehrson
>mailto:bret@infowest.com
>NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl>>


--
-- 
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
        One man-hour to invent,
                One man-week to implement,
                        One lawyer-year to patent.
0
albert37 (3001)
2/25/2004 4:35:42 PM
In article <7xNYb.37095$zX7.1751@newssvr33.news.prodigy.com>,
Thomas Matthews  <Thomas_MatthewsHatesSpamBots@sbcglobal.net> wrote:
<SNIP?
>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.

Borland is right. You are wrong. See below.

>
>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?).

Do you really believe that where you make a program
error that results in negative breaths, your patient
is saved by using a type unsigned?
Warn me if you write such an application, so that
I can find an other hospital.

>I also discussed that signed integers require at
>least one bit for the sign, thus loosing one bit.

Big deal.

>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.
Appropriate use. The reason is that you look at the raw
bits here.

>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?
I agree with this.

>
>--
>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
>


--
-- 
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
        One man-hour to invent,
                One man-week to implement,
                        One lawyer-year to patent.
0
albert37 (3001)
2/25/2004 4:44:02 PM
"Nick Hounsome" <nh002@blueyonder.co.uk> wrote
>
> "Julie J." <unlisted@.> wrote in message news:403B91E8.33EBA2E5@....
> > Unsigned *should* be used in the interface.
> >
> > would you prefer
> >
> > void * allocate(signed int block_size);
> >
> > ?
> >
> > I greatly prefer
> >
> > void * allocate(unsigned int block_size);
> >
> > and it is much more self-documenting.
>
> If you are just going to say allocate(42) fine but what about allocate(s-10)
> where s <10?

If a programmer is stupid enough to write code like that, not only should he/she
be allowed to shoot him/herself in the foot, we should all pitch in to buy the
bullets. Anyone who can walk and chew gum at the same time will know that
calling allocate with a negative number is senseless and will test the
expression before calling the function. Programmers that don't start getting
that simple notion after a few days on the job need to be fired, not coddled.

Claudio Puviani


0
puviani (290)
2/25/2004 5:53:29 PM
All I'm saying w/ unsigned is that the function is *not* going to check for
negative values.  It is the callers responsibility to ensure that the input is
valid.  So, if they send in -5 for a size (converted to unsigned 42-billion or
something), that is what would attempted to be allocated.

Now I realize that in this case there will probably be some arithmetic on the
input (such as quantity * block_size), but the primary intention of the
variable is to hold size-related information.

My comments have not intended to be 100% must-obey-rules, just guidelines for
the use of signed/unsigned integers.

Finally, my responses to the various postings on this topic have been merely to
illustrate that there are *multiple* disparate uses for integers.  Not everyone
uses integers for math in the positive and negative domains.

I just wish people would take into account other's needs and experiences before
making such recommendations about removing language features, simply based on
'I don't have a need for it, so no one should...'.

The *entire* 'problem' surrounding unsigned/signed ints and math/conversion
overflow has to do with:

 - no or a lack of coding standards
 - no or insufficient code reviews
 - no or insufficient unit testing
 - no or insufficient documenation
 - etc.

*not* because of language constructs.

The above items get a lot of lip service in the trade rags and books, but in
reality, how integrated are those items in everyday programming and
development?  Definitely not as much as it should.

Later

Nick Hounsome wrote:
> 
> "Julie J." <unlisted@.> wrote in message news:403B91E8.33EBA2E5@....
> > Unsigned *should* be used in the interface.
> >
> > would you prefer
> >
> > void * allocate(signed int block_size);
> >
> > ?
> >
> > I greatly prefer
> >
> > void * allocate(unsigned int block_size);
> >
> > and it is much more self-documenting.
> 
> If you are just going to say allocate(42) fine but what about allocate(s-10)
> where s <10?
> 
> Do you prefer:
> 
> void* allocate(int size)
> {
>     if( size < 0 ) throw domain_error("its negative stupid!");
>     ...
> }
> 
> or void* allocate(unsigned size)
> {
>     // no way of checking
> }
> 
> I'm only arguing your own point here - YOU said to use int when used in
> arithmetic
> expressions and you don't know when your clients are going to use arithmetic
> expressions.
> 
> >
> > Nick Hounsome wrote:
> > >
> > > "Julie J." <unlisted@.> wrote in message news:403B7591.7A05B64D@....
> > > > abs is a math function.
> > > >
> > > > signed integers should be used for the storage of values that are
> > > primarily
> > > > used in arithmetic situations.
> > > >
> > >
> > > I see you've watered down your criteria from last time I replied to you
> but
> > > my argument still stands:
> > > They might not be PRIMARILY be used in arithmetic situations now but
> they
> > > might in the future.
> > > Consequently maintainability/enhancability requires that you do not use
> > > unsigned in the interface.
> > > Having dispensed with unsigned in the interface it is only asking for
> > > trouble to use it in the implementation.
> > >
> > > Furthermore, how much arithmetic do you have to do on an integer for it
> to
> > > be PRIMARILY used in arithmetic
> > > situations?
> > >
> > > >
> > > >
> > > > lilburne wrote:
> > > > >
> > > > > Dennis (Icarus) wrote:
> > > > >
> > > > > >
> > > > > > Found that one person, yet? (who agrees that unsigned should be
> > > removed? )
> > > > > >
> > > > >
> > > > >  From our coding standard:
> > > > >
> > > > >    "Avoid the use of unsigned int.
> > > > >     An unsigned argument may be passed a negative number and C++
> will
> > > > >     silently convert it to a large positive value. Similarly if
> > > > >     arithmetic is performed on an unsigned value returned from a
> > > > >     function, the result may unexpectedly be a large positive
> value."
> > > > >
> > > > > this is a direct reversal of an earlier policy to use unsigned where
> the
> > > > > value would never be negative. The history of how the change came
> about
> > > > > is a sorry litturgy of code breaking, exhibiting unintended
> behaviour,
> > > > > causing abiguity problems.
> > > > >
> > > > > So whilst we don't remove it all together, anyone that does use it
> must
> > > > > "Be prepared to defend violations of recommendations."
> > > > >
> > > > > now you might like to ponder why it is, if unsigned is so useful in
> the
> > > > > public interface, that in <math> there is:
> > > > >
> > > > >     long abs(long x);
> > > > >
> > > > > rather than:
> > > > >
> > > > >     unsigned long abs(long x);
0
Julie
2/25/2004 7:03:06 PM
"Albert van der Horst" <albert@spenarnc.xs4all.nl> wrote in message
news:HtnFtF.uH.1.spenarn@spenarnc.xs4all.nl...
<snip>
>
> >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?
> I agree with this.

Yep - how many other languages have an "obfuscated code" contest? :-)

Dennis

>
> >
> >--
> >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
> >
>
>
> --
> -- 
> Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
>         One man-hour to invent,
>                 One man-week to implement,
>                         One lawyer-year to patent.


0
2/26/2004 2:25:58 AM
"Claudio Puviani" <puviani@hotmail.com> wrote in message
news:ti5%b.21246$M8.1610881@news4.srv.hcvlny.cv.net...
> "Nick Hounsome" <nh002@blueyonder.co.uk> wrote
> >
> > "Julie J." <unlisted@.> wrote in message news:403B91E8.33EBA2E5@....
> > > Unsigned *should* be used in the interface.
> > >
> > > would you prefer
> > >
> > > void * allocate(signed int block_size);
> > >
> > > ?
> > >
> > > I greatly prefer
> > >
> > > void * allocate(unsigned int block_size);
> > >
> > > and it is much more self-documenting.
> >
> > If you are just going to say allocate(42) fine but what about
allocate(s-10)
> > where s <10?
>
> If a programmer is stupid enough to write code like that, not only should
he/she
> be allowed to shoot him/herself in the foot, we should all pitch in to buy
the
> bullets. Anyone who can walk and chew gum at the same time will know that
> calling allocate with a negative number is senseless and will test the
> expression before calling the function. Programmers that don't start
getting
> that simple notion after a few days on the job need to be fired, not
coddled.
>
> Claudio Puviani

There are 3 places to check arguments to a function:
1. in the called function - 1 instance of the checking code exists
2. in the calling functions - this leads to unreadable code and enormous
code
    bloat because a large number of instances of checking code exist many of
    which may be wrong.

You seem to be advocating 2 over 1 - I think it is you that should be fired.

The only time you should normally validate arguments before calling a
function is when
dealing with user/externally supplied input. That is what runtime_error and
similar exceptions
exist for.

By your argument vector::at is unnecessary!




0
nh002 (175)
2/26/2004 7:18:51 AM
"Julie J." <unlisted@.> wrote in message news:403CF16A.6B529FE2@....
> All I'm saying w/ unsigned is that the function is *not* going to check
for
> negative values.  It is the callers responsibility to ensure that the
input is
> valid.  So, if they send in -5 for a size (converted to unsigned
42-billion or
> something), that is what would attempted to be allocated.

I've covered this in another post. While I agree that the caller should try
to
be sensible the best place to check args in general is in the callee as the
alternative leads to unmaintainable code bloat here.

>
> Now I realize that in this case there will probably be some arithmetic on
the
> input (such as quantity * block_size), but the primary intention of the
> variable is to hold size-related information.

I do see what you mean but I insist that whatever the primary intention is,
the reality is tht it will frequently be called with an expression.
As for being self documenting that is just a red herring - if you leave out
unsigned can you come up with any plausible thought process by which
somebody is going to think it is ok to call a function called allocate with
a negative number?

The other problem with the self documenting argument is that you need
to read the documentation to know the arg is unsigned anyway.

Yet another argument against is that the compiler may well give you
a spurious warning for allocate(42) (passing signed to unsigned)
but will say nothing about a genuine problem: allocate((size_t)3-(size_t)42)

>
> My comments have not intended to be 100% must-obey-rules, just guidelines
for
> the use of signed/unsigned integers.

I cannot accept them as guidelines because of the woolyness of the word
"primarily"
in your definition.

>
> Finally, my responses to the various postings on this topic have been
merely to
> illustrate that there are *multiple* disparate uses for integers.  Not
everyone
> uses integers for math in the positive and negative domains.
>
> I just wish people would take into account other's needs and experiences
before
> making such recommendations about removing language features, simply based
on
> 'I don't have a need for it, so no one should...'.

I have never seriously advocating removing or even not using unsigned except
as
formal parameters.

>
> The *entire* 'problem' surrounding unsigned/signed ints and
math/conversion
> overflow has to do with:
>
>  - no or a lack of coding standards

Personally I think that there are too many coding standards and most are
written by people who know less than me.

>  - no or insufficient code reviews

That would go top of my list. Although I would tend to put this sort of
thing down as
nit-picking.

>  - no or insufficient unit testing
>  - no or insufficient documenation
>  - etc.

I couldn't agree more

>
> *not* because of language constructs.
>
> The above items get a lot of lip service in the trade rags and books, but
in
> reality, how integrated are those items in everyday programming and
> development?  Definitely not as much as it should.
>
> Later
>
> Nick Hounsome wrote:
> >
> > "Julie J." <unlisted@.> wrote in message news:403B91E8.33EBA2E5@....
> > > Unsigned *should* be used in the interface.
> > >
> > > would you prefer
> > >
> > > void * allocate(signed int block_size);
> > >
> > > ?
> > >
> > > I greatly prefer
> > >
> > > void * allocate(unsigned int block_size);
> > >
> > > and it is much more self-documenting.
> >
> > If you are just going to say allocate(42) fine but what about
allocate(s-10)
> > where s <10?
> >
> > Do you prefer:
> >
> > void* allocate(int size)
> > {
> >     if( size < 0 ) throw domain_error("its negative stupid!");
> >     ...
> > }
> >
> > or void* allocate(unsigned size)
> > {
> >     // no way of checking
> > }
> >
> > I'm only arguing your own point here - YOU said to use int when used in
> > arithmetic
> > expressions and you don't know when your clients are going to use
arithmetic
> > expressions.
> >
> > >
> > > Nick Hounsome wrote:
> > > >
> > > > "Julie J." <unlisted@.> wrote in message news:403B7591.7A05B64D@....
> > > > > abs is a math function.
> > > > >
> > > > > signed integers should be used for the storage of values that are
> > > > primarily
> > > > > used in arithmetic situations.
> > > > >
> > > >
> > > > I see you've watered down your criteria from last time I replied to
you
> > but
> > > > my argument still stands:
> > > > They might not be PRIMARILY be used in arithmetic situations now but
> > they
> > > > might in the future.
> > > > Consequently maintainability/enhancability requires that you do not
use
> > > > unsigned in the interface.
> > > > Having dispensed with unsigned in the interface it is only asking
for
> > > > trouble to use it in the implementation.
> > > >
> > > > Furthermore, how much arithmetic do you have to do on an integer for
it
> > to
> > > > be PRIMARILY used in arithmetic
> > > > situations?
> > > >
> > > > >
> > > > >
> > > > > lilburne wrote:
> > > > > >
> > > > > > Dennis (Icarus) wrote:
> > > > > >
> > > > > > >
> > > > > > > Found that one person, yet? (who agrees that unsigned should
be
> > > > removed? )
> > > > > > >
> > > > > >
> > > > > >  From our coding standard:
> > > > > >
> > > > > >    "Avoid the use of unsigned int.
> > > > > >     An unsigned argument may be passed a negative number and C++
> > will
> > > > > >     silently convert it to a large positive value. Similarly if
> > > > > >     arithmetic is performed on an unsigned value returned from a
> > > > > >     function, the result may unexpectedly be a large positive
> > value."
> > > > > >
> > > > > > this is a direct reversal of an earlier policy to use unsigned
where
> > the
> > > > > > value would never be negative. The history of how the change
came
> > about
> > > > > > is a sorry litturgy of code breaking, exhibiting unintended
> > behaviour,
> > > > > > causing abiguity problems.
> > > > > >
> > > > > > So whilst we don't remove it all together, anyone that does use
it
> > must
> > > > > > "Be prepared to defend violations of recommendations."
> > > > > >
> > > > > > now you might like to ponder why it is, if unsigned is so useful
in
> > the
> > > > > > public interface, that in <math> there is:
> > > > > >
> > > > > >     long abs(long x);
> > > > > >
> > > > > > rather than:
> > > > > >
> > > > > >     unsigned long abs(long x);


0
nh002 (175)
2/26/2004 7:33:05 AM
"Nick Hounsome" <nh002@blueyonder.co.uk> wrote
> > > If you are just going to say allocate(42) fine but what about
> > > allocate(s-10) where s <10?
> >
> > If a programmer is stupid enough to write code like that, not only should
> > he/she be allowed to shoot him/herself in the foot, we should all pitch in
to buy
> > the bullets.
>
> There are 3 places to check arguments to a function:
> 1. in the called function - 1 instance of the checking code exists
> 2. in the calling functions - this leads to unreadable code and enormous
> code
>     bloat because a large number of instances of checking code exist many of
>     which may be wrong.
>
> You seem to be advocating 2 over 1 - I think it is you that should be fired.
>
> The only time you should normally validate arguments before calling a
> function is when
> dealing with user/externally supplied input. That is what runtime_error and
> similar exceptions
> exist for.

You're missing a more fundamental point. The code in question (the one that
passes a negative value to an allocating function) should never have been
written in such a way that a negative value is possible. Testing for a
negative -- whether inside or outside the function -- is just a band-aid over a
design flaw that should never have been there. Defensive programming of the type
you advocate may be useful if you're dealing with beginners in C++, but it's
redundant (and unnecessarily expensive) when you're dealing with experienced
programmers.

> By your argument vector::at is unnecessary!

It's completely unnecessary and a performance hurdle. vector::at is
sugar-coating for careless programmers. It could be removed and std::vector
would still be completely usable. Don't mistake convenience functions for
necessary ones.


0
puviani (290)
2/26/2004 7:40:48 AM
"Nick Hounsome" <nh002@blueyonder.co.uk> wrote in
news:g5h%b.4564$IW1.3233@news-binary.blueyonder.co.uk: 

> 
> "Claudio Puviani" <puviani@hotmail.com> wrote in message
> news:ti5%b.21246$M8.1610881@news4.srv.hcvlny.cv.net...
>> "Nick Hounsome" <nh002@blueyonder.co.uk> wrote
>> >
>> > "Julie J." <unlisted@.> wrote in message
>> > news:403B91E8.33EBA2E5@.... 
>> > > Unsigned *should* be used in the interface.
>> > >
>> > > would you prefer
>> > >
>> > > void * allocate(signed int block_size);
>> > >
>> > > ?
>> > >
>> > > I greatly prefer
>> > >
>> > > void * allocate(unsigned int block_size);
>> > >
>> > > and it is much more self-documenting.
>> >
>> > If you are just going to say allocate(42) fine but what about
> allocate(s-10)
>> > where s <10?
>>
>> If a programmer is stupid enough to write code like that, not only
>> should 
> he/she
>> be allowed to shoot him/herself in the foot, we should all pitch in
>> to buy 
> the
>> bullets. Anyone who can walk and chew gum at the same time will know
>> that calling allocate with a negative number is senseless and will
>> test the expression before calling the function. Programmers that
>> don't start 
> getting
>> that simple notion after a few days on the job need to be fired, not
> coddled.
>>
>> Claudio Puviani
> 
> There are 3 places to check arguments to a function:
> 1. in the called function - 1 instance of the checking code exists
> 2. in the calling functions - this leads to unreadable code and
> enormous code
>     bloat because a large number of instances of checking code exist
>     many of which may be wrong.

There are 3 types of mathematicians in this world:
1) Those that can count
2) Those that can't.

:)

> You seem to be advocating 2 over 1 - I think it is you that should be
> fired. 

I advocate the 3rd possibility that you left out:
3. At compile time (where possible, such as negative numbers to an 
unsigned parameter).

0
nntpspam (752)
2/26/2004 5:06:59 PM
"Andre Kostur" <nntpspam@kostur.net> wrote
> There are 3 types of mathematicians in this world:
> 1) Those that can count
> 2) Those that can't.
>
> :)

Actually, there are 10 kinds of people in this world: those who can read binary
and those who can't. ;-)

Claudio Puviani


0
puviani (290)
2/26/2004 5:45:25 PM
(Thread resurrected from the ashes!)

Another valid reason for the unsigned type:

Numeric identifiers

"Julie J." wrote:
> 
> All I'm saying w/ unsigned is that the function is *not* going to check for
> negative values.  It is the callers responsibility to ensure that the input is
> valid.  So, if they send in -5 for a size (converted to unsigned 42-billion or
> something), that is what would attempted to be allocated.
> 
> Now I realize that in this case there will probably be some arithmetic on the
> input (such as quantity * block_size), but the primary intention of the
> variable is to hold size-related information.
> 
> My comments have not intended to be 100% must-obey-rules, just guidelines for
> the use of signed/unsigned integers.
> 
> Finally, my responses to the various postings on this topic have been merely to
> illustrate that there are *multiple* disparate uses for integers.  Not everyone
> uses integers for math in the positive and negative domains.
> 
> I just wish people would take into account other's needs and experiences before
> making such recommendations about removing language features, simply based on
> 'I don't have a need for it, so no one should...'.
> 
> The *entire* 'problem' surrounding unsigned/signed ints and math/conversion
> overflow has to do with:
> 
>  - no or a lack of coding standards
>  - no or insufficient code reviews
>  - no or insufficient unit testing
>  - no or insufficient documenation
>  - etc.
> 
> *not* because of language constructs.
> 
> The above items get a lot of lip service in the trade rags and books, but in
> reality, how integrated are those items in everyday programming and
> development?  Definitely not as much as it should.
> 
> Later
> 
> Nick Hounsome wrote:
> >
> > "Julie J." <unlisted@.> wrote in message news:403B91E8.33EBA2E5@....
> > > Unsigned *should* be used in the interface.
> > >
> > > would you prefer
> > >
> > > void * allocate(signed int block_size);
> > >
> > > ?
> > >
> > > I greatly prefer
> > >
> > > void * allocate(unsigned int block_size);
> > >
> > > and it is much more self-documenting.
> >
> > If you are just going to say allocate(42) fine but what about allocate(s-10)
> > where s <10?
> >
> > Do you prefer:
> >
> > void* allocate(int size)
> > {
> >     if( size < 0 ) throw domain_error("its negative stupid!");
> >     ...
> > }
> >
> > or void* allocate(unsigned size)
> > {
> >     // no way of checking
> > }
> >
> > I'm only arguing your own point here - YOU said to use int when used in
> > arithmetic
> > expressions and you don't know when your clients are going to use arithmetic
> > expressions.
> >
> > >
> > > Nick Hounsome wrote:
> > > >
> > > > "Julie J." <unlisted@.> wrote in message news:403B7591.7A05B64D@....
> > > > > abs is a math function.
> > > > >
> > > > > signed integers should be used for the storage of values that are
> > > > primarily
> > > > > used in arithmetic situations.
> > > > >
> > > >
> > > > I see you've watered down your criteria from last time I replied to you
> > but
> > > > my argument still stands:
> > > > They might not be PRIMARILY be used in arithmetic situations now but
> > they
> > > > might in the future.
> > > > Consequently maintainability/enhancability requires that you do not use
> > > > unsigned in the interface.
> > > > Having dispensed with unsigned in the interface it is only asking for
> > > > trouble to use it in the implementation.
> > > >
> > > > Furthermore, how much arithmetic do you have to do on an integer for it
> > to
> > > > be PRIMARILY used in arithmetic
> > > > situations?
> > > >
> > > > >
> > > > >
> > > > > lilburne wrote:
> > > > > >
> > > > > > Dennis (Icarus) wrote:
> > > > > >
> > > > > > >
> > > > > > > Found that one person, yet? (who agrees that unsigned should be
> > > > removed? )
> > > > > > >
> > > > > >
> > > > > >  From our coding standard:
> > > > > >
> > > > > >    "Avoid the use of unsigned int.
> > > > > >     An unsigned argument may be passed a negative number and C++
> > will
> > > > > >     silently convert it to a large positive value. Similarly if
> > > > > >     arithmetic is performed on an unsigned value returned from a
> > > > > >     function, the result may unexpectedly be a large positive
> > value."
> > > > > >
> > > > > > this is a direct reversal of an earlier policy to use unsigned where
> > the
> > > > > > value would never be negative. The history of how the change came
> > about
> > > > > > is a sorry litturgy of code breaking, exhibiting unintended
> > behaviour,
> > > > > > causing abiguity problems.
> > > > > >
> > > > > > So whilst we don't remove it all together, anyone that does use it
> > must
> > > > > > "Be prepared to defend violations of recommendations."
> > > > > >
> > > > > > now you might like to ponder why it is, if unsigned is so useful in
> > the
> > > > > > public interface, that in <math> there is:
> > > > > >
> > > > > >     long abs(long x);
> > > > > >
> > > > > > rather than:
> > > > > >
> > > > > >     unsigned long abs(long x);
0
julie2478 (37)
3/2/2004 12:19:58 AM
Reply: