Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uflorida!novavax!proxftl!bill
From: bill@proxftl.UUCP (T. William Wells)
Newsgroups: comp.lang.c
Subject: Machines for testing portability (was Re: "Numerical Recipes in C" is nonportable code)
Message-ID: <673@proxftl.UUCP>
Date: 30 Aug 88 07:15:10 GMT
References: <664@lindy.Stanford.EDU> <6758@megaron.arizona.edu> <718@gtx.com> <13258@mimsy.UUCP> <531@accelerator.eng.ohio-state.edu> <1673@dataio.Data-IO.COM>
Reply-To: bill@proxftl.UUCP (T. William Wells)
Organization: Proximity Technology, Ft. Lauderdale
Lines: 18
Summary:
Expires:
Sender:
Followup-To:
Distribution:
Keywords:

In article <1673@dataio.Data-IO.COM> bright@dataio.Data-IO.COM (Walter Bright) writes:
: The best way to learn to write portable code is to be required to port
: your applications to Vaxes, 68000s, and PCs. (I have all 3 on my desk!)

We find that using 68000's (Suns and Macintoshes) and IBM-PC's
(in the various memory models) is sufficient to catch most
portability problems.  Especially since we avoid as much as
possible using system provided libraries and do not do terminal
I/O except through standard I/O.

Anybody else have suggestions on sets of systems for checking
portability?  And how about portability between different system
libraries and different terminal handling schemes, a problem we
don't (yet) have because we ignore it?

---
Bill
novavax!proxftl!bill