* size_t/ssize_t warnings (was: Re: Build regressions/improvements in v3.5-rc5)
@ 2012-07-04 20:17 Geert Uytterhoeven
2012-07-05 1:25 ` Mike Frysinger
2012-07-06 1:12 ` Hans-Peter Nilsson
0 siblings, 2 replies; 5+ messages in thread
From: Geert Uytterhoeven @ 2012-07-04 20:17 UTC (permalink / raw)
To: Jan Kara; +Cc: linux-kernel, Linux-Arch, linux-cris-kernel
On Wed, Jul 4, 2012 at 3:34 PM, Jan Kara <jack@suse.cz> 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?
I haven't tried s390 yet, which also has a non-matching combination (unsigned
long vs. int).
Cris-people: __SIZE_TYPE__ turned out to be hardcoded in my compiler (gcc
4.6.3 from Tony's collection) to unsigned int. Is that correct?
And why do some 32-bit architectures use unsigned long/long?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: size_t/ssize_t warnings (was: Re: Build regressions/improvements in v3.5-rc5) 2012-07-04 20:17 size_t/ssize_t warnings (was: Re: Build regressions/improvements in v3.5-rc5) Geert Uytterhoeven @ 2012-07-05 1:25 ` Mike Frysinger 2012-07-06 1:12 ` Hans-Peter Nilsson 1 sibling, 0 replies; 5+ messages in thread From: Mike Frysinger @ 2012-07-05 1:25 UTC (permalink / raw) To: Geert Uytterhoeven; +Cc: Jan Kara, linux-kernel, Linux-Arch, linux-cris-kernel [-- Attachment #1: Type: Text/Plain, Size: 2305 bytes --] On Wednesday 04 July 2012 16:17:28 Geert Uytterhoeven wrote: > On Wed, Jul 4, 2012 at 3:34 PM, Jan Kara <jack@suse.cz> 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 #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: size_t/ssize_t warnings (was: Re: Build regressions/improvements in v3.5-rc5) 2012-07-04 20:17 size_t/ssize_t warnings (was: Re: Build regressions/improvements in v3.5-rc5) Geert Uytterhoeven 2012-07-05 1:25 ` Mike Frysinger @ 2012-07-06 1:12 ` Hans-Peter Nilsson 2012-07-06 7:18 ` Geert Uytterhoeven 1 sibling, 1 reply; 5+ messages in thread From: Hans-Peter Nilsson @ 2012-07-06 1:12 UTC (permalink / raw) To: geert; +Cc: jack, linux-arch, linux-kernel, linux-cris-kernel > From: Geert Uytterhoeven <geert@linux-m68k.org> > Date: Wed, 4 Jul 2012 22:17:28 +0200 > On Wed, Jul 4, 2012 at 3:34 PM, Jan Kara <jack@suse.cz> 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. Um, no, ssize_t isn't long. Do you mean __kernel_ssize_t? (Or are you looking at cris-axis-elf? ...no, that can't be it, as you see __SIZE_TYPE__ being unsigned int.) > They go away if I make ssize_t int. But ssize_t already is int... N.B. size_t is different between cris-axis-elf and cris-axis-linux-gnu. The former uses the default definition in gcc/defaults.h (long unsigned int) and the latter sets it specifically to "unsigned int", in gcc/config/cris/linux.h (or before 2010-12-09, from config/svr4.h). The ssize_t definition comes from glibc, where it is "int". > __kernel_size_t __kernel_ssize_t > --------------- ---------------- > cris: __SIZE_TYPE__ (unsigned int) long A bit odd; __kernel_ssize_t should probably change to int, to match ssize_t. > Cris-people: __SIZE_TYPE__ turned out to be hardcoded in my compiler (gcc > 4.6.3 from Tony's collection) to unsigned int. Is that correct? Correct, for cris-axis-linux-gnu. > And why do some 32-bit architectures use unsigned long/long? I'd guess from the gcc default. brgds, H-P ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: size_t/ssize_t warnings (was: Re: Build regressions/improvements in v3.5-rc5) 2012-07-06 1:12 ` Hans-Peter Nilsson @ 2012-07-06 7:18 ` Geert Uytterhoeven 2012-07-06 13:45 ` Hans-Peter Nilsson 0 siblings, 1 reply; 5+ messages in thread From: Geert Uytterhoeven @ 2012-07-06 7:18 UTC (permalink / raw) To: Hans-Peter Nilsson; +Cc: jack, linux-arch, linux-kernel, linux-cris-kernel Hi Hans-Peter, On Fri, Jul 6, 2012 at 3:12 AM, Hans-Peter Nilsson <hans-peter.nilsson@axis.com> wrote: >> From: Geert Uytterhoeven <geert@linux-m68k.org> >> Date: Wed, 4 Jul 2012 22:17:28 +0200 > >> On Wed, Jul 4, 2012 at 3:34 PM, Jan Kara <jack@suse.cz> 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. > > Um, no, ssize_t isn't long. Do you mean __kernel_ssize_t? In the kernel, (s)size_t == __kernel_(s)size_t > (Or are you looking at cris-axis-elf? ...no, that can't be it, > as you see __SIZE_TYPE__ being unsigned int.) > >> They go away if I make ssize_t int. > > But ssize_t already is int... > > N.B. size_t is different between cris-axis-elf and > cris-axis-linux-gnu. The former uses the default definition in > gcc/defaults.h (long unsigned int) and the latter sets it > specifically to "unsigned int", in gcc/config/cris/linux.h (or > before 2010-12-09, from config/svr4.h). The ssize_t definition > comes from glibc, where it is "int". OK, so (s)size_t should be (unsigned) int for Linux. >> __kernel_size_t __kernel_ssize_t >> --------------- ---------------- > >> cris: __SIZE_TYPE__ (unsigned int) long > > A bit odd; __kernel_ssize_t should probably change to int, to > match ssize_t. In the kernel, ssize_t == __kernel_ssize_t. Probably the "long" dates from the time people used cris-axis-elf instead of cris-axis-linux-gnu, and "__SIZE_TYPE" from the time people started using cris-axis-linux-gnu? Ah, yes, commit ac505a9fd19c99fdb622fe4896446f995151babc ("[PATCH] CRIS architecture update for 2.5.74") in full-history-linux changed size_t from "unsigned long" to __SIZE_TYPE, but didn't update ssize_t. Probably "signed __SIZE_TYPE" doesn't work? So I guess they should be changed to (explicit) "unsigned int", resp. "int". Or does it make sense to retain __SIZE_TYPE? >> Cris-people: __SIZE_TYPE__ turned out to be hardcoded in my compiler (gcc >> 4.6.3 from Tony's collection) to unsigned int. Is that correct? > > Correct, for cris-axis-linux-gnu. > >> And why do some 32-bit architectures use unsigned long/long? > > I'd guess from the gcc default. OK, that makes sense. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: size_t/ssize_t warnings (was: Re: Build regressions/improvements in v3.5-rc5) 2012-07-06 7:18 ` Geert Uytterhoeven @ 2012-07-06 13:45 ` Hans-Peter Nilsson 0 siblings, 0 replies; 5+ messages in thread From: Hans-Peter Nilsson @ 2012-07-06 13:45 UTC (permalink / raw) To: geert; +Cc: jack, linux-arch, linux-kernel, linux-cris-kernel > From: Geert Uytterhoeven <geert@linux-m68k.org> > Date: Fri, 6 Jul 2012 09:18:52 +0200 > On Fri, Jul 6, 2012 at 3:12 AM, Hans-Peter Nilsson > <hans-peter.nilsson@axis.com> wrote: > > Um, no, ssize_t isn't long. Do you mean __kernel_ssize_t? > > In the kernel, (s)size_t == __kernel_(s)size_t Right, sorry for being slow. > OK, so (s)size_t should be (unsigned) int for Linux. Both the the kernel and userspace, yes. > Probably the "long" dates from the time people used cris-axis-elf > instead of cris-axis-linux-gnu, and "__SIZE_TYPE" from the time > people started using cris-axis-linux-gnu? I don't remember. I have a vague recollection of a change in the distant past. > Ah, yes, commit ac505a9fd19c99fdb622fe4896446f995151babc > ("[PATCH] CRIS architecture update for 2.5.74") in full-history-linux > changed size_t from "unsigned long" to __SIZE_TYPE, but didn't > update ssize_t. Probably "signed __SIZE_TYPE" doesn't work? Well no. Remember here it's "unsigned int": "signed unsigned int" doesn't compile very well. > So I guess they should be changed to (explicit) "unsigned int", resp. > "int". Or does it make sense to retain __SIZE_TYPE? I think it'd make sense to use __SIZE_TYPE__ (don't forget the trailing "__") for *all* targets that don't have a particular difference between kernel and userspace ABI's (notable exceptions being those with use 32-bit user and 64-bit kernel ABIs). Unfortunately, there's no __SSIZE_TYPE__. brgds, H-P ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-07-06 13:46 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-07-04 20:17 size_t/ssize_t warnings (was: Re: Build regressions/improvements in v3.5-rc5) Geert Uytterhoeven 2012-07-05 1:25 ` Mike Frysinger 2012-07-06 1:12 ` Hans-Peter Nilsson 2012-07-06 7:18 ` Geert Uytterhoeven 2012-07-06 13:45 ` Hans-Peter Nilsson
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.