public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Hao Wu <hao.a.wu@intel.com>, edk2-devel@ml01.01.org
Subject: Re: [PATCH 0/1] Refine casting expression result to bigger size
Date: Mon, 23 Jan 2017 12:01:05 +0100	[thread overview]
Message-ID: <08dcec9c-48bf-1878-dcb9-60d28441064f@redhat.com> (raw)
In-Reply-To: <1485067434-12064-1-git-send-email-hao.a.wu@intel.com>

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


  parent reply	other threads:[~2017-01-23 11:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2017-01-23 20:58   ` [PATCH 0/1] " Ard Biesheuvel
2017-01-24  5:53     ` Wu, Hao A

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=08dcec9c-48bf-1878-dcb9-60d28441064f@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox