From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web11.113445.1669626510385681772 for ; Mon, 28 Nov 2022 01:08:30 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=SH+IKoCx; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 46AAA6104F for ; Mon, 28 Nov 2022 09:08:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AE781C433B5 for ; Mon, 28 Nov 2022 09:08:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1669626508; bh=Zg9A+w1OxlqIHJ+qgQWg2mUYWhEhh/W6l3quqS4o4Cc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=SH+IKoCxbdng4k2GGOIKf0UqJEnimMxtHSh8Krt1+vhulm3KOT8Zwq/EHPa5/S3Rg ea2x5g0K3pog+ORdUJixZ0whTbb7AT/wLUsdhK0D3z9RKPK1f+BC4uYa2J/oZv9pf3 RYCgo6HolfLFZBpqQj2JWK0kaXW9UcAASmt54LmoaS6XGw7V8YnSpvyRhq7shP2IZ2 oe8qyZesZXR4EAY2uzQP+ONNPCQflUz/5uM6sMIWUZtbbE3Lki+vXAD+e6lo8XXw4H 6jptcaxxhrx1XgOJ4DSPUiabLu+IA4a4LH68fxOwBK7SSLCQ9oTZ5UL9OEnxXkidKc 0+kza7/h7HbFQ== Received: by mail-lj1-f172.google.com with SMTP id z4so12365315ljq.6 for ; Mon, 28 Nov 2022 01:08:28 -0800 (PST) X-Gm-Message-State: ANoB5plMLpFYkiPFSHYxjmLS/vRIXEqwCmQRCsFCgf+oUdVvqIXNsUl4 1fhNMOWilAz9MFBCHkz7tb7pShDXSdna1VR3kNM= X-Google-Smtp-Source: AA0mqf4iLXs7+s+YOM9qxLdtER4mEiQ4RTfN+JB3FBvO/RRzk8u6RJDF8Vslq15XMxBNpfHMzajsTIY9dIJdAOBeIRQ= X-Received: by 2002:a05:651c:b14:b0:277:7eef:1d97 with SMTP id b20-20020a05651c0b1400b002777eef1d97mr10459571ljr.516.1669626506704; Mon, 28 Nov 2022 01:08:26 -0800 (PST) MIME-Version: 1.0 References: <20221122044708.672-1-abner.chang@amd.com> In-Reply-To: From: "Ard Biesheuvel" Date: Mon, 28 Nov 2022 10:08:14 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH] edk II C Coding Standard: Remove section 5.4.2.2 STATIC To: devel@edk2.groups.io, michael.d.kinney@intel.com Cc: "Chang, Abner" , "Ni, Ray" , "Gao, Liming" Content-Type: text/plain; charset="UTF-8" On Tue, 22 Nov 2022 at 19:10, Michael D Kinney 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.