From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
> From: "Wilfredo Sanchez" <[EMAIL PROTECTED]>
> > strtoll returns long long and we're returning something else. Maybe I'm
> > too anal.
>
> You aren't being anal... I believe we built this fn upside down.
>
> apr_int64 is a predictable type. I'd suggest we should have added
> apr_strtoi64()
> instead of strtoll (which isn't a portable type in the first place.).
>
> If apr_strtoll exists and longlong == 64 bits, then map that to apr_strtoi64.
> If apr_strtoq exists and quad == 64 bits, then map that to apr_strtoi64.
> If apr_strtol exists and long == 64 bits {64 bit cpu}, then map that to
> apr_strtoi64.
Of course, I meant to write;
if strtoll exists and longlong == 64 bits, then map that to apr_strtoi64.
if strtoq exists and quad == 64 bits, then map that to apr_strtoi64.
if strtol exists and long == 64 bits {64 bit cpu}, then map that to
apr_strtoi64.
> And if we have none of the above, use our own version of apr_strtoi64().
>
> Now we have a useful and predictable type for large math. If apr_strtoll is
> really a 128 bit object on a given 64 bit architecture, using it would be
> massive
> overkill :-)
