Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!samsung!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: (* func)(fred, bert)
Message-ID: <11678@smoke.BRL.MIL>
Date: 23 Nov 89 16:35:25 GMT
References: <2387@stl.stc.co.uk> <744@lakart.UUCP> <0175@sheol.UUCP> <11664@smoke.BRL.MIL> <1736@l.cc.purdue.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 22

In article <1736@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>To get 100% portable code, it is necessary to be absolutely sure that
>the same results occur in all installations.  For C, this would mean
>that all arithmetic be integer arithmetic, ...  Furthermore,
>unsigned arithmetic must be used, as there is no guaranteed way to get
>the signed numbers correct (except possibly by casting in exactly the
>right manner).
>Boolean operations could still be used, but shifts would require the
>truncation to be explicit, and sign-propagation shifts would require
>the appropriate corrections to be explicit.  No floating point would
>be usable.

NO!  You are trying to come up with rules that guarantee that ANY
code following them WILL work portably.  However, in practice all
that a portable C programmer needs to do is to stay within the bounds
of what is guaranteed by the language specs to work properly.  That
is a MUCH larger domain than your rules imply.

And in any case you didn't address the issue we were discussing,
the rule for which would be "use types properly".  Certainly,
deliberate violation of C's type compatibility rules is just
asking for portability problems.