Date: Mon, 4 Jun 2001 09:59:06 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Tim Van Holder <tim DOT van DOT holder AT pandora DOT be>
cc: DJGPP-Workers <djgpp-workers AT delorie DOT com>
Subject: Re: [patch] Second draft: a64l and l64a
In-Reply-To: <CAEGKOHJKAAFPKOCLHDICENNCDAA.tim.van.holder@pandora.be>
Message-ID: <Pine.SUN.3.91.1010604095847.14670G-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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


On Sun, 3 Jun 2001, Tim Van Holder wrote:

> Second draft; both functions are now in their own file; a
> test program has been added.

Thanks.

I have two requests, not directly related to these changes:

  - please in the future post the diffs as plain text, not as binary
     attachments;
  - please keep the same Subject line.

> +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?

Posix says that the behavior in that case is unspecified, so we could
do anything we think is reasonable.

I'd think that interpreting the argument as an unsigned long would
produce reasonable results.

What do other implementations, like glibc, do in that case?

> +If the @code{long} type is more than 32 bits in size, only the low-order
> +32 bits are used.

This sentence is redundant and confusing, since our long is 32 bit
wide.

> +@portability !ansi, posix

Please add a @port-note that this is part of the new Posix 1003.1-200x
standard, but not of the old POSIX-1:1996.

> +  printf ("a64l(\"EliRules!\")         -> %ld\n", a64l("EliRules!"));

This line has a bug in it.