From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Fri, 30 May 2014 15:56:33 +0100 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=089e013d1db25f9d3f04fa9f408d Subject: Re: [9fans] Compiler bug Topicbox-Message-UUID: f339db8e-ead8-11e9-9d60-3106f5b1d025 --089e013d1db25f9d3f04fa9f408d Content-Type: text/plain; charset=UTF-8 On 30 May 2014 14:03, Julius Schmidt wrote: > Comparing an int to a u16int causes the int to be cast to unsigned int, > instead of the u16int being promoted to int and then compared (as I would > argue the C89 standard specifies). Ken's compiler implements the original unsigned-preserving rule instead of ANSI's later invention. That has the advantage of the type not being dependent on the underlying storage size, but as you say the disadvantage of not using the so-called value-preserving rule. I suppose if I add some code that detects where it made a difference it might not cause too much trouble to change from the simple rule. I imagine p9p has already found most cases anyway. Otherwise, it's another more subtler nsec! --089e013d1db25f9d3f04fa9f408d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 30 May 2014 14:03, Julius Schmidt <aiju@phicode.de> wrote:<= br>
Comparing an int to a u16int causes the int to be cast to unsigned int, in= stead of the u16int being promoted to int and then compared (as I would arg= ue the C89 standard specifies).

Ken's compiler im= plements the original unsigned-preserving rule instead of ANSI's later = invention.
That has the advantage of the type not being dep= endent on the underlying storage size,
but = as you say the disadvantage of not using the so-called value-preserving rul= e.
I suppose if I add some code that detects where = it made a difference it might not cause too
much trouble to change from the simple rule. I imagine p9p has already fou= nd most cases anyway.
Otherwise, it's another more subtler nsec!

--089e013d1db25f9d3f04fa9f408d--