Date: Tue, 24 Feb 1998 06:18:55 +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: <199802232253.RAA10395@delorie.com>
Message-ID: <Pine.OSF.3.95.980224043222.12828A-100000@sable.ox.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk

On Mon, 23 Feb 1998, DJ Delorie wrote:

> I would have done something even simpler:
> 
> @port-note borland Borland's function take only two parameters
> @port-note msc MS
> @portability ansi posix ~borland ~msc
> 
> Note that the port-note lines come before the portability line, and
> each starts with a keyword matching one of the portability keywords.
> Again, ~ means "sort of compatible"; one would expect a note for each ~.
> 
> Putting the notes first means that you can generate the texinfo as
> soon as you see the portability line.

Yes, that's what I had planned to do on reaching the `end' marker.  The
`start' marker was meant to purge the cached notes -- but we can do this
after writing the texinfo of course.

The drawback here is that we're restricted to single-line comments;
perhaps this is generally a good thing (it keeps them brief) but it might
be wise to define a way to write longer comments; say, terminating lines
with `\' to concatenate the next.


We need to define the keywords -- if we're doing a first pass just for the
ANSI and POSIX information then we need only define `ansi' and `posix' for
now.  Others can be added later.  I very much doubt that any notes will be
needed for the ANSI and POSIX portability information -- we could mention
where djgpp's implementation differs, of course, but that would probably
be duplicating other areas of the docs.


I made the tree of web pages to show which parts of the source tree have
been taken by volunteers.  The URL for the top index is: 

http://users.ox.ac.uk/~mert0407/djgpp_docs/

Please tell me if this is not suitable in some way.  We can put
instructions there for reference when we decide on the macro structure. 
I'll implement into mkdoc what DJ suggested for now, supporting the `ansi'
and `posix' targets only.  Others can easily be added later. 


Incidentally I can't make djlsr202 build here, but I haven't tried very
hard yet.  I've only just put the v2.01 zips onto this machine (it's not
mine).  Does the v2.02 library not build properly under v2.01?  The
following errors are coming from src/libc/ansi/locale/lconv.c: 

cc1.exe: warnings being treated as errors
lconv.c:18: warning: initialization makes integer from pointer without a cast
lconv.c:18: initializer element for `__lconv_.frac_digits' is not computable at
load time
lconv.c:27: warning: excess elements in struct initializer after `__lconv_'

As I said, don't take this too seriously, I haven't looked into it at all.
mkdoc compiles quite happily on its own, so there's no problem for me.

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

ko tavla fo la lojban