🚀 go-pugleaf

(My apologies for the large quote, but the example was pretty hard to
trim....)

In article <4iermd$apc@solutions.solon.com> Michael Smith <msmith@mpx.com.au>
writes:
>I missed the start of this, so I may have the wrong end of the stick, but 
>I think that the intention would be to replace code like:
>
>#if defined(SOME_SYSTEM)
>#include <malloc.h>
>#elif defined(SOME_OTHER_SYSTEM)
>#include <alloc.h>
>#elif defined(YET_ANOTHER_SYSTEM)
>#include <memory.h>
>#else
>#include <stdlib.h>
>#endif
>
>#if defined(MSDOS)
>#include <sys\\stat.h>
>#elif defined(VMS)
>#include <whatever file spec needed for VMS>
>#else
>#include <sys/stat.h>
>#endif
>
>with code like this:
>
>#define INCLUDE_MALLOC
>#define INCLUDE_STAT
>#include <uUHF.h>

I think this is the wrong approach.  These two examples are actually
rather good, because they are also rather different.

Let us consider malloc() first.  If we have a conformant compiler,
<stdlib.h> will be the correct include file, but there are still some
compilers Out There that require the use of `alloc.h' or `memory.h'
or some such.  In this case, it is actually fairly reasonable to want
a simple and direct way to include the correct header.  I would
probably solve this in one of two or three ways:

	- Simply #include <stdlib.h>, and require that it be
	  correct (by fixing or replacing the implementation if
	  necessary).

	- Write my own module that implements memory allocation;
	  put any gross #ifdef'ing into it, and use `myalloc()'
	  everywhere.  This is particularly sensible if you want to
	  use a `void *' allocator (some of the systems return
	  `char *') and/or have a standard out-of-memory error.

	- Use a macro to define the name of the correct header, and
	  `#include MALLOC_H'.

The second case is harder, if less subtle (e.g., for malloc we had to
think about pre-ANSI implementations).  In this case, there is no
guarantee that there *is* a `stat.h' of *any* kind.  Here, I would
relegate the inclusion of a stat.h (or equivalent) to a port-specific
module, and hide access to the `struct stat' (or equivalent) behind
soem sort of interface.  Then, when the application is ported to an
ancient IBM O/S, we simply (hah!) need to write a module that gleans
the desired information from the various FCBs.  The application may
even become usable on a system that lacks files entirely (and therefore
has no equivalent of any stat structure), though obviously this would
depend on the application itself.

Writing portable code is difficult, but I think that attempting a
universal header file is the wrong approach in most, if not all,
cases.  The right approach is to pick a set of standards you will
require (such as ANSI or POSIX), define your own abstractions for
what you need from the system, and write everything *not* provided
in those standards using those abstractions.  Perhaps (e.g., for
efficiency) some or most of those will simply be macros, and only
time and porting can prove which abstractions were sufficiently
abstract -- but there is no way that (for instance) you are going
to make a TCP application work on a machine that has no networking
code of any kind, so there is no point in `universalizing' the
header file for TCP on machines that do not support it.
-- 
In-Real-Life: Chris Torek, Berkeley Software Design Inc
El Cerrito, CA	Domain:	torek@bsdi.com	+1 510 234 3167