From: Hans-Peter Nilsson <hans-peter.nilsson@axis.com>
To: geert@linux-m68k.org
Cc: jack@suse.cz, linux-arch@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-cris-kernel@axis.com
Subject: Re: size_t/ssize_t warnings (was: Re: Build regressions/improvements in v3.5-rc5)
Date: Fri, 6 Jul 2012 03:12:36 +0200 [thread overview]
Message-ID: <201207060112.q661CaG4002389@ignucius.se.axis.com> (raw)
In-Reply-To: <CAMuHMdVJTUF3r=MKzpkvj6y_xdVdw=zEgAy2_wm_hG94jdrhBA@mail.gmail.com> (message from Geert Uytterhoeven on Wed, 4 Jul 2012 22:17:28 +0200)
> 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
next prev parent reply other threads:[~2012-07-06 1:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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=201207060112.q661CaG4002389@ignucius.se.axis.com \
--to=hans-peter.nilsson@axis.com \
--cc=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox