🚀 go-pugleaf

In article <a_rubin.716593540@dn66> a_rubin@dsg4.dse.beckman.com (Arthur Rubin) writes:
>In <1992Sep15.043224.27920@nntpd.lkg.dec.com> diamond@jit345.bad.jit.dec.com (Norman Diamond) writes:
>>In article <1992Sep12.164915.10734@jarvis.csri.toronto.edu> flaps@dgp.toronto.edu (Alan J Rosenthal) writes:
>>>a_rubin@dsg4.dse.beckman.com (Arthur Rubin) writes:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>	int a, b;   long c;
>>>>My interpretation (from reading K&R 2) would be that c = a * b should be
>>>>equivalent to c = (int)(a * b).

>K&R 1, in the section on type conversions (2.7), states:
>    The result is of the higher type....

without quite mentioning what happens when neither operand needed promoting :-)
No problem though; there's more below.

>This implies that the result in case of overflow, although undefined, is
>an undefined int.

No.  When a result is undefined, the computer is allowed to burn itself up
and be reincarnated with a different program in its memory, in which the
declared datatypes have magically changed to "long".

(If the result were unspecified, it would be an unspecified int.  But the
standard does not say this -- likely because overflow can at least cause
your thread of execution to burn up, and maybe be reincarnated with a
change of datatype :-)

>Followups to comp.std.c, as it no longer is relevant to any of the other
>groups.

Yeah, and Mr. Bigham tried to trick me into posting to comp.lang.c (without
warning), so I've added comp.lang.c back in for Mr. Bigham.

In article <716597823@romeo.cs.duke.edu> dsb@duke.cs.duke.edu (D. Scott Bigham) writes:
>Section A7.6, "Multiplicative Operators", states that "The usual
>arithmetic conversions are performed on the operands, and predict the
>type of the result."

OK, I can find in ANSI 3.2.1.5, page 36 lines 17 to 18, "and yield result
types in a similar way.  The purpose is to yield a common type, which is
also the type of the result."  Couldn't find anything like this in the
expressions chapter though.

Oddly, the last two lines in that section (and on that page) allow
implementations to stick extra bits in floating values, without saying
anything about integral values.

>>No, cast-to-int does not overflow.  It has a defined result.

>Careful, this is _signed_ int we're talking about here.  According to
>section A6.2, "Integral Conversions", "When any integer is converted to
>a signed type, the value is unchanged if it can be represented in the
>new type and is implementation-defined otherwise."

Sounds like it agrees with the standard.  Sometimes the result is defined
by the standard, the rest of the time the result is defined by the
implementation, and the result is never undefined.
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"Yeah -- bad wiring.  That was probably it.  Very bad."