[PATCH 0/1] Refine casting expression result to bigger size

[PATCH 0/1] Refine casting expression result to bigger size

[Hao Wu]

Please note that this patch is maily for feedback collection and the patch
only covers MdePkg. We are working on patches for other packages.


There are cases that the operands of an expression are all with rank less
than UINT64/INT64 and the result of the expression is casted to
UINT64/INT64 to fit the target size.

An example will be:
UINT32 a,b;
// a and b can be any unsigned int type with rank less than UINT64, like
// UINT8, UINT16, etc.
UINT64 c;
c = (UINT64) (a + b);

Some static code checkers may warn that the expression result might
overflow within the rank of int (integer promotions) and the result is
then cast to a bigger size.

For the consideration of generated binaries size, the commit will keep the
size of the operands as the size of int, and explitly add a type cast
before converting the result to UINT64/INT64.

1). When there is no operand with type UINTN
(UINTN)  (a + b) -> (UINTN)(UINT32)  (a + b) or
(UINT64) (a + b) -> (UINT64)(UINT32) (a + b)

2). Otherwise
(UINT64) (a + b) -> (UINT64)(UINTN)  (a + b)

Hao Wu (1):
  MdePkg: Refine casting expression result to bigger size

 MdePkg/Library/BaseLib/String.c                              | 4 ++--
 MdePkg/Library/BasePeCoffLib/BasePeCoff.c                    | 4 ++--
 MdePkg/Library/BaseS3PciLib/S3PciLib.c                       | 4 ++--
 MdePkg/Library/SmmMemoryAllocationLib/MemoryAllocationLib.c  | 4 ++--
 MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c | 4 ++--
 5 files changed, 10 insertions(+), 10 deletions(-)

-- 
1.9.5.msysgit.0

[PATCH 1/1] MdePkg: Refine casting expression result to bigger size

[Hao Wu]

There are cases that the operands of an expression are all with rank less
than UINT64/INT64 and the result of the expression is casted to
UINT64/INT64 to fit the target size.

An example will be:
UINT32 a,b;
// a and b can be any unsigned int type with rank less than UINT64, like
// UINT8, UINT16, etc.
UINT64 c;
c = (UINT64) (a + b);

Some static code checkers may warn that the expression result might
overflow within the rank of int (integer promotions) and the result is
then cast to a bigger size.

For the consideration of generated binaries size, the commit will keep the
size of the operands as the size of int, and explitly add a type cast
before converting the result to UINT64/INT64.

1). When there is no operand with type UINTN
(UINTN)  (a + b) -> (UINTN)(UINT32)  (a + b) or
(UINT64) (a + b) -> (UINT64)(UINT32) (a + b)

2). Otherwise
(UINT64) (a + b) -> (UINT64)(UINTN)  (a + b)

Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
---
 MdePkg/Library/BaseLib/String.c                              | 4 ++--
 MdePkg/Library/BasePeCoffLib/BasePeCoff.c                    | 4 ++--
 MdePkg/Library/BaseS3PciLib/S3PciLib.c                       | 4 ++--
 MdePkg/Library/SmmMemoryAllocationLib/MemoryAllocationLib.c  | 4 ++--
 MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c | 4 ++--
 5 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/MdePkg/Library/BaseLib/String.c b/MdePkg/Library/BaseLib/String.c
index e84bf50..82aa405 100644
--- a/MdePkg/Library/BaseLib/String.c
+++ b/MdePkg/Library/BaseLib/String.c
@@ -586,7 +586,7 @@ InternalHexCharToUintn (
     return Char - L'0';
   }
 
