(* func)(fred, bert)

[Herman Rubin]

In article <11664 at smoke.BRL.MIL>, gwyn at smoke.BRL.MIL (Doug Gwyn) writes:
> In article <1113 at cirrusl.UUCP> dhesi%cirrusl at oliveb.ATC.olivetti.com (Rahul Dhesi) writes:
> >In article <11592 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn) writes:
> >>However, your code is not portable.
> >The great portable-as-boolean fallacy again.
> 
> No, that's your fallacy.
> 
> >His code is less than 100.000% portable, but it is probably more than
> >99.999% portable.
> 
> Since 100% portability is achievable just as readily as a lower
> degree of confidence (nowhere near 99%, by whatever meaningful
> metric one could devise), why recommend other than perfection
> in this case?  Bad habits should be discouraged as a matter of
> practical principle.

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, that all procedures assume
that the minimal sizes for each type are used for all arguments of that
type, and that all results are truncated to that size.  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.

It can be done, just as any computer can be exactly simulated on any
other computer with sufficient memory, internal or external.  Only
rarely should such expensive portability be considered.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin at l.cc.purdue.edu (Internet, bitnet, UUCP)