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

Krzysztof Kozlowski krzysztof.kozlowski at linaro.org
Tue Aug 15 22:34:53 PDT 2023


On 16/08/2023 01:06, Justin Stitt wrote:
> On Tue, Aug 15, 2023 at 2:15 PM Krzysztof Kozlowski
> <krzysztof.kozlowski at linaro.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




More information about the linux-mtd mailing list