All of lore.kernel.org
 help / color / mirror / Atom feed
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

             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.