signed int overflow

[Ron Natalie]

No-one has been able to come up with examples of C++ compilers that do
anything but 2's complement.

If you have even a single such example please give it.

I can't say I've used C++ on it, but I've certainly used C on UNISYS 1100.
Not only is it a 1's complement machine, it's also got a 36 bit wordsize and
some very odd pointer issues. However, I'm fairly sure there is a C++
compiler for it as well.

If for no other reason than the C standard permits such architectures explicitly
they must be propagated in C++. If we were free to divorce ourselves from
certain C stupidities, C++ could be a cleaner language.

 

[Alf P. Steinbach]

* Ron Natalie:

I can't say I've used C++ on it, but I've certainly used C on UNISYS 1100.
Not only is it a 1's complement machine, it's also got a 36 bit wordsize and
some very odd pointer issues. However, I'm fairly sure there is a C++
compiler for it as well.

Perhaps you're fairly sure because with so many people saying there are
such compilers, surely there must be one? Well, drink blood. Billions
upon billions of gnats insist it is a lovely drink.

Now even you who has worked on a machine with 1's complement don't know
about a C++ compiler that actually uses that approach.

Perhaps there is some pre-standard C++ compiler for that machine, but I'd
dismiss that.

If for no other reason than the C standard permits such architectures explicitly
they must be propagated in C++. If we were free to divorce ourselves from
certain C stupidities, C++ could be a cleaner language.

Agree with the latter but not the former sentence. ;-)

Say that someone (not quite of their right mind) marketed a one's complement
micro-controller with a C++ compiler that also used one's complement (these
are two different things). What are the chances that compiler would be a
conforming one? About zilch, nada, nix; so why should we insist on providing
a path to conformance in one particular small area where the impact on all
_real_ and actual language implementations is negative?

 

[Tom Widmer]

* Tom Widmer:

AFAIK the above is incorrect.

No-one has been able to come up with examples of C++ compilers that do
anything but 2's complement.

If you have even a single such example please give it.

GCC on all platforms can be configured not to do wraparound overflow:
http://gcc.gnu.org/onlinedocs/gcc-3.4.2/gcc/Code-Gen-Options.html#Code-Gen-Options
See -ftrapv

I suspect there are programs that are relying on this "defined
undefined" behaviour, and such features shouldn't really make the mode
non-conforming IMHO.

As for other signed integer formats, I don't know of any current
machines using them, but you could try asking in an embedded
programming group; it may be that there are no current systems that
don't use 2s complement at all, but there may be some DSPs and similar
that do.

Tom

 

[Alf P. Steinbach]

* Tom Widmer:

GCC on all platforms can be configured not to do wraparound overflow:
http://gcc.gnu.org/onlinedocs/gcc-3.4.2/gcc/Code-Gen-Options.html#Code-Gen-Options
See -ftrapv

I suspect there are programs that are relying on this "defined
undefined" behaviour,

I suspect not... If so an example should have popped up long ago.

and such features shouldn't really make the mode non-conforming IMHO.

That concerns the wording of the standard.

For example, one could allow GCC's option by requiring a symbol like
NDEBUG, for example, _TRAPV_INT. Any old program relying on the
GCC compiler option (of which none are known) would then be conforming
just by pretending it had been compiled with this symbol defined. And
actual, real programs could then get standard-mandated trapping --
with implementation effect unless "trap" is also defined -- by using
the symbol.

Best of both worlds, that.

As for other signed integer formats, I don't know of any current
machines using them, but you could try asking in an embedded
programming group; it may be that there are no current systems that
don't use 2s complement at all, but there may be some DSPs and similar
that do.

Since this has been discussed many times in many forums with many experts in
this area, I rather doubt it; anyway the question is C++ compilers.

 

[Tom Widmer]

* Tom Widmer:

I suspect not... If so an example should have popped up long ago.

This newsgroup and newsgroups in general are only read by a small
proportion of the C++ community.

That concerns the wording of the standard.

For example, one could allow GCC's option by requiring a symbol like
NDEBUG, for example, _TRAPV_INT. Any old program relying on the
GCC compiler option (of which none are known) would then be conforming
just by pretending it had been compiled with this symbol defined. And
actual, real programs could then get standard-mandated trapping --
with implementation effect unless "trap" is also defined -- by using
the symbol.

Best of both worlds, that.

Well, the standard would have to define what a "trap" is. A particular
signal? Not very portable to Windows I think...

I suppose: "If _SIGNED_OVERFLOW_UNDEFINED is defined, the effects of
signed integer overflow are undefined, otherwise they are defined as
follows:"... Then implementations on funny (or future) processors or
with code generated for traps could just define that symbol.

Since this has been discussed many times in many forums with many experts in
this area, I rather doubt it; anyway the question is C++ compilers.

If Greg Comeau doesn't know of any current systems, then I doubt there
are any - I imagine Comeau C++ has been ported to a number of embedded
platforms. Has Greg ever posted on this issue?

Tom

 

[Greg Comeau]

If Greg Comeau doesn't know of any current systems, then I doubt there
are any - I imagine Comeau C++ has been ported to a number of embedded
platforms. Has Greg ever posted on this issue?

I have not. Partly because I can't remember (one would think
I would, but well, everything is always important on each port,
so lots gets blurry after a while), and partly because in the
cases where I can remember, I'm not allowed to say.