🚀 go-pugleaf

Clem Taylor (ctaylor@stimpy.eecis.udel.edu) writes:
> main ( )
> {
>     int a = 0x8000, b = 0xFFFF, c; /* ints are 16 bits */
>     int x = -32768, y = -1,     z;

On *this* machine, then, the constants 0x8000 and 0xFFFF have the type
unsigned, but their values are still 32768 and 65535 respectively.  The
sections I cited previously still apply: the values are converted in an
implementation-defined manner, but in practice can be expected to yield
-32768 and -1 respectively -- as the printf() seems to confirm.

The expression -32768 has the type long and the value -32768.  Assuming
2's complement, the value -32768 *can* be represented in an int, and so
it is converted to int without change [6.2.1.2/3.2.1.2]; a and x are equal,
as are b and y.

>     c = a / b;
>     z = x / y;

In each of these lines, -32768 is being divided by -1 in the type int.
The mathematical result is 32768, which does not fit in the type.  This
constitutes an exception, causing the behavior to be undefined [6.3/3.3].

> So, on a 16 bit machine, where promotion is not an issue, is this behavior
> correct?  Does the standard specify this...

*Any* behavior is correct [3.16/1.6].
-- 
Mark Brader           \ "It's not in the slightest bit harder to write Fortran
msb@sq.com             \ or Basic programs in C++ or Smalltalk than it is
SoftQuad Inc., Toronto  \ to write them in C or Pascal."   -- Peter da Silva

This article is in the public domain.
Apologies if you saw it twice -- a local glitch.