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 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.