From: "Chang, Abner" <abner.chang@amd.com>
To: "Kinney, Michael D" <michael.d.kinney@intel.com>,
Ard Biesheuvel <ardb@kernel.org>,
"devel@edk2.groups.io" <devel@edk2.groups.io>
Cc: "Ni, Ray" <ray.ni@intel.com>, "Gao, Liming" <gaoliming@byosoft.com.cn>
Subject: Re: [edk2-devel] [PATCH] edk II C Coding Standard: Remove section 5.4.2.2 STATIC
Date: Mon, 12 Dec 2022 05:30:56 +0000 [thread overview]
Message-ID: <MN2PR12MB3966CF2AC5BDB4EFAC9FF6F7EAE29@MN2PR12MB3966.namprd12.prod.outlook.com> (raw)
In-Reply-To: <CO1PR11MB4929BD430D55079A0AC85BFBD2139@CO1PR11MB4929.namprd11.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 3374 bytes --]
[AMD Official Use Only - General]
HI Ard, attach the patch review for the 'static'. Please check it and provide your feedback on it if you think the phrase is not strong enough.
Thanks
Abner
> -----Original Message-----
> From: Kinney, Michael D <michael.d.kinney@intel.com>
> Sent: Monday, November 28, 2022 11:41 PM
> To: Ard Biesheuvel <ardb@kernel.org>; devel@edk2.groups.io; Kinney,
> Michael D <michael.d.kinney@intel.com>
> Cc: Chang, Abner <Abner.Chang@amd.com>; Ni, Ray <ray.ni@intel.com>;
> Gao, Liming <gaoliming@byosoft.com.cn>
> Subject: RE: [edk2-devel] [PATCH] edk II C Coding Standard: Remove section
> 5.4.2.2 STATIC
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> Ard,
>
> I agree it should be a strong recommendation for all of these reasons.
>
> There is a patch review for this spec for use of 'static'. Can you please
> provide feedback with your recommended content?
>
> Thanks,
>
> Mike
>
> > -----Original Message-----
> > From: Ard Biesheuvel <ardb@kernel.org>
> > Sent: Monday, November 28, 2022 1:08 AM
> > To: devel@edk2.groups.io; Kinney, Michael D
> > <michael.d.kinney@intel.com>
> > Cc: Chang, Abner <Abner.Chang@amd.com>; Ni, Ray <ray.ni@intel.com>;
> > Gao, Liming <gaoliming@byosoft.com.cn>
> > Subject: Re: [edk2-devel] [PATCH] edk II C Coding Standard: Remove
> > section 5.4.2.2 STATIC
> >
> > On Tue, 22 Nov 2022 at 19:10, Michael D Kinney
> > <michael.d.kinney@intel.com> wrote:
> > >
> > > Hi Abner,
> > >
> > > Removing that section 5.4.2.2 is required to close this bug.
> > >
> > > Meaning of 'static' is covered by the ANSI C standards.
> > >
> > > Use of 'static' for non-public variable/functions in EDK II
> > > libraries/modules is recommended.
> > >
> > > However, it is not required. It is recommended to reduce chances of
> > > symbol conflicts at link time. Current approach is if a link
> > > failure occurs for multiply defined symbols and those are non-public
> > > symbols, the 'static' attribute can be applied to the non-public
> > > symbols in the components that generated the link failure.
> > >
> > > It may be good to mention this recommendation in the CSS.
> > >
> > > I will let you decide when this recommendation needs to be added to
> > > CSS.
> > >
> >
> > 'static' is not just a tool to avoid symbol conflicts. It also avoids
> > abuse of symbols that are assumed to have a private nature but can be
> > linked to nonetheless (e.g., in static libraries). Ideally, any
> > library should only export the symbols that it defines as part of its
> > interface, although this is not currently feasible of a library
> > consists of multiple object files.
> >
> > Another thing to keep in mind is that static is used by the compiler
> > to make inferences about the value. A static global variable can only
> > be modified by the code in the same compilation unit, and so the
> > compiler is free to optimize accesses or perform constant propagation
> > and drop it entirely if it only observes reads and no writes from the
> > variable.
> >
> > I consider it good developer hygiene to always use static on global
> > symbols (code and data) unless the symbol needs to be shared with
> > other compilation units.
[-- Attachment #2: Type: message/rfc822, Size: 14745 bytes --]
From: "Chang, Abner via groups.io" <abner.chang=amd.com@groups.io>
To: "devel@edk2.groups.io" <devel@edk2.groups.io>
Cc: Ray Ni <ray.ni@intel.com>, Michael D Kinney <michael.d.kinney@intel.com>
Subject: [edk2-devel] [PATCH V2] edk II C Coding Standard: Remove section 5.4.2.2 STATIC
Date: Sat, 26 Nov 2022 09:02:57 +0000
Message-ID: <172B1708C307B48B.11309@groups.io>
Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
From: Abner Chang <abner.chang@amd.com>
BZ #1766
Revise the sections that mention the usage of "static" and
remove section 5.4.2.2.1 and 5.4.2.2.2 section.
We are not allowed to use upper-case STATIC in the source
file now.
Just follow C standard and use the lower-case 'static'.
Leave the macro "#deifne STATIC static" there without
removing it to keep the backward compatible.
Signed-off-by: Abner Chang <abner.chang@amd.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
---
5_source_files/54_code_file_structure.md | 19 ++++---------------
5_source_files/56_declarations_and_types.md | 2 +-
2 files changed, 5 insertions(+), 16 deletions(-)
diff --git a/5_source_files/54_code_file_structure.md b/5_source_files/54_code_file_structure.md
index 0c4d6a2..6a9fcc7 100644
--- a/5_source_files/54_code_file_structure.md
+++ b/5_source_files/54_code_file_structure.md
@@ -267,19 +267,8 @@ specified in Section 5.4.1.3 "Compile-Time Names".
Thus, while it might be legal C, do **not** declare external variables anywhere
other than at the top level of a file as specified by this document.
-#### 5.4.2.2 Static
+#### 5.4.2.2 static
-An object declared `STATIC` has either file or block scope.
-
-##### 5.4.2.2.1 Do not reuse an object or function identifier with static storage duration.
-
-Throughout the set of source files defined within a single .inf file, do not
-reuse an identifier with static storage duration. The compiler may not be
-confused by this, but the user may confuse unrelated variables with the same
-name.
-
-##### 5.4.2.2.2 Functions should not be declared STATIC.
-
-Some source-level debuggers are unable to resolve static functions. Until it
-can be verified that no one is dependent upon a debugger with this limitation,
-it is strongly recommended that functions not be declared static.
+Use static for the variables and functions those are non-public to other source
+files is encouraged. This reduces the chances of symbol redefined error during
+link process.
\ No newline at end of file
diff --git a/5_source_files/56_declarations_and_types.md b/5_source_files/56_declarations_and_types.md
index ec1803d..db98b95 100644
--- a/5_source_files/56_declarations_and_types.md
+++ b/5_source_files/56_declarations_and_types.md
@@ -38,7 +38,7 @@
Any abstract type that is defined must be constructed from other abstract types
or from common EFI data types.
-#### 5.6.1.2 The use of int, unsigned, char, void, static, long is a violation of the coding convention.
+#### 5.6.1.2 The use of int, unsigned, char, void, long and the data types those are defined in EFI Data Types is a violation of the coding convention.
The corresponding EFI types must be used instead.
--
2.37.1.windows.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#96631): https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F96631&data=05%7C01%7Cabner.chang%40amd.com%7C4b16779158484971fb8308dacf8d1ce6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638050502240293052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=eseelCW8m4aLLXn%2FkC14SPTMX4UA6B9g%2BI4Q5q2W1UU%3D&reserved=0
Mute This Topic: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.io%2Fmt%2F95269399%2F7039027&data=05%7C01%7Cabner.chang%40amd.com%7C4b16779158484971fb8308dacf8d1ce6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638050502240449300%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BJa16pSkZiuk9e8YoYR6o%2F1TpNCg%2FozlGNLeRjrEGBc%3D&reserved=0
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Funsub&data=05%7C01%7Cabner.chang%40amd.com%7C4b16779158484971fb8308dacf8d1ce6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638050502240449300%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=QCmY7omz67ulLnn9Xi%2Br%2FudQrhRNCOU6qJmjHDQ9rHE%3D&reserved=0 [abner.chang@amd.com]
-=-=-=-=-=-=-=-=-=-=-=-
prev parent reply other threads:[~2022-12-12 5:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-22 4:47 [PATCH] edk II C Coding Standard: Remove section 5.4.2.2 STATIC Chang, Abner
2022-11-22 5:48 ` [edk2-devel] " Ni, Ray
2022-11-22 6:07 ` Chang, Abner
2022-11-22 16:31 ` Michael D Kinney
2022-11-22 22:12 ` Pedro Falcato
2022-11-22 22:39 ` Michael D Kinney
2022-11-26 7:44 ` Chang, Abner
2022-11-28 9:08 ` Ard Biesheuvel
2022-11-28 15:41 ` Michael D Kinney
2022-12-12 5:30 ` Chang, Abner [this message]
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=MN2PR12MB3966CF2AC5BDB4EFAC9FF6F7EAE29@MN2PR12MB3966.namprd12.prod.outlook.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