You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Justin Erenkrantz <je...@apache.org> on 2002/07/25 01:35:51 UTC
Re: cvs commit: apr/include apr_strings.h
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
Re: cvs commit: apr/include apr_strings.h
Posted by Wilfredo Sánchez <ws...@mit.edu>.
No, I don't think so. strtoll returns a long long by definition. That's a platform specific size. apr_int64_t should be a 64 bit integer. Not the same thing, necessarily.
-wsv
On Thursday, July 25, 2002, at 02:03 PM, Justin Erenkrantz wrote:
> My gut feeling is that the apr_intr64_t should defined to be the
> same type as strtoll returns. -- justin
Re: cvs commit: apr/include apr_strings.h
Posted by Justin Erenkrantz <je...@apache.org>.
On Thu, Jul 25, 2002 at 11:38:30AM -0400, Wilfredo Sanchez wrote:
> strtoll returns long long and we're returning something else. Maybe I'm
> too anal.
My gut feeling is that the apr_intr64_t should defined to be the
same type as strtoll returns. -- justin
Re: cvs commit: apr/include apr_strings.h
Posted by "William A. Rowe, Jr." <ad...@rowe-clan.net>.
From: "William A. Rowe, Jr." <ad...@rowe-clan.net>
> From: "Wilfredo Sanchez" <ws...@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 :-)
Re: cvs commit: apr/include apr_strings.h
Posted by Wilfredo Sánchez <ws...@mit.edu>.
Yeah. That's what I get for being slow.
-wsv
On Thursday, August 15, 2002, at 11:11 AM, Ryan Bloom wrote:
> I believe that Will Rowe already changed the function name. Also, you
> don't need to check the size, we already have the logic in APR's
> configure
> script to do that. :-)
Re: cvs commit: apr/include apr_strings.h
Posted by Ryan Bloom <rb...@ntrnet.net>.
On Thu, 15 Aug 2002, [ISO-8859-1] Wilfredo S�nchez wrote:
> I'm going to go ahead and rename the function, so the API is correct.
>
> How do I test for the size of a type with autoconf?
I believe that Will Rowe already changed the function name. Also, you
don't need to check the size, we already have the logic in APR's configure
script to do that. :-)
Ryan
Re: cvs commit: apr/include apr_strings.h
Posted by Wilfredo Sánchez <ws...@mit.edu>.
I'm going to go ahead and rename the function, so the API is correct.
How do I test for the size of a type with autoconf?
-wsv
On Tuesday, July 30, 2002, at 11:38 AM, William A. Rowe, Jr. wrote:
> 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 :-)
Re: cvs commit: apr/include apr_strings.h
Posted by "William A. Rowe, Jr." <ad...@rowe-clan.net>.
From: "Wilfredo Sanchez" <ws...@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
>
>
Re: cvs commit: apr/include apr_strings.h
Posted by Wilfredo Sanchez <ws...@mit.edu>.
strtoll returns long long and we're returning something else. Maybe I'm too anal.
-wsv
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