www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1998/02/27/00:42:49

Date: Fri, 27 Feb 1998 05:42:18 +0000 (GMT)
From: George Foot <george DOT foot AT merton DOT oxford DOT ac DOT uk>
Reply-To: George Foot <george DOT foot AT merton DOT oxford DOT ac DOT uk>
To: DJ Delorie <dj AT delorie DOT com>
cc: djgpp-workers AT delorie DOT com
Subject: Re: Suggestion: Portability section for libc docs
In-Reply-To: <199802270505.AAA23577@delorie.com>
Message-ID: <Pine.OSF.3.95.980227051636.6178I-100000@sable.ox.ac.uk>
MIME-Version: 1.0

On Fri, 27 Feb 1998, DJ Delorie wrote:

> ansi and posix are definite.  I think "dos" doesn't make sense; it's
> not a compiler.  "unix" is too vague, and ansi/posix should cover it.
> "windows" is also not a compiler.  I'd recommend ansi, posix, and
> maybe bc and msc, potentially with a digit after to indicate a version
> number (i.e. msc7 or bc3).  After all, they're the most popular
> platforms people will be interested in being portable to.  Maybe add
> cygwin?

Watcom?  I suggest the version number (if any) be separated from the
token, e.g. "msc(7)" or "bc(3.1)" if those versions exist.  We can then
append the version to the `nice' output string making "Microsoft C 7" or
"Borland C 3.1", for instance.  Getting the version numbers right may be
awkward, though -- it involves somebody having two copies of the same
compiler with the right version numbers to notice the difference.
Alternatively we could mention version number differences in notes.  I'm
not sure why we need to go into this much detail, though. 

> If a target isn't mentioned, put "?" or "unknown", or omit that column
> in the table (after all, we only have one function per table!).

I'm wondering whether the table really is a good format.  If we're going
to be leaving out columns frequently, we might as well just write a list,
e.g. "ANSI, POSIX, Microsoft, not Borland". 

> > The "!dos" sounds sensible, yes -- this can be added easily.
> 
> Unfortunately, this means that every function needs to list every
> compiler we support.  Don't know if that's better than assuming
> unlisted means unsupported.

Well... unlisted means nobody has checked it.  Writing "unknown" might
make the docs seem incomplete.  If we just don't mention unlisted targets,
people can draw their own conclusions -- a function which is ANSI but does
not mention Borland can probably be assumed to be portable to Borland.

> mkdoc should combine port-note's with the same keyword, in the order
> they're given, into a single note.

Yes, I've just realised that the way I did the portability notes was
rather roundabout -- it would be much simpler to just use an array of char
*, one element per target, then realloc and strcat to those strings. 

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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019