* [PATCH 0/1] Refine casting expression result to bigger size @ 2017-01-22 6:43 Hao Wu 2017-01-22 6:43 ` [PATCH 1/1] MdePkg: " Hao Wu 2017-01-23 11:01 ` [PATCH 0/1] " Laszlo Ersek 0 siblings, 2 replies; 5+ messages in thread From: Hao Wu @ 2017-01-22 6:43 UTC (permalink / raw) To: edk2-devel; +Cc: 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH 1/1] MdePkg: Refine casting expression result to bigger size 2017-01-22 6:43 [PATCH 0/1] Refine casting expression result to bigger size Hao Wu @ 2017-01-22 6:43 ` Hao Wu 2017-01-23 11:01 ` [PATCH 0/1] " Laszlo Ersek 1 sibling, 0 replies; 5+ messages in thread From: Hao Wu @ 2017-01-22 6:43 UTC (permalink / raw) To: edk2-devel; +Cc: Hao Wu, Michael Kinney, Liming Gao, Eric Dong 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 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH 0/1] Refine casting expression result to bigger size 2017-01-22 6:43 [PATCH 0/1] Refine casting expression result to bigger size Hao Wu 2017-01-22 6:43 ` [PATCH 1/1] MdePkg: " Hao Wu @ 2017-01-23 11:01 ` Laszlo Ersek 2017-01-23 20:58 ` Ard Biesheuvel 1 sibling, 1 reply; 5+ messages in thread From: Laszlo Ersek @ 2017-01-23 11:01 UTC (permalink / raw) To: Hao Wu, edk2-devel 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 0/1] Refine casting expression result to bigger size 2017-01-23 11:01 ` [PATCH 0/1] " Laszlo Ersek @ 2017-01-23 20:58 ` Ard Biesheuvel 2017-01-24 5:53 ` Wu, Hao A 0 siblings, 1 reply; 5+ messages in thread From: Ard Biesheuvel @ 2017-01-23 20:58 UTC (permalink / raw) To: Laszlo Ersek; +Cc: Hao Wu, edk2-devel@lists.01.org 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 0/1] Refine casting expression result to bigger size 2017-01-23 20:58 ` Ard Biesheuvel @ 2017-01-24 5:53 ` Wu, Hao A 0 siblings, 0 replies; 5+ messages in thread From: Wu, Hao A @ 2017-01-24 5:53 UTC (permalink / raw) To: Ard Biesheuvel, Laszlo Ersek; +Cc: edk2-devel@lists.01.org > -----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. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-01-24 5:53 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-01-22 6:43 [PATCH 0/1] Refine casting expression result to bigger size Hao Wu 2017-01-22 6:43 ` [PATCH 1/1] MdePkg: " Hao Wu 2017-01-23 11:01 ` [PATCH 0/1] " Laszlo Ersek 2017-01-23 20:58 ` Ard Biesheuvel 2017-01-24 5:53 ` Wu, Hao A
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox