Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!brl-adm!brl-sem!ron
From: ron@brl-sem.UUCP
Newsgroups: comp.lang.c
Subject: Re: Portable C vs Efficient C or "Cost of Portability"
Message-ID: <710@brl-sem.ARPA>
Date: Thu, 2-Apr-87 15:48:26 EST
Article-I.D.: brl-sem.710
Posted: Thu Apr  2 15:48:26 1987
Date-Received: Sat, 4-Apr-87 16:03:41 EST
References: <213@pyuxe.UUCP>
Organization: Electronic Brain Research Lab
Lines: 52
Keywords: portability, performance

In article <213@pyuxe.UUCP>, joecar@pyuxe.UUCP writes:
> 
> I'm looking for some information, experiences, opinions,
> references, etc., that will help me understand the following
> question:
>  
>    If one writes portable C, does it have to be less efficient 
>    than non-portable C ?
>  
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 int/char * are the same size.  This manifests itself in
	two ways.  First, sometimes people overload the same memory
	location with both pointers and ints.  This is what unions
	are for.  Unions should not be any less efficient than not
	having them (except where the compiler does initiallization
	wrong).  The second is passing things to subroutines without
	casting.  The assignment operater is pretty forgiving...it
	knows what the types on both sides need be.  Subroutines aren't
	nearly so clairvoyant, one needs to settle on what the argument
	type is and force any calls to be made to that type.  On machines
	where it doesn't matter, the cast is a no-op, on others it is
	essential.

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.

The above, when done correctly should have no effect on efficiency
(except that it will cause the code to work on machines where it
wouldn't before).

Now there are a few additional things that require some thinking to
do efficiently:

4.  Assuming byte ordering in larger objects.
	There are some real quick get arounds if you "know" your machine's
	byte order, but this may be wrong on other machines.  But this still
	can be accomodated.  For example the 4.2 network code has a macro
	that converts to network byte order which again is essential for
	machines with the other order, but is a no-op on the ones where
	the byte order is the same.

5.  Making assumptions about the location of items and padding within
	structures.  This one requires some thought.

-Ron