-  return (UINTN) (10 + InternalCharToUpper (Char) - L'A');
+  return (UINTN)(UINT32) (10 + InternalCharToUpper (Char) - L'A');
 }
 
 /**
@@ -1211,7 +1211,7 @@ InternalAsciiHexCharToUintn (
     return Char - '0';
   }
 
-  return (UINTN) (10 + InternalBaseLibAsciiToUpper (Char) - 'A');
+  return (UINTN)(UINT32) (10 + InternalBaseLibAsciiToUpper (Char) - 'A');
 }
 
 
diff --git a/MdePkg/Library/BasePeCoffLib/BasePeCoff.c b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
index 33cad23..d7f5fd0 100644
--- a/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
+++ b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
@@ -15,7 +15,7 @@
   PeCoffLoaderGetPeHeader() routine will do basic check for PE/COFF header.
   PeCoffLoaderGetImageInfo() routine will do basic check for whole PE/COFF image.
 
-  Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.<BR>
+  Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.<BR>
   Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.<BR>
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD License
@@ -703,7 +703,7 @@ PeCoffLoaderGetImageInfo (
       //
       DebugDirectoryEntryFileOffset = 0;
 
-      SectionHeaderOffset = (UINTN)(
+      SectionHeaderOffset = (UINTN)(UINT32)(
                                ImageContext->PeCoffHeaderOffset +
                                sizeof (UINT32) +
                                sizeof (EFI_IMAGE_FILE_HEADER) +
diff --git a/MdePkg/Library/BaseS3PciLib/S3PciLib.c b/MdePkg/Library/BaseS3PciLib/S3PciLib.c
index e29f7fe..d712c64 100644
--- a/MdePkg/Library/BaseS3PciLib/S3PciLib.c
+++ b/MdePkg/Library/BaseS3PciLib/S3PciLib.c
@@ -3,7 +3,7 @@
   the PCI operations to be replayed during an S3 resume. This library class
   maps directly on top of the PciLib class. 
 
-  Copyright (c) 2006 - 2012, Intel Corporation. All rights reserved.<BR>
+  Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.<BR>
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions
@@ -25,7 +25,7 @@
 #include <Library/S3PciLib.h>
 
 #define PCILIB_TO_COMMON_ADDRESS(Address) \
-        ((UINT64) ((((UINTN) ((Address>>20) & 0xff)) << 24) + (((UINTN) ((Address>>15) & 0x1f)) << 16) + (((UINTN) ((Address>>12) & 0x07)) << 8) + ((UINTN) (Address & 0xfff ))))
+        ((UINT64)(UINTN) ((((UINTN) ((Address>>20) & 0xff)) << 24) + (((UINTN) ((Address>>15) & 0x1f)) << 16) + (((UINTN) ((Address>>12) & 0x07)) << 8) + ((UINTN) (Address & 0xfff ))))
 
 /**
   Saves a PCI configuration value to the boot script.
diff --git a/MdePkg/Library/SmmMemoryAllocationLib/MemoryAllocationLib.c b/MdePkg/Library/SmmMemoryAllocationLib/MemoryAllocationLib.c
index 937165a..8321b6c 100644
--- a/MdePkg/Library/SmmMemoryAllocationLib/MemoryAllocationLib.c
+++ b/MdePkg/Library/SmmMemoryAllocationLib/MemoryAllocationLib.c
@@ -12,7 +12,7 @@
   allocation for the Reserved memory types are not supported and will always 
   return NULL.
 
-  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.<BR>
+  Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.<BR>
   This program and the accompanying materials                          
   are licensed and made available under the terms and conditions of the BSD License         
   which accompanies this distribution.  The full text of the license may be found at        
@@ -343,7 +343,7 @@ InternalAllocateAlignedPages (
       Status = gSmst->SmmFreePages (Memory, UnalignedPages);
       ASSERT_EFI_ERROR (Status);
     }
-    Memory         = (EFI_PHYSICAL_ADDRESS) (AlignedMemory + EFI_PAGES_TO_SIZE (Pages));
+    Memory         = (EFI_PHYSICAL_ADDRESS)(UINTN) (AlignedMemory + EFI_PAGES_TO_SIZE (Pages));
     UnalignedPages = RealPages - Pages - UnalignedPages;
     if (UnalignedPages > 0) {
       //
diff --git a/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c b/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c
index 3da5e211..d818f9c 100644
--- a/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c
+++ b/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c
@@ -2,7 +2,7 @@
   Support routines for memory allocation routines based 
   on boot services for Dxe phase drivers.
 
-  Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.<BR>
+  Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.<BR>
   This program and the accompanying materials                          
   are licensed and made available under the terms and conditions of the BSD License         
   which accompanies this distribution.  The full text of the license may be found at        
@@ -216,7 +216,7 @@ InternalAllocateAlignedPages (
       Status = gBS->FreePages (Memory, UnalignedPages);
       ASSERT_EFI_ERROR (Status);
     }
-    Memory         = (EFI_PHYSICAL_ADDRESS) (AlignedMemory + EFI_PAGES_TO_SIZE (Pages));
+    Memory         = (EFI_PHYSICAL_ADDRESS)(UINTN) (AlignedMemory + EFI_PAGES_TO_SIZE (Pages));
     UnalignedPages = RealPages - Pages - UnalignedPages;
     if (UnalignedPages > 0) {
       //
-- 
1.9.5.msysgit.0

Re: [PATCH 0/1] Refine casting expression result to bigger size

[Laszlo Ersek]

On 01/22/17 07:43, Hao Wu wrote:
> Please note that this patch is maily for feedback collection and the patch
> only covers MdePkg. We are working on patches for other packages.
> 
> 
> There are cases that the operands of an expression are all with rank less
> than UINT64/INT64 and the result of the expression is casted to
> UINT64/INT64 to fit the target size.
> 
> An example will be:
> UINT32 a,b;
> // a and b can be any unsigned int type with rank less than UINT64, like
> // UINT8, UINT16, etc.
> UINT64 c;
> c = (UINT64) (a + b);
> 
> Some static code checkers may warn that the expression result might
> overflow within the rank of int (integer promotions) and the result is
> then cast to a bigger size.
> 
> For the consideration of generated binaries size, the commit will keep the
> size of the operands as the size of int, and explitly add a type cast
> before converting the result to UINT64/INT64.
> 
> 1). When there is no operand with type UINTN
> (UINTN)  (a + b) -> (UINTN)(UINT32)  (a + b) or
> (UINT64) (a + b) -> (UINT64)(UINT32) (a + b)
> 
> 2). Otherwise
> (UINT64) (a + b) -> (UINT64)(UINTN)  (a + b)
> 
> Hao Wu (1):
>   MdePkg: Refine casting expression result to bigger size
> 
>  MdePkg/Library/BaseLib/String.c                              | 4 ++--
>  MdePkg/Library/BasePeCoffLib/BasePeCoff.c                    | 4 ++--
>  MdePkg/Library/BaseS3PciLib/S3PciLib.c                       | 4 ++--
>  MdePkg/Library/SmmMemoryAllocationLib/MemoryAllocationLib.c  | 4 ++--
>  MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c | 4 ++--
>  5 files changed, 10 insertions(+), 10 deletions(-)
> 

- If it is justified to do the addition in 64-bits (or in UINTN), then
the addition should be modified accordingly. This might incur a code
size increase, but if that's necessary for correctness, then it should
be done.

- However, if the addition is just fine as-is, because we know for sure
that the sum will never overflow "int" or "unsigned int" (as selected by
the integer promotions and the usual arithmetic conversions), then we're
addressing the issue in the wrong direction. Namely, in this case, the
solution is to simply drop the outermost cast, which is already useless.
(Because, it would automatically happen as part of the assignment or the
"return" statement.)

I mean... Those (useless) outermost casts were probably introduced to
appease the Visual Studio compiler. Apparently, they cause various
static code checkers to complain, so now we introduce yet more casts to
keep them quiet as well. When will it end?

For example, the 2nd return statement of the InternalHexCharToUintn()
function is proposed as

  return (UINTN)(UINT32) (10 + InternalCharToUpper (Char) - L'A');

in reality it should be just

  return 10 + InternalCharToUpper (Char) - L'A';

Thanks
Laszlo

Re: [PATCH 0/1] Refine casting expression result to bigger size

[Ard Biesheuvel]

On 23 January 2017 at 11:01, Laszlo Ersek <lersek@redhat.com> wrote:
> On 01/22/17 07:43, Hao Wu wrote:
>> Please note that this patch is maily for feedback collection and the patch
>> only covers MdePkg. We are working on patches for other packages.
>>
>>
>> There are cases that the operands of an expression are all with rank less
>> than UINT64/INT64 and the result of the expression is casted to
>> UINT64/INT64 to fit the target size.
>>
>> An example will be:
>> UINT32 a,b;
>> // a and b can be any unsigned int type with rank less than UINT64, like
>> // UINT8, UINT16, etc.
>> UINT64 c;
>> c = (UINT64) (a + b);
>>
>> Some static code checkers may warn that the expression result might
>> overflow within the rank of int (integer promotions) and the result is
>> then cast to a bigger size.
>>
>> For the consideration of generated binaries size, the commit will keep the
>> size of the operands as the size of int, and explitly add a type cast
>> before converting the result to UINT64/INT64.
>>
>> 1). When there is no operand with type UINTN
>> (UINTN)  (a + b) -> (UINTN)(UINT32)  (a + b) or
>> (UINT64) (a + b) -> (UINT64)(UINT32) (a + b)
>>
>> 2). Otherwise
>> (UINT64) (a + b) -> (UINT64)(UINTN)  (a + b)
>>
>> Hao Wu (1):
>>   MdePkg: Refine casting expression result to bigger size
>>
>>  MdePkg/Library/BaseLib/String.c                              | 4 ++--
>>  MdePkg/Library/BasePeCoffLib/BasePeCoff.c                    | 4 ++--
>>  MdePkg/Library/BaseS3PciLib/S3PciLib.c                       | 4 ++--
>>  MdePkg/Library/SmmMemoryAllocationLib/MemoryAllocationLib.c  | 4 ++--
>>  MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c | 4 ++--
>>  5 files changed, 10 insertions(+), 10 deletions(-)
>>
>
> - If it is justified to do the addition in 64-bits (or in UINTN), then
> the addition should be modified accordingly. This might incur a code
> size increase, but if that's necessary for correctness, then it should
> be done.
>

Indeed. The problem with

c = (UINT64) (a + b);

is the parens: this should be written as (UINT64)a + b if the sum may
overflow a UINT32

> - However, if the addition is just fine as-is, because we know for sure
> that the sum will never overflow "int" or "unsigned int" (as selected by
> the integer promotions and the usual arithmetic conversions), then we're
> addressing the issue in the wrong direction. Namely, in this case, the
> solution is to simply drop the outermost cast, which is already useless.
> (Because, it would automatically happen as part of the assignment or the
> "return" statement.)
>

Agreed.

> I mean... Those (useless) outermost casts were probably introduced to
> appease the Visual Studio compiler. Apparently, they cause various
> static code checkers to complain, so now we introduce yet more casts to
> keep them quiet as well. When will it end?
>
> For example, the 2nd return statement of the InternalHexCharToUintn()
> function is proposed as
>
>   return (UINTN)(UINT32) (10 + InternalCharToUpper (Char) - L'A');
>
> in reality it should be just
>
>   return 10 + InternalCharToUpper (Char) - L'A';
>

Indeed. IMO this is related to our warnings-as-errors policy, while in
reality, some warnings are simply warnings, and should be ignored if
it can be confirmed by visual inspection that the expression can never
overflow.

Re: [PATCH 0/1] Refine casting expression result to bigger size

[Wu, Hao A]

> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> Sent: Tuesday, January 24, 2017 4:58 AM
> To: Laszlo Ersek
> Cc: Wu, Hao A; edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH 0/1] Refine casting expression result to bigger size
> 
> On 23 January 2017 at 11:01, Laszlo Ersek <lersek@redhat.com> wrote:
> > On 01/22/17 07:43, Hao Wu wrote:
> >> Please note that this patch is maily for feedback collection and the patch
> >> only covers MdePkg. We are working on patches for other packages.
> >>
> >>
> >> There are cases that the operands of an expression are all with rank less
> >> than UINT64/INT64 and the result of the expression is casted to
> >> UINT64/INT64 to fit the target size.
> >>
> >> An example will be:
> >> UINT32 a,b;
> >> // a and b can be any unsigned int type with rank less than UINT64, like
> >> // UINT8, UINT16, etc.
> >> UINT64 c;
> >> c = (UINT64) (a + b);
> >>
> >> Some static code checkers may warn that the expression result might
> >> overflow within the rank of int (integer promotions) and the result is
> >> then cast to a bigger size.
> >>
> >> For the consideration of generated binaries size, the commit will keep the
> >> size of the operands as the size of int, and explitly add a type cast
> >> before converting the result to UINT64/INT64.
> >>
> >> 1). When there is no operand with type UINTN
> >> (UINTN)  (a + b) -> (UINTN)(UINT32)  (a + b) or
> >> (UINT64) (a + b) -> (UINT64)(UINT32) (a + b)
> >>
> >> 2). Otherwise
> >> (UINT64) (a + b) -> (UINT64)(UINTN)  (a + b)
> >>
> >> Hao Wu (1):
> >>   MdePkg: Refine casting expression result to bigger size
> >>
> >>  MdePkg/Library/BaseLib/String.c                              | 4 ++--
> >>  MdePkg/Library/BasePeCoffLib/BasePeCoff.c                    | 4 ++--
> >>  MdePkg/Library/BaseS3PciLib/S3PciLib.c                       | 4 ++--
> >>  MdePkg/Library/SmmMemoryAllocationLib/MemoryAllocationLib.c  | 4 ++-
> -
> >>  MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c | 4 ++--
> >>  5 files changed, 10 insertions(+), 10 deletions(-)
> >>
> >
> > - If it is justified to do the addition in 64-bits (or in UINTN), then
> > the addition should be modified accordingly. This might incur a code
> > size increase, but if that's necessary for correctness, then it should
> > be done.
> >
> 
> Indeed. The problem with
> 
> c = (UINT64) (a + b);
> 
> is the parens: this should be written as (UINT64)a + b if the sum may
> overflow a UINT32
> 
> > - However, if the addition is just fine as-is, because we know for sure
> > that the sum will never overflow "int" or "unsigned int" (as selected by
> > the integer promotions and the usual arithmetic conversions), then we're
> > addressing the issue in the wrong direction. Namely, in this case, the
> > solution is to simply drop the outermost cast, which is already useless.
> > (Because, it would automatically happen as part of the assignment or the
> > "return" statement.)
> >
> 
> Agreed.
> 
> > I mean... Those (useless) outermost casts were probably introduced to
> > appease the Visual Studio compiler. Apparently, they cause various
> > static code checkers to complain, so now we introduce yet more casts to
> > keep them quiet as well. When will it end?
> >
> > For example, the 2nd return statement of the InternalHexCharToUintn()
> > function is proposed as
> >
> >   return (UINTN)(UINT32) (10 + InternalCharToUpper (Char) - L'A');
> >
> > in reality it should be just
> >
> >   return 10 + InternalCharToUpper (Char) - L'A';
> >
> 

Hi Laszlo and Ard,

Thanks for the feedbacks. I agree that for the above case the type casts
"(UINT)(UINT32)" are unnecessary.

Also, I agree that for cases that overflow might happen, (UINT64)a + b
should be used.

So I will work out a V2 patch for MdePkg following the below rules:
1). If the expression will not overflow "(unsigned) int", remove the
unnecessary type casts.
2). If overflow is possible, explicitly type cast the first operand in the
expression to bigger size.

Best Regards,
Hao Wu

> Indeed. IMO this is related to our warnings-as-errors policy, while in
> reality, some warnings are simply warnings, and should be ignored if
> it can be confirmed by visual inspection that the expression can never
> overflow.