From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <97ECED3C-853F-482C-A098-E60245EF347A@me.com> References: <201503112030.t2BKU71p008530@skeeve.com> <97ECED3C-853F-482C-A098-E60245EF347A@me.com> Date: Thu, 12 Mar 2015 17:14:47 +0000 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=047d7bf0c39a55849e05111a8521 Subject: Re: [9fans] ken cc for linux Topicbox-Message-UUID: 495f51ce-ead9-11e9-9d60-3106f5b1d025 --047d7bf0c39a55849e05111a8521 Content-Type: text/plain; charset=UTF-8 That reminds me that I've got various small repairs and changes to merge in. Possibly the best way will be to point to a test version in an announcement here, and then people can check that they work for them, so nothing breaks unexpectedly on recompilation. One potential big future change (not yet made) is to switch to strictly ANSI rules for unsigned+signed values meeting in "the usual arithmetic conversions". The rules are horrible, but it's one of the few ways in which the compiler implements something that's neither an extension nor a restriction compared to the standard. You'll never miss most of the others. One approach there is to have the compiler consider the type under both systems and warn if the difference might cause trouble (typically in comparisons, but there might be other cases). Most of the Plan 9 source has been compiled under the ANSI regime in the form of Plan 9 Ports, so I'd expect that most of the tricky cases have already been fixed. --047d7bf0c39a55849e05111a8521 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That reminds me that I've g= ot various small repairs and changes to merge in.
Possibly the best way will be to point to a test version in an annou= ncement here, and
then people can check tha= t they work for them, so nothing breaks unexpectedly on
recompilation.

One potential big future change (not yet made) is to = switch to strictly ANSI rules for unsigned+signed
values meeting in "the usual arithmetic conversions". The = rules are horrible, but it's one of the
few ways in which the compiler implements something that's neither= an extension nor a restriction
compared to= the standard. You'll never miss most of the others. One approach there= is to have
the compiler consider the type = under both systems and warn if the difference might cause trouble
(typically in comparisons, but there might be other = cases). Most of the Plan 9 source has
been = compiled under the ANSI regime in the form of Plan 9 Ports, so I'd expe= ct that most of the
tricky cases have alrea= dy been fixed.
--047d7bf0c39a55849e05111a8521--