Mail Archives: djgpp-workers/2001/06/04/05:53:11
> I have two requests, not directly related to these changes:
>
> - please in the future post the diffs as plain text, not as binary
> attachments;
I've had problems before where patches couldn't be applied due to line
breaks added by the mail agent, so I've taken to sending diffs as
attachments if they're meant to be applied, instead of just reviewed.
> - please keep the same Subject line.
Will do in the future.
>
> > +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.
I was talking about possibly changing the signatures to use unsigned
long, but I suppose that simply treating them as such would be OK.
> > +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.
Will drop it.
> > +@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.
Will do.
> > + printf ("a64l(\"EliRules!\") -> %ld\n", a64l("EliRules!"));
>
> This line has a bug in it.
Hmmm - where exactly? I see nothing wrong with it :-)
- Raw text -