Unsigned types are DANGEROUS??

[Paul]

It seems to me that you might be putting too much value on your
misinformed opinions. I know I wouldn't give you a tuppence for it. A
tuppence for you to keep it to yourself maybe...

THe only misinformed opinion around here is the IDIOTS that think an array
is not an array because its a pointer.

I don't mean to be rude or nasty but I'm sorry I have no other opinion on
these people, they are just dumb ass idiots and nothing more.

 

[MikeP]

Am 17.03.2011 04:42, schrieb MikeP:

#include <stdint.h>

// use uint32_t etc.

Well it amounts to the same thing. Though I gave the typdef statement
above as general, my typedefs use the platform-specific __int32 or
whatever (I'm only on one platform). In either case, the poster suggested
that someone would eschew unsigned because of having to do more typing
and I was just pointing out that it is a non-issue.

 

[MikeP]

I am curious; I have been using VC++ for years and have not been aware
of a way to detected signed integer overflow; how exactly do you do
this without using assembler?

Windows' Structured Exception Handling (SEH) will probably let you hook
it.

 

[MikeP]

Sort of. For those implementations (up to 32 bit word and pointer
sizes), they didn't have much of a choice. If they even thought about
it, it means that they must have seen strong arguments towards using a
signed integer.

Spell it out for me please: How do you conclude that they must have seen
strong arguments towards using a signed integer?

However, I'm working mostly on 64-bit code these days (in C++ at
least).
For such an environment, this argument doesn't hold anymore in practice
(even though it still holds in theory)... a 64-bit signed integer is
more than enough to hold the sizes of anything I may want to address.

While 64 bits of address space is "more than enough", Intel limits the
accessible space to something less than 64 bits (48 bits?).

 

[MikeP]

I don't know whether it is /the/ real issue, but IMHO (I rarely use the
"H", but here I do it is an important issue.


IMO it is only useful in places where modulo arithmetic is purposefully
used. In highly optimized code for address (and other) calculations,
for
example. In encryption and hashing algorithms. There probably are
others; I'm by no means an expert here.

OK, so addresses and such where modulo arithmetic is a boon (I use that
OPTIMIZATION a lot too), there, modular integers are a great fit
(sometimes). Modular integers are a misfit for loop counters, but so are
signed integers. So the issue is that there is a missing integer type:
unsigned with overflow checking (and it would be nice if signed did
overflow checking too). Hence, everyone HAS to SHOEHORN a square peg in a
round hole: signed or modular integer where something else would be more
appropriate. I get it now.

As I see it, in the dawn of the language everything was clear: you used
(signed) int for everything -- except when you needed modulo
arithmetic,
which was when you used unsigned int. (Note also that "unsigned"
doesn't
mean "not negative" -- it means "has no concept of sign", neither
positive nor negative. Another thing often overlooked.)

I see no evidence that it was not just an error of omission or
obliviousness to requirements or inadvertently it just happened to work
out that way. Then again, I haven't analyzed all the permeating affects
of "doing it right". "doing it right" meaning regarding modular integers
as a special optimized type to be used where modulo arithmetic is highly
advantagous.

In the library things were less clear: since there was no (signed) int
to represent the whole range of addressable bytes,
they sort of /had/ to
use unsigned for size_t. And bingo -- we were in the mess that we still
are and are compelled to use (unsigned) size_t for calculations that
are
not meant to be modulo arithmetic.

But that is still the wrong line of reasoning. You are suggesting that
signed is the right thing because modular is the wrong thing, and that is
not the case. The right thing is non-existent in the language. Error of
omission.

So there are two orthogonal concepts: modulo arithmetic (the language
says unsigned is modulo, signed is not necessarily) and whether a given
variable may or may not assume negative values.

Well there are more than 2 concepts: signed, unsigned, the modulo
optimization, overflow checking. 4 concepts and the combinations of them.

Unluckily these two are
all too often mixed up in the discussion -- and they are mixed up
between the language itself (that makes the clear distinction that
unsigned is for modulo arithmetic and signed is not) and the library
(which uses unsigned for places where modulo arithmetic is not
necessarily desired).

Since all this goes way back to early C (and early C++), I don't see
any
of this change any time soon (or not so soon). So we just have to live
with the mess and find our way around it.

