Date:	Thu, 27 Aug 1998 14:04:40 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	George Foot <george DOT foot AT merton DOT oxford DOT ac DOT uk>
cc:	DJ Delorie <dj AT delorie DOT com>, djgpp-workers AT delorie DOT com
Subject:	Re: Patch to mkdoc and re: portability information
In-Reply-To:	<E0zBMqc-0000Hg-00@sable.ox.ac.uk>
Message-ID:	<Pine.SUN.3.91.980827140421.6326G-100000@is>
MIME-Version:	1.0

On Tue, 25 Aug 1998, George Foot wrote:

>     Defined by ANSI.  Generally available on Unix and DOS.
> or
>     Defined by POSIX but not ANSI.  Generally available on Unix but not DOS.
> or
>     Not defined by ANSI or POSIX.  Not generally available on Unix or DOS.

IMHO, too many words.  I think a table is enough.

> > For ANSI and POSIX compatibility, there are actually four cases:
> > 
> > * We follow the spec (i.e. malloc())
> > * We do not follow the spec (i.e. posix requires text files use \n not \r\n)
> > * The spec doesn't define this function (i.e. _bios_print())
> > * The spec precludes this function (i.e. biosprint(), but not _bios_print())
> > 
> > The last case should be for functions that, by default, are pulled in
> > by spec-required headers (like stdio.h) but pollute the spec's name
> > space.  Such functions could be removed by #defining the appropriate
> > symbol (i.e. _POSIX_SOURCE).
> 
> How should these four possibilities be listed?

How about a note in the ANSI column?  Like so:

   ANSI             POSIX  DOS  UNIX
   no (see note 1)   no    yes   no

   Notes:

   1. ANSI disallows using this in a portable program.

- Raw text -