Re: [edk2-devel] [PATCH v1 1/1] ArmPkg/ArmMmuLibb: Fix implicit cast

["Laszlo Ersek" <lersek@redhat.com>]

On 06/25/20 09:59, PierreGondois wrote:
> From: Pierre Gondois <pierre.gondois@arm.com>
> 
> While building with the following command line:
> build -b DEBUG -a AARCH64 -t VS2017 -p
> edk2\MdeModulePkg\MdeModulePkg.dsc
> 
> A missing cast triggers the following warning,
> then triggering an error:
> edk2/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c(652):
> warning C4152: nonstandard extension, function/data pointer
> conversion in expression
> 
> This patch adds a cast, removing the warning.
> 
> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
> ---
> 
> The changes can be seen at: https://github.com/PierreARM/edk2/commits/831_Fix_implicit_cast_v1
> 
> Notes:
>     v1:
>      - Add (void*) cast. [Pierre]
> 
>  ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c
> index 222ff817956feb738325fc78fbaf064de98802a9..7df7c75d4a571403209e4fee0f0a06ed6e3513fa 100644
> --- a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c
> +++ b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c
> @@ -649,7 +649,7 @@ ArmMmuBaseLibConstructor (
>    // The ArmReplaceLiveTranslationEntry () helper function may be invoked
>    // with the MMU off so we have to ensure that it gets cleaned to the PoC
>    //
> -  WriteBackDataCacheRange (ArmReplaceLiveTranslationEntry,
> +  WriteBackDataCacheRange ((VOID*)ArmReplaceLiveTranslationEntry,
>      ArmReplaceLiveTranslationEntrySize);
>  
>    return RETURN_SUCCESS;
> 

Converting a pointer-to-function to a pointer-to-void (or
pointer-to-object, or pointer-to-incomplete-type) is not defined by the
C standard. So if we want to fix this warning cleanly, we should convert
first to UINTN, and then to (VOID*).

Because (from C99, 6.3.2.3 Pointers):

  6 Any pointer type may be converted to an integer type. Except as
    previously specified, the result is implementation-defined. If the
    result cannot be represented in the integer type, the behavior is
    undefined. The result need not be in the range of values of any
    integer type.

and

  5 An integer may be converted to any pointer type. Except as
    previously specified, the result is implementation-defined, might
    not be correctly aligned, might not point to an entity of the
    referenced type, and might be a trap representation. [56]

  Footnote 56: The mapping functions for converting a pointer to an
               integer or an integer to a pointer are intended to be
               consistent with the addressing structure of the execution
               environment.

So when we write (VOID*)(UINTN)ArmReplaceLiveTranslationEntry, then we
get a pass at least as "implementation-defined".

Thanks,
Laszlo