lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: [lucy-dev] [VOTE] Apache Lucy (incubating) 0.2.2 RC 1
Date Thu, 03 Nov 2011 14:23:35 GMT
On Wed, Nov 02, 2011 at 08:51:46PM -0700, Nathan Kurz wrote:
> On Wed, Nov 2, 2011 at 7:52 PM, Marvin Humphrey <> wrote:
> > Here's the line in question:
> >
> >    fprintf(stderr, "Can't malloc %" U64P " bytes.\n", (uint64_t)count);
> >
> > Thanks for pointing these warnings out, Hoss.  I would like to silence them,
> > but it's hard to do that portably -- for instance, we can't cast to "long long
> > int" because it's not there on all systems.
> I do believe that we should compile warning free, but I'm not sure I'm
> understanding the issue here.  Hoss's error is on GCC, we're
> targetting C99, and you already have U64P defined as a macro?

Our dialect is the intersection of C99 and C++, which gets us nice things
like mixed declarations and code and double-slash comments, but does not
guarantee the availablility of "%zu".

> Wouldn't "%zu" work fine without the cast?  I think it's standard C99 at
> this point, and not just a GCC extension.  But if you've got a macro anyway,
> it should be fine to use.  Historically, the reason to avoid it was support
> under Windows, where you would have to use "%Iu" (that's a capital 'i', not
> a lower case 'L').
> Or am I missing another layer of complexity?

"%zu" is indeed C99.

OK, this isn't so hard to solve after all.  We can just have Charmonizer
define a macro which defines the size_t print format in a way which both works
for MSVC (in C++ mode) and which doesn't make GCC squeal.

Marvin Humphrey

View raw message