Date: Mon, 04 Jun 2001 21:33:35 +0300
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
Message-Id: <7458-Mon04Jun2001213334+0300-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
CC: djgpp-workers AT delorie DOT com
In-reply-to: <CAEGKOHJKAAFPKOCLHDIMEOCCDAA.tim.van.holder@pandora.be>
Subject: Re: [patch] Second draft: a64l and l64a
References:  <CAEGKOHJKAAFPKOCLHDIMEOCCDAA DOT tim DOT van DOT holder AT pandora DOT be>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
> Date: Mon, 4 Jun 2001 19:30:51 +0200
> 
> Third draft follows:

Thanks.  Now that I _really_ see the text, I have a few more minor
comments:

> long	a64l(const char *s);
> @end example
>
> @subheading Description
>
> This function takes a pointer to a radix-64 representation, with the
> first digit the least significant, and returns the corresponding
> @code{long} value.
>
> If @var{s} contains more than six characters, only the first six are
> used.

Please rename `s' to something more meaningful, like `src'. `s' looks
funny in the Info version.

> @code{a64l()} will scan the string from left to right

The right way to mention a function by name is @code{func}, not
@code{func()}.  The latter looks like a call to the function with no
arguments, which is not what you mean.

> Returns the @code{long} value resulting from the conversion of the contents
> of @var{s}, or 0L if @var{s} is NULL

Both 0L and NULL should have a @code markup.

> to an invalid string (i.e. one not generated by a previous call to
> @code{l64a()}).

@code{l64a}.

> If the result would overflow a signed long, the
> conversion of @samp{/2BIG/} (1144341633L) is returned.

@code{1144341633L}.

> char	*l64a(long value);
> @end example
>
> @subheading Description
>
> This function takes a @code{long} argument and returns a pointer to its
> radix-64 representation.  Negative numbers are not supported.
> @c FIXME: Supporting negative values (or at least unsigned longs) seems
> @c        more logical; should we be POSIX-compliant here?

You can now remove that FIXME, and instead say what did your code do
with negative values.

> diff -rN emptydir/makefile src/libc/posix/stdlib/makefile
> 0a1,7
> > # Copyright (C) 2001 DJ Delorie, see COPYING.DJ for details
> >
> > TOP=../..
> >
> > SRC += a64l.c l64a.c

I think we normally put only one file on a line.  DJ, is that a
standard we should enforce?