All of lore.kernel.org
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Hans-Peter Nilsson <hans-peter.nilsson@axis.com>
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 09:18:52 +0200	[thread overview]
Message-ID: <CAMuHMdU+GdPnEgdJJFezPET5y4Q0-fqBJZZZ1cNZyPOG6_d4Ug@mail.gmail.com> (raw)
In-Reply-To: <201207060112.q661CaG4002389@ignucius.se.axis.com>

Hi Hans-Peter,

On Fri, Jul 6, 2012 at 3:12 AM, Hans-Peter Nilsson
<hans-peter.nilsson@axis.com> wrote:
>> 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?

In the kernel, (s)size_t == __kernel_(s)size_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".

OK, so (s)size_t should be (unsigned) int for Linux.

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

In the kernel, ssize_t == __kernel_ssize_t.

Probably the "long" dates from the time people used cris-axis-elf
instead of cris-axis-linux-gnu, and "__SIZE_TYPE" from the time
people started using cris-axis-linux-gnu?
Ah, yes, commit ac505a9fd19c99fdb622fe4896446f995151babc
("[PATCH] CRIS architecture update for 2.5.74") in full-history-linux
changed size_t from "unsigned long" to __SIZE_TYPE, but didn't
update ssize_t. Probably "signed __SIZE_TYPE" doesn't work?

So I guess they should be changed to (explicit) "unsigned int", resp.
"int". Or does it make sense to retain __SIZE_TYPE?

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

OK, that makes sense.

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-06  7: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
2012-07-06  7:18   ` Geert Uytterhoeven [this message]
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=CAMuHMdU+GdPnEgdJJFezPET5y4Q0-fqBJZZZ1cNZyPOG6_d4Ug@mail.gmail.com \
    --to=geert@linux-m68k.org \
    --cc=hans-peter.nilsson@axis.com \
    --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.