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.
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 :-)
Bill
> On Wednesday, July 24, 2002, at 07:35 PM, Justin Erenkrantz wrote:
>
> > On Wed, Jul 24, 2002 at 11:31:57PM -0000, [EMAIL PROTECTED] wrote:
> >> @@ -233,17 +233,17 @@
> >> }
> >> #endif
> >>
> >> -APR_DECLARE(long long) apr_strtoll(const char *buf, char **end, int
> >> base)
> >> +APR_DECLARE(apr_int64_t) apr_strtoll(const char *buf, char **end, int
> >> base)
> >> {
> >> #if (APR_HAVE_STRTOLL)
> >> - return strtoll(buf, end, base);
> >> + return (apr_int64_t)strtoll(buf, end, base);
> >
> > Do we really need a cast here? -- justin
>
>
