Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!well!msudoc!umich!jtr485
From: jtr485@umich.UUCP
Newsgroups: comp.lang.c
Subject: Re: Portable C vs Efficient C or "Cost of Portability"
Message-ID: <101@umich.UUCP>
Date: Sat, 4-Apr-87 00:42:52 EST
Article-I.D.: umich.101
Posted: Sat Apr  4 00:42:52 1987
Date-Received: Sat, 11-Apr-87 04:42:56 EST
References: <213@pyuxe.UUCP> <710@brl-sem.ARPA>
Organization: EECS, University of Michigan
Lines: 33
Keywords: portability, performance

In article <710@brl-sem.ARPA>, ron@brl-sem.UUCP writes:
> One may right perfectly efficient portable code....most nonportable
> code is just sloppy rather than machine dependant.  Consider the following
> common errors:
> 
> 1.  Assuming that there is "0" at location "0".
> 2.  Assuming sizeof(int) == sizeof(char *)
>	passing things to subroutines without
> 	casting.  The assignment operater is pretty forgiving...it
> 	knows what the types on both sides need be.
Assignment had better be forgiving since type casts are defined in terms of it.

> 3.  Saying int when you mean long...
> 	Of course there is no way to determine this really portably,
> 	but you can make a small machine header file that sets up
> 	typedefs appropriately.
short, int, long is the dumbest part of C.  The language should have said
there will be a class of types int<ext> where <ext> is the number of bits.
But not have specified how many of these there are or what <ext> values
they should have.  just poor planning. take your header file ONE step further
add macros like 
#define int %$@very bad boy using INT#$
#define long %$@very bad boy using LONG#$
so you CANNOT use int, long etc.

> 4.  Making assumptions about byte order.
> 5.  Making assumptions about the location of items and padding within	structs.
how about:
  6.  Passing of variable parameter lists.
   	What?  You mean it can't be done portably?  Oh well, never mind. 

> -Ron
--j.a.tainter