linux-kernel - Re: Build regressions/improvements in v3.3-rc5 (C lang questions)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 28 Feb 2012 16:08:04 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Randy Dunlap <rdunlap@...otime.net>
Cc:	Geert Uytterhoeven <geert@...ux-m68k.org>,
	linux-kernel@...r.kernel.org, Al Viro <viro@...iv.linux.org.uk>
Subject: Re: Build regressions/improvements in v3.3-rc5 (C lang questions)

On Tue, Feb 28, 2012 at 3:41 PM, Randy Dunlap <rdunlap@...otime.net> wrote:
>
>>   + src/drivers/usb/misc/sisusbvga/sisusb.c: warning: format '%zd' expects type 'signed size_t', but argument 3 has type 'ssize_t':  => 982
>>   + src/fs/ecryptfs/miscdev.c: warning: format '%zd' expects type 'signed size_t', but argument 3 has type 'ssize_t':  => 448, 488
>
> Do the (2) above mean that some platform's gcc is borked?
> (I don't see these on i386 or x86_64.)

Hmm. We had something similar long ago on i386, where the kernel
"size_t" was "unsigned long", but user-mode size_t was "unsigned int"
(or maybe it was the other way around). Anyway, it's obviously
physically the same type, but it would make gcc unhappy because gcc
felt that somebody was doing something bad.

>>   + src/fs/ecryptfs/miscdev.c: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int':  => 433, 433:60
>
> I can see that warning on 32-bit i386 (X86_32), but if I change the
> "%lu" to "%u", it causes this warning on 64-bit x86_64:
>
> fs/ecryptfs/miscdev.c:433:38: warning: format '%u' expects type 'unsigned int', but argument 4 has type 'long unsigned int'
>
> so how is this supposed to be handled?

I suspect that one should be "%zu", because we have

  /* 4 + ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES comes from tag 65 packet format */
  #define MAX_MSG_PKT_SIZE        (PKT_TYPE_SIZE + PKT_CTR_SIZE \
                                 + ECRYPTFS_MAX_PKT_LEN_SIZE \
                                 + sizeof(struct ecryptfs_message) \
                                 + 4 + ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES)

so it's the "sizeof(struct ecryptfs_message)" that makes it a size_t
(everything else is int, if I look at it right, and int+size_t is
going to be size_t)

Of course, if the platform then has the compiler and the kernel
disagreeing about size_t like above, that isn't going to help
anything. But does it fix the x86-32/64 warnings?

                   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/