apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: [PATCH] Re: [PATCH] %lld support in apr_snprintf()
Date Fri, 17 Dec 2010 12:29:18 GMT

On Dec 17, 2010, at 6:58 AM, Dan Poirier wrote:

> On Thu. 2010-12-16 at 03:35 PM EST, Jim Jagielski <jim@jaguNET.com> wrote:
>> On Dec 16, 2010, at 3:23 PM, Jim Jagielski wrote:
>>> Here is my idea... currently, when looking for sizes
>>> and formats for off_t, we do from smallest to largest
>>> (int -> long -> long long). We also do the same when
>>> checking apr_int64_t as well...
>>> What if we do the reverse? What if instead of finding
>>> the smallest that is the right size, we find the first,
>>> starting with the longest?
>>> I'm trying that out now, so we'll see...
>> hey.... this looks promising! With this, APR and httpd
>> builds with no "warning ... expect" errors at all, and
>> passes the test framework, no matter is built forcing 64bit,
>> 32bit *or universal*!
>> Please check over because I hope to commit sometimes
>> tomorrow!!
> I think universal is going to take more work.  Right now, configure runs
> little test programs once, either 32-bit or 64-bit, and records the
> results in apr.h and other places.  Those answers can't always be right
> for both 32-bit and 64-bit.  The header files will need to have some
> conditionals to use the right answers depending on which way the code is
> being compiled.  Other programs obviously manage to do this. Maybe it's
> simpler than it seems to me.
> Example: if I build universal (CFLAGS='-arch i386 -arch x86_64'), the compile
> fails in strings/apr_snprintf.c:

Hmmm.... I cannot recreate that (at least on the 1.4.x branch).
What happens if you just blank out CFLAGS? The default
is for universal...

> strings/apr_snprintf.c: In function ‘conv_os_thread_t’:
> strings/apr_snprintf.c:500: error: duplicate case value
> strings/apr_snprintf.c:498: error: previously used here
> strings/apr_snprintf.c: In function ‘conv_os_thread_t_hex’:
> strings/apr_snprintf.c:671: error: duplicate case value
> strings/apr_snprintf.c:669: error: previously used here
> because sizeof(apr_int32_t) is apparently the same as
> sizeof(apr_int64_t), which is obviously wrong.  Here's apr.h:
> typedef  int             apr_int32_t;
> typedef  unsigned int    apr_uint32_t;
> typedef  long            apr_int64_t;
> typedef  unsigned long   apr_uint64_t;
> (What's interesting is that if I build just 32-bit or just 64-bit, that
> compile does not fail.  I don't know why; maybe the tests that set
> apr_int32_t and apr_int64_t respond in different ways to universal
> builds.)
> But all this is beside the point of the current issue.  I think if we
> can get apr to build & test okay separately, 32-bit or 64-bit, that'll
> be real worthwhile progress.  Universal can wait for another day :-)
> Dan

View raw message