[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] x86/xen/efi: Fix EFI variable 'name' type conversion



Ahh, I see that I definitely should have made the patch notes more descriptive. I could be wrong but I was under the impression that casting the data type of wchar_t to efi_char16_t (unsigned short) was acceptable as I've seen it in similar patches before, see here https://lkml.org/lkml/2019/7/21/126. The Sparse warning threw me off.

I thought the cast would inform the compiler better when it came to unicode characters, I may be wrong here, I'm very new to submitting patches...

On Mon, 2 Sep 2019 at 17:54, Jan Beulich <jbeulich@xxxxxxxx> wrote:
On 01.09.2019 08:58, Adam Zerella wrote:
> This resolves a type conversion from 'char *' to 'unsigned short'.

Could you explain this? There's no ...

> --- a/arch/x86/xen/efi.c
> +++ b/arch/x86/xen/efi.c
> @@ -118,8 +118,8 @@ static enum efi_secureboot_mode xen_efi_get_secureboot(void)
>       unsigned long size;

>       size = sizeof(secboot);
> -     status = efi.get_variable(L"SecureBoot", &efi_variable_guid,
> -                               NULL, &size, &secboot);
> +     status = efi.get_variable((efi_char16_t *)L"SecureBoot",
> +                               &efi_variable_guid, NULL, &size, &secboot);

... "char *" resulting as type for L"" type strings, hence there
should be no need for a cast: In fact I consider such casts
dangerous, as they may hide actual problems. To me this looks
more like something that wants fixing in sparse; the compilers,
after all, have no issue with such wide character string literals.

> @@ -158,7 +158,7 @@ static enum efi_secureboot_mode xen_efi_get_secureboot(void)
>       return efi_secureboot_mode_unknown;
>  }

> -void __init xen_efi_init(struct boot_params *boot_params)
> +static void __init xen_efi_init(struct boot_params *boot_params)
>  {
>       efi_system_table_t *efi_systab_xen;

If I was a maintainer of this code, I'd request this not be part
of a patch with a title being entirely unrelated to the change.

Jan

Adam

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.