From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4864:20::131; helo=mail-it1-x131.google.com; envelope-from=df7729@gmail.com; receiver=edk2-devel@lists.01.org Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 99AC52119AC37 for ; Tue, 11 Dec 2018 15:03:45 -0800 (PST) Received: by mail-it1-x131.google.com with SMTP id p197so6850234itp.0 for ; Tue, 11 Dec 2018 15:03:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=axc4epy7MN6nVcyOkmjQ0k6j4XAEuTyrLuqrB9Jaa4E=; b=WLxyja/XbqmxTskHZ0ckJ+DNyu0Puz9w9EJHi6UAOFb3ygnuIYTKwNaibdqU8ykcdl LQMMVQxBtU0ZsvG0yob9ST2h0UGhkWpMD6WSczV1Vm23iX6ltneMdoB6Vq8PdqBxp7dU pytK72BhXOkMlMKjddx+whVtn9lyTvUHJW/WAbCC1BH7Ui+DB32dtLPYzBuVz+jUgrfY S8cV76Cdh++Wb+k18Fr+cxRyEQRrCe6hZF10sVaxAOB4CRpFrhElTjfCvdH6o4VrGLXj GJ3oxZ5NxPnVLdAUmj5W2ayAgPDALQkjWnNNrT66aux47L1xHjYH4Uh4UfRLC5Ho3ELh iV/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=axc4epy7MN6nVcyOkmjQ0k6j4XAEuTyrLuqrB9Jaa4E=; b=dDkuNKcaNQaQIoj/wgoOf/13Wa5yaskOAiIIWYpy1uAlpbTRtOtCrJfzYB3lyndUfZ twzaet0j0eqbH6xB6QgJoC89LWfZTi/UVd+8JVX8rlEPxBoTk7ixfjIDxK1BbfJUKIIH 8W7fBlnaSJNA4c+bGfUNbaLhKXIxVEBS2Dl9/N6TOtCjv2xVvn0pLmvInQdsx7Zm65Pe 2rJIWP4ZpKy191n3oyo1HbrUd0ufr/rUlnzn6YMIXPmSdtmjkm9cGf2lDKYbzmVzrQcl YhcdfOm5gcLH2KkyiyNIIWdkT7vdmzw90Ks4V6ijjV0wWyLnNDimRrg4nMb4Cyre10Ag LlCQ== X-Gm-Message-State: AA+aEWaonT3zCrhs81tzeAFaJo2UqTfUZTcieckP3ObKzkp46vTDAW0q Awsj3QxgcVrm5Lv20E3d4wOmhNUH7CWZYyU5P+A= X-Google-Smtp-Source: AFSGD/XbrW7hKJyX1eA1bQOSwfQCntpm6kFiCKFF0N57q/UskZmcVkfLsqdSkn4om1uzayuyGLTBg4Bp6KfBf27PFQY= X-Received: by 2002:a02:9d27:: with SMTP id n36mr16260131jak.30.1544569424908; Tue, 11 Dec 2018 15:03:44 -0800 (PST) MIME-Version: 1.0 References: <20181130224537.18936-1-ard.biesheuvel@linaro.org> <20181130224537.18936-7-ard.biesheuvel@linaro.org> <4a244c8f-8f59-2936-f543-2bd43f78af9c@redhat.com> <11e96d9d-7f7c-7b2d-c05d-e5d009a2f4b1@redhat.com> In-Reply-To: From: "David F." Date: Tue, 11 Dec 2018 15:03:33 -0800 Message-ID: To: Ard Biesheuvel Cc: Laszlo Ersek , edk2 developers list , "Carsey, Jaben" , "Gao, Liming" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [PATCH v2 6/6] BaseTools/CommonLib: drop definition of MAX_UINTN X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 23:03:45 -0000 Content-Type: text/plain; charset="UTF-8" I missed that it was for the build-tool source itself and not for the targets that are built using edk2 and the API itself. On Tue, Dec 11, 2018 at 2:55 PM Ard Biesheuvel wrote: > On Tue, 11 Dec 2018 at 23:53, David F. wrote: > > > > I don't know, to me it's very clear that UINTN is talking about the > target, just like size_t would be. > > > > But which target? This change is against the source of the BaseTools, > which are host tools that can be used to build a single target image > consisting of 32-bit and 64-bit modules. So which size is the native > size in this case? > > > There are/were a bunch of API's using UINTN so using UINTN was > desirable, and where needed UINTN_MAX. > > > > I just don't see an advantage to removing it. Do see disadvantage to > removing it for breaking existing code and for those that want the "native" > (best/fasted/most efficient) int size for the processor (similar again to > size_t) > > > > On Tue, Dec 11, 2018 at 7:46 AM Laszlo Ersek wrote: > >> > >> 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 ) and UINT32_MAX (from ). > >> > >> 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 > 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 > >> >>> Reviewed-by: Jaben Carsey > >> >>> --- > >> >>> 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 > >> >> _______________________________________________ > >> >> edk2-devel mailing list > >> >> edk2-devel@lists.01.org > >> >> https://lists.01.org/mailman/listinfo/edk2-devel > >> >> > >> > > >> >