Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!ncar!groucho!steve
From: steve@groucho.ucar.edu (Steve Emmerson)
Newsgroups: comp.std.c
Subject: Re: Frustrated trying to be portable
Keywords: ANSI C, standard library
Message-ID: <10322@ncar.ucar.edu>
Date: 18 Feb 91 02:34:29 GMT
References: <1991Feb17.203337.20569@uokmax.ecn.uoknor.edu>
Sender: news@ncar.ucar.edu
Distribution: na
Organization: University Corporation for Atmospheric Research (UCAR)
Lines: 40

[I'm posting this article rather than replying via email due to the
general nature of the problem and the fact that our approach (detailed
below) might be incorrect.]

Cliff Green <clgreen@nsslsun.gcn.uoknor.edu> writes:

>I'm getting somewhat frustrated in making a fairly complex package I'm 
>working on to be portable.  ...

>...?  I appreciate all
>the help you can give this standards novice.

We're attempting to solve just this portability problem through the use
of platform- (i.e. operating-system and compiler) dependent header-files
and interface libraries.  For example, a program might have at its top

	#include "udposix.h"
	#include <stdlib.h>
	...

and, if necessary, we supply the <stdlib.h> header-file, which might
include system-supplied header files as well as defining/declaring any
missing items.  The coding style is a subset of that allowed by the
union of Standard C and POSIX.  Function prototypes are supported on
appropriate platforms.

The code would be compiled by something akin to

	cc -I$(UNIDATA_INC) <program>.c -L$(UNIDATA_LIB) -ludposix ...

where the `udposix' library is also supplied by us (it's empty on some
platforms).  Missing functions are created and incorporated into the
library on an as-needed basis.

Supported platforms include AIX 3.1, SunOS 4.0.3, SunOS 4.1, 
SunOS 4.1.1, Ultrix 3.5, Ultrix 4.0, UNICOS 5.1.9, and VMS 5.3.

If you'd like more information, give me a buzz.

Steve Emmerson        steve@unidata.ucar.edu        ...!ncar!unidata!steve