linux-kernel - Re: [PATCH] mtd: maps: fix -Wvoid-pointer-to-enum-cast warning

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] [day] [month] [year] [list]

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