[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1c4aa5ce-df78-b69c-0dc2-2859b0c1c3df@linaro.org>
Date: Wed, 16 Aug 2023 07:34:53 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Justin Stitt <justinstitt@...gle.com>
Cc: Linus Walleij <linus.walleij@...aro.org>,
Miquel Raynal <miquel.raynal@...tlin.com>,
Richard Weinberger <richard@....at>,
Vignesh Raghavendra <vigneshr@...com>,
Nathan Chancellor <nathan@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Tom Rix <trix@...hat.com>,
linux-arm-kernel@...ts.infradead.org,
linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
llvm@...ts.linux.dev
Subject: Re: [PATCH] mtd: maps: fix -Wvoid-pointer-to-enum-cast warning
On 16/08/2023 01:06, Justin Stitt wrote:
> On Tue, Aug 15, 2023 at 2:15 PM Krzysztof Kozlowski
> <krzysztof.kozlowski@...aro.org> wrote:
>>
>> On 15/08/2023 23:11, Justin Stitt wrote:
>>> When building with clang 18 I see the following warning:
>>> | drivers/mtd/maps/physmap-versatile.c:209:25: warning: cast to smaller
>>> | integer type 'enum versatile_flashprot' from 'const void *' [-Wvoid-pointer-to-enum-cast]
>>> | 209 | versatile_flashprot = (enum versatile_flashprot)devid->data;
>>>
>>> This is due to the fact that `devid->data` is a void* while `enum
>>> versatile_flashprot` has the size of an int. This leads to truncation
>>> and possible data loss.
>>
>> Cast does not solve truncation. This part of commit msg suggests that
>> you actually fix real issue... and that is an issue, because then
>> AUTOSEL will grab it. This is just compiler warning silencing and rather
>> coding standard correctness, no real fix, so please drop the sentence.
> OK, makes sense about this not technically solving an issue and thus
> AUTOSEL may pick it up. Can you elaborate, though, on how the cast
> doesn't solve truncation.
Because that is no how the C language work?
Casting UINTMAX+1 to unsigned int, does not magically change the
unsigned int into something else...
> Is the initial implementation not a
> pointer-width down to int-width cast?
These are different widths, so cast cannot solve truncation.
> Surely we're losing the top half
> of bits.
If we are losing top half then how is the truncation and data loss solved?
> I'm still not saying there's data loss, to be clear. Just
> that the compiler is warning because of the truncation.
Sorry, what truncation? The one which will happen always regardless of
the cast and warning?
Best regards,
Krzysztof
Powered by blists - more mailing lists