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:47:47 GMT
From: "William A. Rowe, Jr." <admin@rowe-clan.net>
> 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.

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 :-)



Mime
View raw message