compilation print format warnings and errors

[Joe Izraelevitz]

Under gcc 4.8.1 on Lubuntu, (commit 9cfb7c36), I have compilation issues.

After running "make cstyle" then "make" the make command throws a lot of warnings regarding print formatting, e.g.
btt.c:768:3: error: format ‘%zu’ expects argument of type ‘size_t’, but argument 6 has type ‘uint64_t’ [-Werror=format=]

Since the standard compilation includes the Werror flag, these warnings get upgraded to errors and the build fails...
Obviously, I'd rather not start touching the code before I get a working compilation.

I'm assuming this is by design as part of the (ongoing?) redesign mentioned last week.  Is there a stable version I should roll back to?  Or am I just doing something dumb? 

Joe

[Zach Brown]

On Mon, Oct 27, 2014 at 03:09:36PM -0700, Joe Izraelevitz wrote:
> Under gcc 4.8.1 on Lubuntu, (commit 9cfb7c36), I have compilation issues.
>
> After running "make cstyle" then "make" the make command throws a lot of
> warnings regarding print formatting, e.g.
> btt.c:768:3: error: format ‘%zu’ expects argument of type ‘size_t’, but
> argument 6 has type ‘uint64_t’ [-Werror=format=]

Are you building on a 32bit target? I'm guessing so, I was only able to
get the errors with:

--- a/src/Makefile.inc
+++ b/src/Makefile.inc
@@ -67,7 +67,7 @@ vpath %.c ..
vpath %.h .. ../include
INCS = -I.. -I../include

-CFLAGS += -std=gnu99 -Wall -Werror
+CFLAGS += -std=gnu99 -Wall -Werror -m32
LDFLAGS = -Wl,-z,relro

LN = ln

Print formating is easy (if annoying), but bugs like:

--- a/src/btt_layout.h
+++ b/src/btt_layout.h
@@ -113,7 +113,7 @@ struct btt_flog {
* BTT layout properties...
*/
#define BTT_MIN_SIZE ((size_t)(1ul << 20) * 512)
-#define BTT_MAX_ARENA ((size_t)(1ul << 39)) /* 512GB per arena */
+#define BTT_MAX_ARENA (1ull << 39) /* 512GB per arena */
#define BTT_MIN_LBA 512
#define BTT_INTERNAL_LBA_ALIGNMENT 256
#define BTT_DEFAULT_NFREE 256

Make me bet that no one has worked with the code in 32bit yet.

I guess the short answer is to use 64bit targets? :)

- z

[Czurylo, Krzysztof]

Seems like you're trying to compile it for 32-bit platform, are you?

Well, maybe it's not clearly stated in README and/or manpage, but 32-bit Linux is not our target. For now, we're focused on 64-bit platforms.

So, try to use 64-bit platform/compiler...

 

Anyway, I've noticed this problem already...

Obviously, "%zu" should not be used for "uint64_t" (%llu" would be better, I guess), but the actual problem is with "off_t", which - depending on the platform - can be "%ld" or "%lld".

Hmmm, seems like the best option is the explicit casting to "long long int" and "%lld" format.

 

I'll try to prepare an appropriate patch tomorrow.

 

Thans for feedback,

 

krzycz

--
You received this message because you are subscribed to the Google Groups "pmem" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pmem+uns...@googlegroups.com.
To post to this group, send email to pm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pmem/2e079e22-0cc5-41fe-be51-33fc6bf85e73%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
ul. S&#322owackiego 173 | 80-298 Gda&#324sk | S&#261d Rejonowy Gda&#324sk P&#243&#322noc | VII Wydzia&#322 Gospodarczy Krajowego Rejestru S&#261dowego - KRS 101882 | NIP 957-07-52-316 | Kapita&#322 zak&#322adowy 200.000 PLN.

Ta wiadomo&#347&#263 wraz z za&#322&#261cznikami jest przeznaczona dla okre&#347lonego adresata i mo&#380e zawiera&#263 informacje poufne. W razie przypadkowego otrzymania tej wiadomo&#347ci, prosimy o powiadomienie nadawcy oraz trwa&#322e jej usuni&#281cie; jakiekolwiek przegl&#261danie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.

[Zach Brown]

On Mon, Oct 27, 2014 at 10:48:37PM +0000, Czurylo, Krzysztof wrote:
> Seems like you're trying to compile it for 32-bit platform, are you?
>
> Well, maybe it's not clearly stated in README and/or manpage, but 32-bit Linux
> is not our target. For now, we're focused on 64-bit platforms.

*nod*

> Anyway, I've noticed this problem already...
>
> Obviously, "%zu" should not be used for "uint64_t" (%llu" would be better, I
> guess), but the actual problem is with "off_t", which - depending on the
> platform - can be "%ld" or "%lld".
>
> Hmmm, seems like the best option is the explicit casting to "long long int" and
> "%lld" format.

Being a kernel guy, I'm partial to using shorter types like u64 and
making them always long long so that %llu can be used without casts.
uint64_t/%"PRIu64" has always seemed like a cruel joke.

off_t is annoying, for sure. With no 'z' or inttypes.h specifiers
you're stuck with casting, as far as I know.

We're almost in a brave new world where you can add format specifiers,
but gcc doesn't know how to parse them when checking for errors:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781

- z

[Joe Izraelevitz]

Yep - on 32 bit.  I'll switch.  Thanks for the quick replies.

Joe