Through a posting in comp.lang.c++.moderated, I happened to
become concerned about integral overflow.  Based on my
(limited) understanding of the April 95 working paper:


I find it disconcerning that nothing is said about signed
integral overflow.  If nothing is said, an implementation
might do as it pleases.  E.g., it may choose to generate a
"general arithmetic overflow" window on the system
operator's console and unconditionally terminate the
program. :-(

This is, imho, inconsistent with the general philosophy of
the language. When converting unsigned to signed, on signed
"out of bounds", an implementation may generate any value it
pleases, but: "The show must go on!"

In my opinion, there should be a rule in the standard which
says something to the respect:


"When you do signed integral arithmetic and it overflows,
all bets are off regarding the result value, but the program
will continue to work."


-----------------------------------------------
Opinions expressed in this article are my own,
not neccessarily those of my employer.

andreas.krueger@it-mannesmann.de


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <199608300840.KAA00419@mwt616.at.mdv.de> Andreas Krueger
<andreas.krueger@it-mannesmann.de> writes:

|> Through a posting in comp.lang.c++.moderated, I happened to
|> become concerned about integral overflow.  Based on my
|> (limited) understanding of the April 95 working paper:

|> I find it disconcerning that nothing is said about signed
|> integral overflow.  If nothing is said, an implementation
|> might do as it pleases.  E.g., it may choose to generate a
|> "general arithmetic overflow" window on the system
|> operator's console and unconditionally terminate the
|> program. :-(

I would think that a core dump would be the most appropriate solution.
Programming generally means some sort of modelling, and when that model
fails, it is a serious problem.  I cannot see why integer overflow is
any different than accessing a random pointer.  (If the overflow occurs
while calculating an index into a table of pointers, or an argument to
malloc or new, then it might really end up in accessing a random
pointer.)

|> This is, imho, inconsistent with the general philosophy of
|> the language. When converting unsigned to signed, on signed
|> "out of bounds", an implementation may generate any value it
|> pleases, but: "The show must go on!"

There has been some discussion of this in comp.std.c.  I had always
thought that overflow was undefined behavior in C, but the gentlemen
there convinced me that I was wrong, and that, in fact, the standard
requires pretty much what you are asking for.

Ideally, of course, overflow would be diagnosible error.  Given the cost
of doing so on current hardware, though, I can understand why the
diagnostic was not required.

|> In my opinion, there should be a rule in the standard which
|> says something to the respect:

|> "When you do signed integral arithmetic and it overflows,
|> all bets are off regarding the result value, but the program
|> will continue to work."

This is quasi-impossible.  Suppose the overflow occurred on an
intermediate result when calculating the argument to new.  Do you mean
that the program is still required to continue to work?  That operator
new somehow figures out that you actually want a lot more than you
requested, and gives it to you (or more likely, throws bad_alloc).

The only way a program will continue to work in the case of overflow is
if the arithmetic is continued somehow in extended precision.  That *IS*
expensive, and certainly not in the tradition of C and C++.

On the other hand, I do have a very pertinent standards related
question: in an expression of the form "new T[ n ]", suppose that "n" is
a valid value for size_t.  Can this expression result in undefined
behavior?  (One would hope not, but I'm willing to bet that the first
thing most implementations do is multiply n by sizeof( T ).  Without
checking for overflow:-).)
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]