[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0dcf23d3-09d5-802f-d9cc-2900d2cdaa53@mkarcher.dialup.fu-berlin.de>
Date: Tue, 24 Jan 2023 23:05:00 +0100
From: Michael Karcher <kernel@...rcher.dialup.fu-berlin.de>
To: Geert Uytterhoeven <geert@...ux-m68k.org>,
Randy Dunlap <rdunlap@...radead.org>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux-sh list <linux-sh@...r.kernel.org>,
Segher Boessenkool <segher@...nel.crashing.org>,
Rich Felker <dalias@...c.org>,
Yoshinori Sato <ysato@...rs.sourceforge.jp>,
John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>
Subject: Re: [PATCH v4 1/1] arch/sh: avoid spurious sizeof-pointer-div warning
Am 24.01.2023 um 14:07 schrieb Geert Uytterhoeven:
> On Mon, Jan 23, 2023 at 8:40 PM Randy Dunlap <rdunlap@...radead.org> wrote:
>> I'm curious how you generated this patch.
I'm currently using Thunderbird in a GUI environment as my only mail client,
and I pasted just the +/- lines of the patch into the pre-composed mail. The
copious amounts of bad mails I generated this way are a good point to set up
git-send-email in my linux environment to avoid bad patches / badly formatted
mails
> Reviewed-by: Geert Uytterhoeven <geert+renesas@...der.be>
> Tested-by: Geert Uytterhoeven <geert+renesas@...der.be>
Thanks!
> Note that I didn't receive v5 (neither did lore), only Adrian's reply.
And that is another issue of my mail setup. Thunderbird is set to
automatically decide on HTML or plaintext only, and as soon as I switch to
"preformatted text", Thunderbird concludes that the mail contains
significant formatting, and defaults to multipart/alternative with HTML and
plain text. Mails of this type obviously get dropped by vger.kernel.org.
On the other hand, if I *don't* select "preformatted text", but use the
default settings "paragraph" or "normal text", there will be no HTML part
(which is good), but spaces will be transformed to non-breaking spaces.
I verified that the version of the v5 mail I just sent to all recipients
I already had on the v1 mail (so that doesn't include Geert, but both lkml
and linux-sh) now fulfills all requirements. I verified that it appeared
at lore on linux-sh.
>>> -#define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 : sizeof(a)/sizeof(*a)
>>> +#define _INTC_SIZEOF_OR_ZERO(a) (_Generic(a, \
>>> + typeof(NULL): 0, \
>>> + default: sizeof(a)))
> _INTC_SIZEOF_OR_ZERO() might be useful in general.
Indeed. Feel free to move it (using a name that doesn't start with _INTC) to
a more general linux header file.
On the other hand, having a sizeof-like macro that fails to work on void*
(what NULL is), but works on all other types might be confusing and
error-prone. You likely want to further type constrain it, and you need to
parenthesize the argument "a" if you generalize this macro.
The version suggested by Jakub Jelinek in the gcc bugtracker has the advantage
of verifying that the void* parameter is indeed the compiletime constant NULL,
but it has the disadvantage that the expression used to verify that NULL was
passed is involving pointers (it needs to, as NULL is a pointer), and an
expression involving pointers is not an integral constant expression according
to C90 rules, so the compile-time assert using a possibly negatively sized
array is rejected by -Wvla, which is enabled in the kernel source code by
default.
Kind regards,
Michael Karcher
Powered by blists - more mailing lists