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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMuHMdVJTUF3r=MKzpkvj6y_xdVdw=zEgAy2_wm_hG94jdrhBA@mail.gmail.com>
Date:	Wed, 4 Jul 2012 22:17:28 +0200
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	Jan Kara <jack@...e.cz>
Cc:	linux-kernel@...r.kernel.org,
	Linux-Arch <linux-arch@...r.kernel.org>,
	linux-cris-kernel@...s.com
Subject: size_t/ssize_t warnings (was: Re: Build regressions/improvements in v3.5-rc5)

On Wed, Jul 4, 2012 at 3:34 PM, Jan Kara <jack@...e.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@...ux-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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/