> C programmers don't give a damn about overflows. An unfortunate consequence,
> probably, of hardware architectures which, unlike 360, lack unsigned
> instructions, forcing compilers to generate signed instructions for
> unsigned operations.
I've spent more of the last week finding out more about integer overflow (non-)
handling in C than I would have wished to, and certainly enough to last a
lifetime.
In a nutshell the story appears to be that the C standards ("The nice thing
about standards is that you have so many to choose from" - Tanenbaum) simply
codified the variety of existing practice. Where there was no consensus
behavior was left "undefined". Thus we have:
C11 6.5/5
If an exceptional condition occurs during the evaluation of an expression (that
is, if the result is not
mathematically defined or not in the range of representable values for its
type), the behavior is undefined.
with the exception clause:
C11 6.2.5/9
The range of nonnegative values of a signed integer type is a subrange of the
corresponding unsigned integer
type, and the representation of the same value in each type is the same. A
computation involving unsigned
operands can never overflow, because a result that cannot be represented by the
resulting unsigned integer
type is reduced modulo the number that is one greater than the largest value
that can be represented by the
resulting type.
Thus unsigned integers wrap without warning, signed integers can do whatever
their fancy takes (qv "nasal demons").
Come back Ada, all is forgiven,
Best wishes / Mejores deseos / Meilleurs vœux
Ian ...
On Wednesday, April 20, 2022, 02:32:44 AM GMT+2, Paul Gilmartin
<00000014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
On Apr 19, 2022, at 17:57:23, Bernd Oppolzer wrote:
>
> LPR: if the register contains 0x80000000, IMO the result will be zero (and
> overflow),
>
I'd expect 0x80000000, with overflow.
> so you're right ... this will lead to a zero result. IMO, the overflow will
> be ignored.
>
C programmers don't give a damn about overflows. An unfortunate consequence,
probably, of hardware architectures which, unlike 360, lack unsigned
instructions, forcing compilers to generate signed instructions for
unsigned operations.
> N result zero: LPR ... LCR ... SRL puts x'00' in R1
> N result X'80000000': LPR overflow (zero) ... LCR ... SRL puts x'00' in R1
> N result otherwise non-zero: LPR non-zero positive ... LCR negative ... SRL
> puts x'01' in R1
>
Oops! I forgot that one non-negate value with a complement.
> Is bitwise AND defined for signed ints, which are negative?
>
AND doesn't care -- the sign is just one of 32 bits.
> IMO, this is difficult; the result depends on the number format (2s or 1s
> complement).
> So, maybe, this is not defined in the C language; bit operations are for
> unsigned ints, normally.
>
Does the C standard require that shifts are equivalent to
multiply/divide by powers of 2? That pretty much implies
2/s complement. Hmmm. Sift right truncates toward -∞,
not toward zero.
--
gil
