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

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

[Leif Lindholm]

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.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Leif Lindholm <leif.lindholm@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?)

 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
 
 ///
-- 
2.20.1

Re: [PATCH 1/1] BaseTools: use stdint.h for GCC ProcessorBind.h typedefs

[Liming Gao]

Reviewed-by: Liming Gao <liming.gao@intel.com>

>-----Original Message-----
>From: Leif Lindholm [mailto:leif.lindholm@linaro.org]
>Sent: Friday, September 27, 2019 3:28 AM
>To: devel@edk2.groups.io
>Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Feng, Bob C
><bob.c.feng@intel.com>; Gao, Liming <liming.gao@intel.com>; Laszlo Ersek
><lersek@redhat.com>
>Subject: [PATCH 1/1] BaseTools: use stdint.h for GCC ProcessorBind.h
>typedefs
>
>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.
>
>Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>Cc: Bob Feng <bob.c.feng@intel.com>
>Cc: Liming Gao <liming.gao@intel.com>
>Cc: Laszlo Ersek <lersek@redhat.com>
>Signed-off-by: Leif Lindholm <leif.lindholm@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?)
>
> 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
>
> ///
>--
>2.20.1

Re: [PATCH 1/1] BaseTools: use stdint.h for GCC ProcessorBind.h typedefs

[Bob Feng]

Reviewed-by: Bob Feng <bob.c.feng@intel.com>

-----Original Message-----
From: Leif Lindholm [mailto:leif.lindholm@linaro.org] 
Sent: Friday, September 27, 2019 3:28 AM
To: devel@edk2.groups.io
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Feng, Bob C <bob.c.feng@intel.com>; Gao, Liming <liming.gao@intel.com>; Laszlo Ersek <lersek@redhat.com>
Subject: [PATCH 1/1] BaseTools: use stdint.h for GCC ProcessorBind.h typedefs

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.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Leif Lindholm <leif.lindholm@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?)

 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
 
 ///
--
2.20.1

Re: [PATCH 1/1] BaseTools: use stdint.h for GCC ProcessorBind.h typedefs

[Ard Biesheuvel]

On Thu, 26 Sep 2019 at 21:28, Leif Lindholm <leif.lindholm@linaro.org> 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.
>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Bob Feng <bob.c.feng@intel.com>
> Cc: Liming Gao <liming.gao@intel.com>
> Cc: Laszlo Ersek <lersek@redhat.com>
> Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>

Acked-by: Ard Biesheuvel <ard.biesheuvel@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?)
>
>  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
>
>  ///
> --
> 2.20.1
>

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

[Philippe Mathieu-Daudé]

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@linaro.org>
> Cc: Bob Feng <bob.c.feng@intel.com>
> Cc: Liming Gao <liming.gao@intel.com>
> Cc: Laszlo Ersek <lersek@redhat.com>
> Signed-off-by: Leif Lindholm <leif.lindholm@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? :)

> 
>  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@redhat.com>

Re: [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@linaro.org>
>> Cc: Bob Feng <bob.c.feng@intel.com>
>> Cc: Liming Gao <liming.gao@intel.com>
>> Cc: Laszlo Ersek <lersek@redhat.com>
>> Signed-off-by: Leif Lindholm <leif.lindholm@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@redhat.com>
> 

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

[Leif Lindholm]

Thanks all - pushed as 5be5439a5a4e.

(And special thanks to Laszlo for the below.)

On Tue, Oct 01, 2019 at 12:01:31AM +0200, Laszlo Ersek wrote:
> 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@linaro.org>
> >> Cc: Bob Feng <bob.c.feng@intel.com>
> >> Cc: Liming Gao <liming.gao@intel.com>
> >> Cc: Laszlo Ersek <lersek@redhat.com>
> >> Signed-off-by: Leif Lindholm <leif.lindholm@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@redhat.com>
> > 
>