From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Tue, 30 Apr 2019 02:43:25 -0700 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 107D35D68A; Tue, 30 Apr 2019 09:43:25 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-121-42.rdu2.redhat.com [10.10.121.42]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4B6787013C; Tue, 30 Apr 2019 09:43:23 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH V2 3/8] MdePkg/UefiDebugLibStdErr: Decrease the name collisions To: "Kinney, Michael D" , Ard Biesheuvel Cc: "devel@edk2.groups.io" , "Gao, Zhichao" , "Gao, Liming" , "Bi, Dandan" References: <20190424045827.19348-1-zhichao.gao@intel.com> <20190424045827.19348-4-zhichao.gao@intel.com> <47188ce9-c3dc-89e7-c65a-a5fa8eccc7db@redhat.com> From: "Laszlo Ersek" Message-ID: <058199df-cd93-feab-267f-adf300991a1d@redhat.com> Date: Tue, 30 Apr 2019 11:43:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 30 Apr 2019 09:43:25 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 04/29/19 18:40, Kinney, Michael D wrote: > Hi Laszlo, > > I have entered 2 BZ for the STATIC -> static conversion. > one for the EDK II C Coding Standard Specification and > one for the C code in EDK II. > > https://bugzilla.tianocore.org/show_bug.cgi?id=1766 > > https://bugzilla.tianocore.org/show_bug.cgi?id=1767 > > Converting all CONST -> const will require additional > discussion because the UEFI Specification defines the > keyword 'CONST' in Section 2.3.1 - Data Types and is > consistently used in APIs defined in the UEFI/PI > Specifications. Good point, thanks! Laszlo > > Best regards, > > Mike > >> -----Original Message----- >> From: Laszlo Ersek [mailto:lersek@redhat.com] >> Sent: Friday, April 26, 2019 9:49 AM >> To: Ard Biesheuvel ; Kinney, >> Michael D >> Cc: devel@edk2.groups.io; Gao, Zhichao >> ; Gao, Liming >> ; Bi, Dandan >> Subject: Re: [edk2-devel] [PATCH V2 3/8] >> MdePkg/UefiDebugLibStdErr: Decrease the name collisions >> >> On 04/24/19 19:09, Ard Biesheuvel wrote: >>> On Wed, 24 Apr 2019 at 18:59, Kinney, Michael D >>> wrote: >>>> >>>> Hi Ard, >>>> >>>> I see a mix of use of 'static' and 'STATIC' in the >> sources. >>>> >>>> The reason to use STATIC is if it needs to be >> replaced with >>>> something other than 'static' for a specific compiler >> or >>>> debug scenario. >>>> >>>> Long ago, there were some source level debug issue >> with >>>> 'static' symbols, so using the macro STATIC was >> preferred >>>> so it could be mapped to nothing for a debug >> scenario. That >>>> issue no long exists. >>>> >>>> Do you know of a reason today to map 'STATIC' to >> anything >>>> Other than 'static'? >>>> >>>> I also looked at the EDK II C Coding Standard. It is >> also >>>> inconsistent and had references to both 'static' and >> 'STATIC'. >>>> We should enter a few BZs to update that doc once we >> have >>>> clear guidance from this discussion. >>>> >>> >>> I wasn't aware that lower case static is also in use, >> so I was simply >>> extrapolating from personal experience. >> >> +1 >> >>> i think there should be no reason to use the >> preprocessor to change >>> 'static' into something else, and so I'm happy to >> settle on lowercase >>> static, as long as we are consistent. >> >> +1 (same for CONST / const) >> >>> But more importantly, now that >>> this has come up, what I would like to do is make >> 'static' mandatory >>> unless the code requires otherwise: this results in >> much better code >>> generation (given that the compiler can infer >> constness for non-const >>> static variables but not for ones with external >> linkage) and generally >>> improves programmer hygiene when it comes to linking >> to arbitrary >>> symbols that are really internal to a library. >> >> I agree; for new code, giving internal linkage to as >> many as possible >> objects that have static storage duration is the way to >> go. ("Make as >> many globals 'static' as you can.") >> >> Thanks >> Laszlo