Re: [edk2-devel] [PATCH] edk II C Coding Standard: Remove section 5.4.2.2 STATIC

["Michael D Kinney" <michael.d.kinney@intel.com>]

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.