[edk2-devel] [PATCH 1/1] BaseTools: use stdint.h for GCC ProcessorBind.h typedefs

[Laszlo Ersek]

On 09/27/19 12:06, Philippe Mathieu-Daudé wrote:
> On 9/26/19 9:28 PM, Leif Lindholm wrote:
>> The AArch64 definitions of UINT64/INT64 differ from the X64 ones.
>> Since this is on the tool side, doing like X64 and picking the
>> definitions from stdint.h feels like a better idea than hardcoding
>> them. So copy the pattern from X64/ProcesorBind.h.
> 
> Typo: X64/ProcessorBind.h ('s' missing).
> 
>>
>> Cc: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>> Cc: Bob Feng <bob.c.feng at intel.com>
>> Cc: Liming Gao <liming.gao at intel.com>
>> Cc: Laszlo Ersek <lersek at redhat.com>
>> Signed-off-by: Leif Lindholm <leif.lindholm at linaro.org>
>> ---
>>
>> This was triggered by one of the Risc-V patches which may need to end up
>> being modified to the point where this issue goes away, but the current
>> situation seems suboptimal. (Do you use %llx or %lx to print an Elf64_Addr
>> on a 64-bit LP architecture?)
> 
> What is the answer? :)

For a hosted C99 program, you cast it to uint64_t, and print it with

  "%"PRIx64

(Note: "uint64_t" is an optional type, per C99.

"""
However, if an implementation provides integer types with widths of 8,
16, 32, or 64 bits, no padding bits, and (for the signed types) that
have a two’s complement representation, it shall define the
corresponding typedef names.
"""

The existence of Elf64_Addr suggests the implementation is like that,
hence we can assume "uint64_t". Otherwise, we'd have to use
"uint_least64_t" and "%"PRIxLEAST64.)


When restricted to C89, you can only use "%lx" and "unsigned long", and
you also have to rely on -- for example -- SUSv2 (from 1997 -- the last
Single Unix Spec defined in terms of C89), for ensuring / selecting the
XBS5_LP64_OFF64, or XBS5_LPBIG_OFFBIG compilation environments.

(SUSv2 defines uint64_t, so you could use that in itself, but SUSv2
defines no matching format string macros, for printing uint64_t.)

How you print a 64-bit unsigned integer in Visual Studio, I can't say.
It's not fully C99 conformant, it's likely also not SUSv2 conformant (in
case we wanted to rely on C89 + SUSv2); so I have no idea. It's likely
documented in MSDN or some place similar.

Thanks
Laszlo

> 
>>
>>  BaseTools/Source/C/Include/AArch64/ProcessorBind.h | 26 ++++++++++----------
>>  1 file changed, 13 insertions(+), 13 deletions(-)
>>
>> diff --git a/BaseTools/Source/C/Include/AArch64/ProcessorBind.h b/BaseTools/Source/C/Include/AArch64/ProcessorBind.h
>> index bfaf1e28e446..dfa725b2e363 100644
>> --- a/BaseTools/Source/C/Include/AArch64/ProcessorBind.h
>> +++ b/BaseTools/Source/C/Include/AArch64/ProcessorBind.h
>> @@ -41,21 +41,21 @@
>>    typedef signed char         INT8;
>>  #else
>>    //
>> -  // Assume standard AARCH64 alignment.
>> +  // Use ANSI C 2000 stdint.h integer width declarations
>>    //
>> -  typedef unsigned long long  UINT64;
>> -  typedef long long           INT64;
>> -  typedef unsigned int        UINT32;
>> -  typedef int                 INT32;
>> -  typedef unsigned short      UINT16;
>> -  typedef unsigned short      CHAR16;
>> -  typedef short               INT16;
>> -  typedef unsigned char       BOOLEAN;
>> -  typedef unsigned char       UINT8;
>> -  typedef char                CHAR8;
>> -  typedef signed char         INT8;
>> +  #include <stdint.h>
>> +  typedef uint8_t   BOOLEAN;
>> +  typedef int8_t    INT8;
>> +  typedef uint8_t   UINT8;
>> +  typedef int16_t   INT16;
>> +  typedef uint16_t  UINT16;
>> +  typedef int32_t   INT32;
>> +  typedef uint32_t  UINT32;
>> +  typedef int64_t   INT64;
>> +  typedef uint64_t  UINT64;
>> +  typedef char      CHAR8;
>> +  typedef uint16_t  CHAR16;
>>  
>> -  #define UINT8_MAX 0xff
>>  #endif
>>  
>>  ///
>>
> 
> Reviewed-by: Philippe Mathieu-Daude <philmd at redhat.com>
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48318): https://edk2.groups.io/g/devel/message/48318
Mute This Topic: https://groups.io/mt/34302597/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-