From:	George Foot <mert0407 AT sable DOT ox DOT ac DOT uk>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Suggestion: Portability section for libc docs
Date:	10 Feb 1998 17:34:25 GMT
Organization:	Oxford University, England
Lines:	66
Message-ID:	<6bq331$l9e$1@news.ox.ac.uk>
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 980210133039 DOT 12622M-100000 AT is>
NNTP-Posting-Host:	sable.ox.ac.uk
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

On Tue, 10 Feb 1998 13:30:58 +0200 (IST) in comp.os.msdos.djgpp Eli
Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:

: On Mon, 9 Feb 1998, Nate Eldredge wrote:

: > Each function could say whether it is ANSI, POSIX, available on Unix
: > or other DOS compilers, unique to DJGPP, etc.

: I think this is a very good idea.

: Two comments:

:     1) Since most DOS-based compiler don't have POSIX-compliant
:        headers such as unistd.h, I suggest that the Portability
:        section would also include the headers where the
:        functions/variables are declared in the other DOS compilers.
:        This will allow people to write code like below when they need
:        e.g. to use `dup2', without looking for Borland docs:

:     2) Sometimes functions which exist on other platforms have
:        slightly different functionality.  In such cases, the
:        differences should be mentioned.

I partially disagree; I think it would be useful to point out which
functions are portable and to what extent, certainly, and since djgpp
compiles for DOS it would make sense to include portability
information to MS and Borland; but I don't think the libc docs are the
place to describe exactly how certain functions work on *other*
compilers.  If a function is significantly different on another
compiler, I think the fact should be noted, but detailing all the
differences a particular function has seems pointless -- if there are
significant differences, the programmer ought to test their program on
that other compiler before claiming that it will run there, and surely
the docs for the other compiler are the place to look for these details.

I think the portability section should be fairly brief; for example,
if a function is ANSI, just write ANSI.  If it's not availble on
Borland, perhaps write `not Borland'.  If MS put it in a strange
header file, write `Microsoft (io.h)', or something similar.  It's
meant for reference, after all.

Of course there would need to be some section of the docs to explain
the notation.

: You don't need the standards, it is enough to look into the DJGPP
: headers.  Anything that is before ``#ifndef __STRICT_ANSI__'' is ANSI;
: anything that is before ``#ifndef _POSIX_SOURCE'' is POSIX and
: non-ANSI; everything that's after ``#ifndef _POSIX_SOURCE'' is neither
: ANSI nor POSIX.

Does that mean that all ANSI functions are POSIX too?

: I can offer help in Borland-related issues up to BC 3.1; I don't have
: and never worked with BC 4.x or 5.x.  I can also access SunOS 4.x
: (BSD-like), SunOS 5.x (SysV-like), Alpha/Unix, and Linux systems to
: see whether a function is available there.

I'd be happy to help in any way I can.  I only have access to Digital
Unix on an Alpha and Linux, which both overlap with Eli's list above.
There are a lot of functions in the docs though; perhaps they should
be `farmed out' to volunteers?

-- 
george DOT foot AT merton DOT oxford DOT ac DOT uk

ko tavla fo la lojban

- Raw text -