From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Jan Kara <jack@suse.cz>
Cc: linux-kernel@vger.kernel.org,
Linux-Arch <linux-arch@vger.kernel.org>,
linux-cris-kernel@axis.com
Subject: size_t/ssize_t warnings (was: Re: Build regressions/improvements in v3.5-rc5)
Date: Wed, 4 Jul 2012 22:17:28 +0200 [thread overview]
Message-ID: <CAMuHMdVJTUF3r=MKzpkvj6y_xdVdw=zEgAy2_wm_hG94jdrhBA@mail.gmail.com> (raw)
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
next reply other threads:[~2012-07-04 20:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-04 20:17 Geert Uytterhoeven [this message]
2012-07-05 1:25 ` size_t/ssize_t warnings (was: Re: Build regressions/improvements in v3.5-rc5) 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMuHMdVJTUF3r=MKzpkvj6y_xdVdw=zEgAy2_wm_hG94jdrhBA@mail.gmail.com' \
--to=geert@linux-m68k.org \
--cc=jack@suse.cz \
--cc=linux-arch@vger.kernel.org \
--cc=linux-cris-kernel@axis.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.