I foresee new integer types in the standard soon.

It can't be "clean" code,
because we have to live with the library and its compromise (which on
some platforms is a necessary compromise), so we have the various
opinions on how to make the code "less unclean".

There's only one good solution going forward. Gotta start biting the
bullet.

The implicit conversions between signed and unsigned didn't help,
either.

Did I say FOUR concepts and their conbinations? My bad. FIVE:
conversions!

If I had a compiler with a switch that disabled them, I'd have
this switch on all the time.

Hear, hear! Nothing a wrapper won't solve though in the interim or to use
in debug builds.

There should be a signed_cast (similar to
const_cast) for these cases. Luckily, most modern compilers are
starting
to see the problem and introducing warnings for these cases -- almost
as
good.


IMO the "half-bakedness" came in when the library used unsigned in ways
the language definition didn't really support -- for practical reasons
(as so much in C and C++).

I think it happened before that during "requirements analysis" (not that
that was formally, thoroughly or capably don e though, I don't know if it
was or not) when the error of omission occurred.

Because of backwards compatibility (another
common reason for how things are in C and C++), we're stuck with this
ever since.

Stuck with the workarounds. C++'s abstraction capabilities alleviate the
issue somewhat if taking advantage of them.

Also, the situation with the typically highly optimized code in
relatively slow 8- and 16-bit environments (when all this was defined)
is quite different from how it is now. So what made good sense back
then
doesn't seem to make as much sense now

In this case, I'm not sure it made sense back then either.

-- but the rules from back then
are still valid.

Not really. Being "lesser wrong" is still "wrong".

 

[MikeP]

I guess that requires CPU support;

