Messages in this thread | | | Date | Wed, 16 Aug 2023 07:34:53 +0200 | Subject | Re: [PATCH] mtd: maps: fix -Wvoid-pointer-to-enum-cast warning | From | Krzysztof Kozlowski <> |
| |
On 16/08/2023 01:06, Justin Stitt wrote: > On Tue, Aug 15, 2023 at 2:15 PM Krzysztof Kozlowski > <krzysztof.kozlowski@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
| |