public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: "David F." <df7729@gmail.com>
Cc: ard.biesheuvel@linaro.org,
	edk2 developers list <edk2-devel@lists.01.org>,
	"Carsey, Jaben" <jaben.carsey@intel.com>,
	"Gao, Liming" <liming.gao@intel.com>
Subject: Re: [PATCH v2 6/6] BaseTools/CommonLib: drop definition of MAX_UINTN
Date: Tue, 11 Dec 2018 16:45:57 +0100	[thread overview]
Message-ID: <11e96d9d-7f7c-7b2d-c05d-e5d009a2f4b1@redhat.com> (raw)
In-Reply-To: <CAGRSmLs-Xz=_HZ=JVJp6A0Q0X5dZB5wsAeKHuJPM4hfcQSe=Xw@mail.gmail.com>

On 12/11/18 08:11, David F. wrote:
> Not sure why you'd take that out when someone using UINTN for variables may
> want to use MAX_UINTN ?    Future may be different.

The UINTN type comes from the UEFI spec:

    Unsigned value of native width. (4 bytes on supported 32-bit
    processor instructions, 8 bytes on supported 64-bit processor
    instructions, 16 bytes on supported 128-bit processor instructions)

In this sense, "native" refers to the firmware execution environment.
The firmware execution environment need not have anything in common with
the build environment. (You can build 32-bit ARM firmware on X64 hosts.)
In such a scenario, using UINTN *at all* is fraught with
misunderstandings. It *would* be possible to use UINTN as it applies to
the build (= hosted) environment, and in that sense MAX_UINTN would also
be possible to define. However, the code being removed (= defining
MAX_UINTN as MAX_ADDRESS) proves that that approach would be very easy
to misunderstand and misuse. People could easily mistake it for applying
to the firmware execution environment.

UINT32 and UINT64 are not affected by this ambiguity.

Optimally, given that the build utilities target a hosted C runtime,
they should use standard C types, such as "unsigned int", or e.g.
"uint32_t". Together with standard C macros expressing limits, such as
UINT_MAX (from <limits.h>) and UINT32_MAX (from <stdint.h>).

Clearly no-one has capacity to clean up BaseTools like this. For
starters, we should at least remove whatever actively causes confusion.

Thanks,
Laszlo

> On Mon, Dec 3, 2018 at 5:08 AM Laszlo Ersek <lersek@redhat.com> wrote:
> 
>> On 11/30/18 23:45, Ard Biesheuvel wrote:
>>> The maximum value that can be represented by the native word size
>>> of the *target* should be irrelevant when compiling tools that
>>> run on the build *host*. So drop the definition of MAX_UINTN, now
>>> that we no longer use it.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
>>> ---
>>>  BaseTools/Source/C/Common/CommonLib.h | 1 -
>>>  1 file changed, 1 deletion(-)
>>>
>>> diff --git a/BaseTools/Source/C/Common/CommonLib.h
>> b/BaseTools/Source/C/Common/CommonLib.h
>>> index 6930d9227b87..b1c6c00a3478 100644
>>> --- a/BaseTools/Source/C/Common/CommonLib.h
>>> +++ b/BaseTools/Source/C/Common/CommonLib.h
>>> @@ -22,7 +22,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND,
>> EITHER EXPRESS OR IMPLIED.
>>>
>>>  #define MAX_LONG_FILE_PATH 500
>>>
>>> -#define MAX_UINTN MAX_ADDRESS
>>>  #define MAX_UINT64 ((UINT64)0xFFFFFFFFFFFFFFFFULL)
>>>  #define MAX_UINT16  ((UINT16)0xFFFF)
>>>  #define MAX_UINT8   ((UINT8)0xFF)
>>>
>>
>> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>>
> 



  reply	other threads:[~2018-12-11 15:46 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-30 22:45 [PATCH v2 0/6] BaseTools: get rid of MAX_UINTN Ard Biesheuvel
2018-11-30 22:45 ` [PATCH v2 1/6] BaseTools/CommonLib: avoid using 'native' word size in IP address handling Ard Biesheuvel
2018-12-03 10:25   ` Philippe Mathieu-Daudé
2018-12-03 12:50   ` Laszlo Ersek
2018-11-30 22:45 ` [PATCH v2 2/6] BaseTools/CommonLib: use explicit 64-bit type in Strtoi() Ard Biesheuvel
2018-12-03 10:25   ` Philippe Mathieu-Daudé
2018-12-03 12:52   ` Laszlo Ersek
2018-11-30 22:45 ` [PATCH v2 3/6] BaseTools/DevicePath: use explicit 64-bit number parsing routines Ard Biesheuvel
2018-12-03 10:25   ` Philippe Mathieu-Daudé
2018-12-03 12:55   ` Laszlo Ersek
2018-11-30 22:45 ` [PATCH v2 4/6] BaseTools/DevicePath: use MAX_UINT16 as default device path max size Ard Biesheuvel
2018-12-03 13:05   ` Laszlo Ersek
2018-12-05  0:04     ` Gao, Liming
2018-12-05  7:42       ` Ard Biesheuvel
2018-12-05  7:53         ` Gao, Liming
2018-11-30 22:45 ` [PATCH v2 5/6] BaseTools/CommonLib: get rid of 'native' type string parsing routines Ard Biesheuvel
2018-12-03 10:27   ` Philippe Mathieu-Daudé
2018-12-03 13:08   ` Laszlo Ersek
2018-11-30 22:45 ` [PATCH v2 6/6] BaseTools/CommonLib: drop definition of MAX_UINTN Ard Biesheuvel
2018-12-03 10:28   ` Philippe Mathieu-Daudé
2018-12-03 13:08   ` Laszlo Ersek
2018-12-11  7:11     ` David F.
2018-12-11 15:45       ` Laszlo Ersek [this message]
2018-12-11 22:53         ` David F.
2018-12-11 22:55           ` Ard Biesheuvel
2018-12-11 23:03             ` David F.
2018-12-05  0:04 ` [PATCH v2 0/6] BaseTools: get rid " Gao, Liming
2018-12-05  8:12   ` Ard Biesheuvel

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=11e96d9d-7f7c-7b2d-c05d-e5d009a2f4b1@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