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

[Justin Stitt]

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. Is the initial implementation not a
pointer-width down to int-width cast? Surely we're losing the top half
of bits. I'm still not saying there's data loss, to be clear. Just
that the compiler is warning because of the truncation.

>
> >
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1910
> > Reported-by: Nathan Chancellor <nathan at kernel.org>
> > Signed-off-by: Justin Stitt <justinstitt at google.com>
> > ---
> > Note: There is likely no data loss occurring here due to the fact that
> > `enum versatile_flashprot` has only a few enumerated fields, none of
> > which are large enough to cause data loss.
>
> If there is a data loss, cast does not solve it.
>
> > Nonetheless, this patch helps
> > towards the goal of eventually enabling this warning for more builds.
> >
> > Signed-off-by: Justin Stitt <justinstitt at google.com>
>
>
> Best regards,
> Krzysztof
>