Path: utzoo!utgpu!attcan!uunet!convex!killer!osu-cis!att!cbnews!mark
From: mark@cbnews.ATT.COM (Mark Horton)
Newsgroups: comp.lang.c
Subject: Re: Portable Code
Message-ID: <739@cbnews.ATT.COM>
Date: 29 Jul 88 15:06:44 GMT
References: <1157@radio.toronto.edu>
Reply-To: mark@cbnews.ATT.COM (Mark Horton)
Organization: AT&T Bell Laboratories, Columbus
Lines: 73

In article <1157@radio.toronto.edu> brian@radio.astro.toronto.edu (Brian Glendenning) writes:
>
>So I thought I'd ask the net for advice about how to write portable code. I
>know the topic is incredibly broad, but I expect I'm not the only person on
>the net who could benefit from some advice (e.g., people like myself who
>aren't primarily programmers and don't know the lore and wisdom of
>professionals).

Professionals have to learn this stuff some way too, and up until now the
only option is experience and the seat of your pants.

You might be interested in an upcoming book I'm writing called "How to
Write Portable Software in C".  It covers most of these sorts of issues.
It's from Prentice Hall and should hit the stores next spring or summer.

>Some issues that could be addressed:
>
>        1) Byte order and type size differences. What is the best way for
>           dealing with these? What are the "gotcha"'s?

In general, don't make assumptions about them.  Things like

	int c;
	read(0, &c, 1);
	if (c == '\n')

will work on a little endian machine like a VAX but fail on a big
endian machine like a Sun.  There are zillions of potential gotchas
like this, all of which come from assuming something in the folklore
but not in the manual.  (You aren't supposed to read into ints, just
into chars, if you intend the data type to be a char.)

>        2) BSD/SysV/whatever differences. What assumptions are likely to
>           lead me into trouble?

Zillions of them.  Without the book, which lists the functions and rates
their portability, your best bet is to get both a System V and a 4BSD
manual and verify that everything you do is in both manuals.  That is far
easier said than done.  A typical UNIX system manual will imply that
everything in it is portable, including the local enhancements that are
not present anywhere else.

>        3) Source code management: what's the best way to maintain codes that
>           run on a variety of machines. #ifdef MACHINE_TYPE? Never or rarely 
>           use #ifdef, edit makefiles? ???

There are several choices:

	#ifdef vax
		This is useful if you need to key on the hardware type.
		It's automatically defined by cpp.

	#ifdef SYSV
		Useful to key on the operating system.  You have to define
		this with -D or #define.

	#ifdef DBM
		Keying on a particular feature or option you need, you might
		have several of these and allow each to be configured.  You
		must define these yourself.

	#ifdef FIONREAD
		Keying on some constant in a header file that is an indicator
		of whether the feature you need is present.  These are
		automatic but you can't always use them.  In this case you
		might be using this ifdef to protect an ioctl(.. FIONREAD ..)

>	4) Everything I've forgotten :-)

It took a 350 page book to cover this, so it's hard to do in a Usenet
message.  I recommend buying the book, if you can wait.

	Mark Horton