On Wednesday 04 July 2012 16:17:28 Geert Uytterhoeven wrote: > On Wed, Jul 4, 2012 at 3:34 PM, Jan Kara <jack@xxxxxxx> wrote: > >> + fs/quota/quota_tree.c: warning: format '%zd' expects argument of > >> type 'signed size_t', but argument 4 has type 'ssize_t' [-Wformat]: > >> => 372:4 + fs/quota/quota_v2.c: warning: format '%zd' expects > >> argument of type 'signed size_t', but argument 5 has type 'ssize_t' > >> [-Wformat]: => 66:92 > > > > These really look like false positives (there are quite a few of this > > > > kind). Can we possibly silence them? > > These 2 warnings happen on cris only, because size_t is unsigned int and > ssize_t is (signed) long. They go away if I make ssize_t int. > > I had a look at the various definitions of size_t and ssize_t: > > __kernel_size_t > __kernel_ssize_t --------------- ---------------- > > generic 32-bit: unsigned int int > generic 64-bit: __kernel_ulong_t (unsigned long) > __kernel_long_t (long) > > Exceptions: > > avr32: unsigned long long > blackfin: unsigned long long > cris: __SIZE_TYPE__ (unsigned int) long > mn10300/__GNUC__ == 4: unsigned int signed int > mn10300/__GNUC__ != 4: unsigned long signed long > s390 (32-bit): unsigned long int > x32: __kernel_ulong_t (unsigned long long) > __kernel_long_t (long long) > > On cris, I get the warning if ssize_t != int. > Whether size_t is unsigned int or unsigned long doesn't matter. > So it's not just a mismatch between int and long. > > I also tried blackfin, which has matching unsigned long/long, and it > doesn't give the warning. Presumably the toolchain has size_t hardcoded to > long for printf-style format checking? well, every gcc arch has to declare a type for size_t. on Blackfin, we picked: gcc/config/bfin/bfin.h:/* what is the 'type' of size_t */ gcc/config/bfin/bfin.h-#define SIZE_TYPE "long unsigned int" grep shows that many other arches do the same -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
