Pedro Izecksohn <[EMAIL PROTECTED]> wrote:
> peternilsson42 wrote:
[ unsigned short int a;
a = USHRT_MAX; /* previously a = -1; */ ]
> > So you made absolutely _no_ change to the semantics of
> > that assignment!
>
> I fixed the signal to make others happy.
You must be referring to Thomas' comment:
"BTW, you should have your compiler warnings turned up
so that you get a warning for assigning a signed value
to an unsigned variable."
Admittedly assigning -1 to an unsigned type may look
unintuitive, but it's actually the best way to get the
max value without using (the ugly) UXXXX_MAX macros.
So, I disagree with Thomas if he is saying that a = -1;
is undesirable. Although I'm all for warnings about
comparison of signed and unsigned types. [e.g. -1 < 1u,
which is actually false.]
> > You seem to be only interested in one class of machine.
> > ...
> > why do you think that? Or,
> > do you think different values should be displayed?
>
> My previous reference was:
>
> "The three forms of the IMUL instruction are similar in
> that the length of the product is calculated to twice
> the length of the operands." ...
Ah, then you've probably been fooled by the cliché that
C is just portable assembler.
Another subtlety that you should be aware of concerns
floating point calculations. By rights, C requires that
intermediate calculations are _not_ performed in wider
types. However, many compilers will do it anyway. Often
because it's faster, not because it's more accurate.
gcc has a switch -ffloat-store that enforces ansi/iso
semantics in that regard.
> Now I saw:
>
> "An example of undefined behavior is the behavior on
> integer overflow." (ISO/IEC 9899:1999 (E))
>
> It is mathematically obvious the Intel's approach.
> I thought it applied wherever it is possible.
Very few languages take advantage of such instructions.
[FORTH's */ (STAR-SLASH) is one exception.]
--
Peter
