Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!husc6!cca!g-rh
From: g-rh@cca.CCA.COM (Richard Harter)
Newsgroups: comp.lang.c
Subject: Re: Machines for testing portability (was Re: "Numerical Recipes in C" is nonportable code)
Message-ID: <32825@cca.CCA.COM>
Date: 1 Sep 88 07:46:46 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> <673@proxftl.UUCP> <795@ns.UUCP>
Reply-To: g-rh@CCA.CCA.COM (Richard Harter)
Organization: Xerox Corporation, Cambridge, Massachusetts
Lines: 26

In article <795@ns.UUCP> ddb@ns.UUCP (David Dyer-Bennet) writes:

>  Also, while I haven't tried it personally, I remember a LONG string of
>articles years ago in some group with the subject "Porting to PRIME seen
>as a probable negative experience"; I seem to remember it has to do with
>different types of pointers being of different sizes, none of which would
>fit in in an int.

	This is somewhat of a bum rap.  Prime C at one time had 48 bit
char pointers versus 32 bit word pointers.  Currently all pointers are
48 bits.  This makes for problems for people who blithely stuff pointers
into ints.  But it really isn't a problem for people who port from UNIX
to PRIMOS who run their code through lint (and act on the results).

	Primos C does have some oddities.  They set the high bit on in
ascii chars.  Setting a file pointer to stdin or stdout has to be done
at the top level.  Library routines sometimes have different calling
sequences.  There is a 128K limit on array sizes (machine architecture).
But it really isn't all that bad; I've never seen the C compiler break
on standard portable C which is more than I can say for VMS C.

-- 

In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
	Richard Harter, SMDS  Inc.