SEH does? C++ exceptions are built on top of SEH (or at least they used
to be, don't know about now).

 

[MikeP]

SEH is only useful if an exception is actually thrown; I see no support
in VC++ for causing such an exception to be thrown on integer overflow
unless you actually write some inline assembler (INTO instruction for
example) after the integer operation.

A "structured exception" you mean? You'll have to map it to C++
exceptions. No assembly required though. (I haven't done this yet, BTW,
just read about it... am considering it now though).

 

[MikeP]

SEH is only useful if an exception is actually thrown; I see no support
in VC++ for causing such an exception to be thrown on integer overflow
unless you actually write some inline assembler (INTO instruction for
example) after the integer operation.

OK, I see what you mean now:
http://www.gamedev.net/topic/310538-integer-overflow-exception/

 

[MikeP]

Yes I mean a "structured exception"; AFAICT there *is* assembly
required as VC++, targeting Intel, will not emit code to trigger an
overflow interrupt which in-turn causes a structured exception to be
thrown. I have tested this on Win32 and SEH only kicks in if I
manually add an inline "INTO" assembler instruction after an
overflowing expression.

And it seems like a rather torturous path to go through: sprinkle INTO
instructions all over the place, that will transfer control to what is
vectored at interupt 4 (SEH no doubt), your SEH "hook" will map to C++
exceptions, and Wa La, overflow checking in C++!

 

[MikeP]

Yes I mean a "structured exception"; AFAICT there *is* assembly
required as VC++, targeting Intel, will not emit code to trigger an
overflow interrupt which in-turn causes a structured exception to be
thrown. I have tested this on Win32 and SEH only kicks in if I
manually add an inline "INTO" assembler instruction after an
overflowing expression.

You actually got the INTO to work though? You've caught the
EXCEPTION_INT_OVERFLOW exception?

 

[MikeP]

Or as actually happens on my implementation the entire expression is
optimized to an instruction which does not affect the overflow flag
at all.
So basically VC++ (VS2008) does not support detection of signed
integer overflow; using in-line assembler doesn't does not equate to
"support" IMO.

Well that settles that then. So who is going to write up the proposal to
the committee for a new integer type(s)?

 

[Noah Roberts]

Well that settles that then. So who is going to write up the proposal to
the committee for a new integer type(s)?

Why bother with all that when it would be fairly simple to come up with
your own?

struct smart_int
{
...
smart_int& operator+=(smart_int i)
{
assert(i < 0 || std::numeric_limits<int>::max() - value < i.value);
// ... etc...
value += i.value;
return *this;
}

private:
int value;
};

Alternatively you could use policy design and have "check" a policy that
can be plugged in when appropriate.

Remember the C++ mantra: don't make people pay for what they don't need.

 

[MikeP]

Why bother with all that when it would be fairly simple to come up
with your own?

struct smart_int
{
...
smart_int& operator+=(smart_int i)
{
assert(i < 0 || std::numeric_limits<int>::max() - value <
i.value); // ... etc...
value += i.value;
return *this;
}

private:
int value;
};

Alternatively you could use policy design and have "check" a policy
that can be plugged in when appropriate.

Remember the C++ mantra: don't make people pay for what they don't
need.

Yes, I've noted wrapper-technique many times in this thread. A built-in
would no doubt be more efficient. And I'm not sure how close one can come
to built-in behavior and in how many of the scenarios with the wrapper.
No one would pay for what they wouldn't need: don't use the new integer
type if you don't see a need for it.

 

[MikeP]

But it doesn't really make sense as a proposal as overflow is a bug
not a feature.

Introduction of the required missing integer type(s) IS a feature. You
have the subject in your sentence wrong.

 

[MikeP]

Rather than new types a qualifier would be better:

nooverflow int n;
nooverflow char ch;

I don't think that is better. I do think the old types would become
deprecated in a lot of places if new types were introduced. No sense
throwing good money after bad, you know.

 

[MikeP]

Don't you think it's odd that on the one hand Java rejected unsigned
types,

But why did they?

yet on the other hand guarantees two's complement
representation?

The question is To me that's a classic case of dissonance between
recognizing the usefulness of representation tricks yet shunning it
because it's somehow impure.

How does that translate into "there should not be integer types that have
overflow checking"? Or does it?

 

[Peter Remmers]

Am 17.03.2011 12:22, schrieb Paul:

I am not even reading your long winded explnation of what E1 is above.
I'm simply "telling" you it's an array, I don't care what you think I'm
telling you wehat it simply is.

You don't care. You don't tell what it simply is. You tell everyone what
is your distorted view of the matter. You tell everyone who does not
share your view they are idiots and they should **** off and STFU. You
resort to name calling once you run out of arguments. You tell everyone
that they are confused, they are trolls, they are narrow-minded,
ignorant, arrogant, n00bs, losers, and whatnot. You boast that you have
been right about those things 20 years ago. You act like you are the
only sane person in this newsgroup, like you are far superior, even
though you don't have a single clue who you are talking to - you just
are superior by definition.

Your claim that you already knew everything better 20 years ago implies
that you are at least 30 years old or something. Which is all the more a
shame because you act like a little child, sticking your fingers in your
ears and singing "lalala, I don't hear you!". You are not able to have a
technical conversation without name calling, high adrenaline levels,
accusations, and good manners worthy of an adult who deserves respect.

Peter

 

[MikeP]

I think that deprecation of existing types is a) wishful thinking

You didn't read what I wrote: I said in a lot of places (maybe "a lot" is
too strong).

and
b) not necessary as I don't believe we need any new types (modulo what
c++0x is providing). Overflow is a bug and adding a language feature
purely for avoiding or detecting a bug seems somehow wrong to me as I
don't I think there is precedent for it.

Think about it correctly instead of in terms of overflow. Currently
unsigned does not give the required semantic you have be arguing for,
hence something is lacking: the complement integer type to signed. It's a
void being filled by what is available and neither of those alternatives
type are behaviorally correct for the required usage.

 

[MikeP]

I think that deprecation of existing types is a) wishful thinking and
b) not necessary as I don't believe we need any new types (modulo what
c++0x is providing). Overflow is a bug and adding a language feature
purely for avoiding or detecting a bug seems somehow wrong to me as I
don't I think there is precedent for it.

And, to me, though I am not a language lawyer, it seems that the BUG is
the error of omission (or more than one) when the type system was
created.

 

[MikeP]

So, I'd rather just do overflow checking like

if (~a < b) { /* overflow */ }

That's cryptic.

than to depend on an iodiosyncratic toolbox of extensions and
libraries. It's like cooking: there are people who use all the
gadgets, and people who stick with a good chef's knife.

And put the salmonella into the cake slices you mean?