apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: svn commit: r553679 - /apr/apr/trunk/strings/apr_snprintf.c
Date Mon, 09 Jul 2007 11:00:45 GMT
On Fri, Jul 06, 2007 at 08:51:38AM -0300, Davi Arnaut wrote:
> Joe Orton wrote:
> > Are these wide_int -> int32_t changes correct?  wide_int was long before 
> > and is now always 32-bit.
> When I made the patch, it seemed to be correct because the format checks
> using IS_LONG were based upon APR_INT64_T_FMT.

Ah, OK.  It looks a bit counter-intuitive but it seems to work OK, so no 

> > Also the *INT32_MAX types are from C99 stdint.h which might not be present.
> Good catch, I guess we could use *INT_MAX. This begs the question: why
> don't we have APR_*INT32_MIN/MAX? Should be pretty straight forward:

It's not the first time the question has been asked... no objection to 
adding such anyway.  Note the private definition in apr_private_common.h 
would need to be removed.

> defaults:
> #define APR_UINT32_MAX	0xffffffffU
> #define APR_UINT64_MAX  0xffffffffffffffffULL
> autoconf logic:

Having autoconf tests to calculate values which are mathematical 
constants seems like... overkill :) I would just add the #defines as 
above; at most doing:

#define APR_UINT32_MAX 0xetc

note using APR_*INT64_C() for the 64-bit constants is a good idea.


View raw message