Date: Tue, 24 Feb 1998 16:48:45 -0800 (PST)
Message-Id: <199802250048.QAA28537@adit.ap.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: George Foot <george DOT foot AT merton DOT oxford DOT ac DOT uk>, DJ Delorie <dj AT delorie DOT com>
From: Nate Eldredge <eldredge AT ap DOT net>
Subject: Re: Suggestion: Portability section for libc docs
Cc: djgpp-workers AT delorie DOT com
Precedence: bulk

At 06:18  2/24/1998 +0000, George Foot wrote:
>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.

IMHO, this is important. Being limited to one line in the comment would be
very annoying.
>
>
>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.
>
Perhaps I'm confused, but from DJ's example it looked as though it would be
possible for the "keywords" to be non-magical. That is, any word could be
used as a header instead of "ANSI" or "Borland", etc. I'd like to suggest we
do that, so we don't have to hack `mkdoc' again each time we want to add
something.

So the keywords would only be "key" in the sense that we'd standardized on
them for consistency, not that there's something special about them.

>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_'

I saw this too. I suspect it's due to mixing 2.02 source with the 2.01
headers. Although I haven't tried it, I suspect that installing djdev202
first will fix it.

Nate Eldredge
eldredge AT ap DOT net