public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
To: Quentin Schulz <quentin.schulz@cherry.de>
Cc: Quentin Schulz <foss+uboot@0leil.net>,
	 Tom Rini <trini@konsulko.com>, Simon Glass <sjg@chromium.org>,
	 u-boot@lists.denx.de
Subject: Re: [PATCH] cmd/mem.c: fix undefined behavior in mem cmp
Date: Mon, 30 Sep 2024 11:54:29 +0200	[thread overview]
Message-ID: <8734lhlb56.fsf@prevas.dk> (raw)
In-Reply-To: <73723830-60be-4968-bb88-f518e493361f@cherry.de> (Quentin Schulz's message of "Mon, 30 Sep 2024 10:38:35 +0200")

Quentin Schulz <quentin.schulz@cherry.de> writes:

> Hi Rasmus,
>
> On 9/27/24 8:56 PM, Rasmus Villemoes wrote:
>> Quentin Schulz <foss+uboot@0leil.net> writes:
>> 
>>> From: Quentin Schulz <quentin.schulz@cherry.de>
>>>
>>> My linter complains that "When using void pointers in calculations, the
>>> behaviour is undefined".
>>>
>>> GCC does say that "In GNU C, addition and subtraction operations are
>>> supported on pointers to void"[1] but this hints at this only being
>>> supported in the GNU flavor of C. And I assume U-Boot may want to be
>>> compiled with clang/llvm?
>>>
>>> Let's fix that warning by casting the void pointer to a u8 pointer since
>>> the size variable unit is byte.
>>>
>>> [1] https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html
>>>
>> No, let's please not. Try enabling -Wpointer-arith and see how much
>> churn that would require all over the tree (doing it in this one place
>> would be pointless), and all the casts would make the code much much
>> harder to read.
>> 
>
> That alone is not a justification.
>
>> We do rely on lots of gcc extensions, and Clang has documented that it
>> "aims to support a broad range of GCC extensions". Arithmetic on void is
>> one of them, and that's not going to go away.
>> 
>
> But this very well could/is.
>
> 1) is there a way to tell Clang that we want to follow this GNU
> extension for that case?

For that case? No. But we do -std=gnu11 which is understood by both
compilers and tells clang that we do use GNU extensions. I don't know
the clang internals, but I strongly suspect that that flag would make
sure that defaults for various warnings are set appropriately (that is,
not warning for something which is explicitly guaranteed to work in GNU
C).

> Is that the default?

In our build, yes. See CSTD_FLAG. But both gcc and clang default to some
-std=gnuXX, with the exact value of XX depending on compiler version.

> 2) do we document somewhere the GNU C extensions we use on the whole
> tree?

Not that I know of explicitly, but CSTD_FLAG=-std=gnu11 kind of
documents that gnu extensions are used.

Note that typeof() and inline asm() statements are also gnu extensions
that we make heavy use of, as are various __attribute__(()), statement
expressions (i.e. ({ stuff; }) ), omitting the middle expression in ?: ,
special handling of token paste ## after a comma, case ranges 'case LOW
... HIGH', etc. etc. 

>
> 3) is anyone aware of a way to silence some specific warnings at the
> project level so that clang takes care of it so that linters use those
> settings so we avoid people sending more commits for that "issue"?

I don't quite parse that sentence. Are you saying that your linter is
being invoked by clang, and you want clang to pass certain options to
the linter to disable certain warnings? I don't know how clang could
know that options those would be.

Rasmus



  reply	other threads:[~2024-09-30  9:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-27 16:37 [PATCH] cmd/mem.c: fix undefined behavior in mem cmp Quentin Schulz
2024-09-27 18:56 ` Rasmus Villemoes
2024-09-30  8:38   ` Quentin Schulz
2024-09-30  9:54     ` Rasmus Villemoes [this message]
2024-10-14 13:13       ` Quentin Schulz

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=8734lhlb56.fsf@prevas.dk \
    --to=rasmus.villemoes@prevas.dk \
    --cc=foss+uboot@0leil.net \
    --cc=quentin.schulz@cherry.de \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox