Date: Wed, 30 May 2001 20:30:47 +0300 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: "Tim Van Holder" Message-Id: <7458-Wed30May2001203047+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: Subject: Re: First draft: a64l/l64a References: 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" > Date: Tue, 29 May 2001 22:14:31 +0200 > > When looking through the POSIX draft Mark pointed out, I > saw a pair of functions mentioned that wouldn't be too > hard to implement, so I did. Thanks. A few comments: > --- nul Tue May 29 22:09:11 2001 > +++ radix64.c Tue May 29 22:04:48 2001 Please use /dev/null; nul won't work on Unix. Also, please divide the source into two separate files. There's no need to gratuitously bloat user programs with functions they don't call. > +#ifdef TEST > +#include > + > +int > +main(void) > +{ > + printf ("a64l(\"/.\") -> %ld\n", a64l("/.")); > + printf ("a64l(\"DJGPP\") -> %ld\n", a64l("DJGPP")); This is best put on a separate file in the tests directory (to become part of djtstNNN.zip). > +The result of @code{a64l()} is undefined if @var{s} is a null pointer, or > +the string it points to was not generated by a previous call to > +@code{l64a()}. At least in the case of a NULL pointer I think the result is pretty much known in advance. In general, ``result is undefined'' is lawyerspeak; in our docs I think we should tell what will happen if we know that. > +This function takes a @code{long} argument and returns a pointer to its > +radix-64 representation. The result is undefined if @var{value} is > +negative. Same here. Finally, I'd suggest to mention base-64 somewhere in the docs, since someone might not realize what are you talking about.