lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: [lucy-dev] [VOTE] Apache Lucy (incubating) 0.2.2 RC 1
Date Thu, 03 Nov 2011 03:05:23 GMT
D00d relax, warnings aren't errors unless you
want them to be.  Gcc is wonderfully inconsistent
between versions and has always been that way
(assuming that's the culprit here).

I don't support writing around compiler warnings,
especially not from gcc, unless the compiler is
actually generating the wrong result as a consequence.

>From: Marvin Humphrey <>
>Sent: Wednesday, November 2, 2011 10:52 PM
>Subject: Re: [lucy-dev] [VOTE] Apache Lucy (incubating) 0.2.2 RC 1
>On Tue, Nov 01, 2011 at 10:15:09AM -0700, Chris Hostetter wrote:
>> 3) A few misc warnings popped up during C compilation...
>Grr.  These are annoying.
>> /home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2/core/Lucy/Object/CharBuf.c:259:
warning: format ‘%lld’ expects type ‘long long int’, but argument 3 has type ‘int64_t’
>The compiler is crying wolf.
>It's not important to distinguish between a signed 64-bit integer type named
>"long long int" and another signed 64-bit integer type named "int64_t" when
>passing arguments to *printf.  The compiler ought to be smart enough to figure
>out that those are equivalent.
>> /home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2/core/Lucy/Util/Memory.c:28:
warning: format ‘%llu’ expects type ‘long long unsigned int’, but argument 3 has type
>Here's the line in question:
>    fprintf(stderr, "Can't malloc %" U64P " bytes.\n", (uint64_t)count);
>The variable "count" is indeed a "size_t".  However, it is specifically being
>cast to a uint64_t so that fprintf will get a 64-bit integer to go with that
>64-bit format string specifier regardless of whether size_t is 32 bits or
>64 bits.
>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.
>For the second case, we could theoretically create a temporary uint64_t
>variable and stop the compiler from complaining about size_t.  But I'm almost
>positive the compiler would then whine about a uint64_t not being the "long
>long unsigned int" it wants to see paired with "%llu".
>Marvin Humphrey
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message