apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <ad...@rowe-clan.net>
Subject Re: cvs commit: apr/include apr_strings.h
Date Tue, 30 Jul 2002 15:38:17 GMT
From: "Wilfredo Sanchez" <wsanchez@mit.edu>
>    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, wsanchez@apache.org 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
> 
> 


Mime
View raw message