apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Poirier <poir...@pobox.com>
Subject Re: [PATCH] Re: [PATCH] %lld support in apr_snprintf()
Date Fri, 17 Dec 2010 11:58:16 GMT
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:

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

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


View raw message