Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!mit-eddie!genrad!decvax!decwrl!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.lang.c
Subject: Re: C Review
Message-ID: <11737@sun.uucp>
Date: Tue, 20-Jan-87 14:49:34 EST
Article-I.D.: sun.11737
Posted: Tue Jan 20 14:49:34 1987
Date-Received: Wed, 21-Jan-87 03:43:40 EST
References: <2313@brl-adm.ARPA> <1667@hoptoad.uucp> <451@catnip.UUCP>
Sender: news@sun.uucp
Lines: 26
Summary: No, people on some 68K machines are *quite* aware of portability concerns like that....

> People who have Intel 80x86 based Unix micros (such as Xenix and Microport)
> are actually *more* aware than you 68000 types about portability concerns.
> We are the ones who get bitten when someone assumes sizeof(int)=sizeof(long),

Wrongo.  Some 68K implementations have 16-bit "int"s and 32-bit pointers and
"long"s; those of us who have worked on such implementations are quite aware
of this.

> >It's taken about 6 months to get a version of "arc" (written in C for
> >msdos) to run semi-reliably on machines with different byte order,
> >different order of execution, or different word sizes than the 8088.
> 
> As a person who ported the recently posted Unix arc sources to Xenix,
> let me assure you that many of the portability problems were introduced
> by the Unix guru who ported arc to Unix (on a 68000 based micro no less)

It seems doubtful that problems in porting "arc" to a non-808* machine were
caused by its port to a 68K-based machine!

My own favorite "worst architecture/C implementation" for encouraging
non-portable code is VAX UNIX's, but so what?  There is a distressing
tendency amongst C programmers on *all* implementations to write
non-portable code when with little or no extra effort, and little or no cost
in efficiency, they could write the same code portably.  Trying to pin the
blame on one particular machine or on one particular C implementation on
that machine is pointless.