size_t/ssize_t warnings (was: Re: Build regressions/improvements in v3.5-rc5)

size_t/ssize_t warnings (was: Re: Build regressions/improvements in v3.5-rc5)

[Geert Uytterhoeven]

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

Re: size_t/ssize_t warnings (was: Re: Build regressions/improvements in v3.5-rc5)

[Mike Frysinger]

[-- 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 --]

Re: size_t/ssize_t warnings (was: Re: Build regressions/improvements in v3.5-rc5)

[Hans-Peter Nilsson]

> 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

Re: size_t/ssize_t warnings (was: Re: Build regressions/improvements in v3.5-rc5)

[Geert Uytterhoeven]

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

Re: size_t/ssize_t warnings (was: Re: Build regressions/improvements in v3.5-rc5)

[Hans-Peter Nilsson]

> 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