Not a bug : Fix some compile warnings.

[hasse69]

gcc reports some warnings...

gcc -std=gnu99 -o mkr2i mkr2i.o -rdynamic -L../unrar  -ldl -lrt 
rar2fs.c: In function ‘lrelease’:
rar2fs.c:1248:9: warning: format ‘%p’ expects argument of type ‘void *’, but argument 5 has type ‘uint64_t’ [-Wformat=]
         printd(3, "(%05d) %s [%-16p]\n", getpid(), "FREE", fi->fh);
         ^
mv -f .deps/filecache.Tpo .deps/filecache.Po
mv -f .deps/iobuffer.Tpo .deps/iobuffer.Po
rar2fs.c: In function ‘rar2_release’:
rar2fs.c:3745:9: warning: format ‘%p’ expects argument of type ‘void *’, but argument 5 has type ‘uint64_t’ [-Wformat=]
         printd(3, "(%05d) %s [%-16p]\n", getpid(), "RELEASE", fi->fh);
         ^
mv -f .deps/optdb.Tpo .deps/optdb.Po
rar2fs.c:3797:17: warning: format ‘%p’ expects argument of type ‘void *’, but argument 5 has type ‘uint64_t’ [-Wformat=]
                 printd(3, "(%05d) %s [%-16p]\n", getpid(), "FREE", fi->fh);
                 ^

That occurs because file handle(fh) is just integer, but uses "pointer" format to print that.

This patch can fix this. It just replaces "%p" to PRIX64 to ensure hex output - fh declares as uint64_t in fuse_common.h on my system.

Original issue reported on code.google.com by jyhpsycho on 2014-02-23

[hasse69]

Already fixed these since I had to compile with --enable-debug for trouble shooting
issue28. But thanks anyway :)

Original issue reported on code.google.com by hans.beckerus on 2014-02-23 03:09:04

[hasse69]

Original issue reported on code.google.com by hans.beckerus on 2014-02-23 03:10:23

• Labels added: Type-Enhancement, Priority-Low
• Labels removed: Type-Defect, Priority-Medium

[hasse69]

If there's some issue on 32-bit systems - fh declares uint32_t under that systems -,
that should be patched like this...

Original issue reported on code.google.com by jyhpsycho on 2014-02-23 03:11:07

---

- _Attachment: [rar2fs-fix-warnings-ptr.patch](https://storage.googleapis.com/google-code-attachments/rar2fs/issue-30/comment-3/rar2fs-fix-warnings-ptr.patch)_

[hasse69]

No, AFAIK fi->fh is not platform dependant. It is declared as a uint64_t also on 32-bit
architectures.

Original issue reported on code.google.com by hans.beckerus on 2014-02-23 03:15:05

[hasse69]

(No text was entered with this change)

Original issue reported on code.google.com by hans.beckerus on 2014-02-23 03:32:54

[hasse69]

(No text was entered with this change)

Original issue reported on code.google.com by hans.beckerus on 2014-02-23 16:56:10