From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 67BEB4240B; Wed, 18 Jan 2023 09:31:45 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5B740427EE; Wed, 18 Jan 2023 09:31:45 +0100 (CET) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 0F9DB410DD for ; Wed, 18 Jan 2023 09:31:44 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH v7 4/4] eal: add nonnull and access function attributes Date: Wed, 18 Jan 2023 09:31:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D87683@smartserver.smartshare.dk> In-Reply-To: <20230117211656.GA30892@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH v7 4/4] eal: add nonnull and access function attributes Thread-Index: AdkquQrASHPQDTovSA+dw12Zuyk6sAAV6x9g References: <20221202153432.131023-1-mb@smartsharesystems.com> <20230116130724.50277-1-mb@smartsharesystems.com> <20230116130724.50277-4-mb@smartsharesystems.com> <98CBD80474FA8B44BF855DF32C47DC35D8767B@smartserver.smartshare.dk> <20230117211656.GA30892@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Tyler Retzlaff" , , , Cc: "Ferruh Yigit" , , , , , , , , , , X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org +To: Thomas & David, you probably have some opinions on this too! > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > Sent: Tuesday, 17 January 2023 22.17 >=20 > On Tue, Jan 17, 2023 at 09:19:22AM +0100, Morten Br=F8rup wrote: > > > From: Ferruh Yigit [mailto:ferruh.yigit@amd.com] > > > Sent: Monday, 16 January 2023 18.02 > > > > > > On 1/16/2023 1:07 PM, Morten Br=F8rup wrote: > > > > Add nonnull function attribute to help the compiler detect a = NULL > > > > pointer being passed to a function not accepting NULL pointers = as > an > > > > argument at build time. > > > > > > > > Add access function attributes to tell the compiler how a > function > > > > accesses memory pointed to by its pointer arguments. > > > > > > > > Add these attributes to the rte_memcpy() function, as the first > in > > > > hopefully many to come. > > > > > > > > Signed-off-by: Morten Br=F8rup > > > > Acked-by: Tyler Retzlaff > > > > Reviewed-by: Ruifeng Wang > > > > --- > > > > [...] > > > > > > +/** > > > > + * Tells compiler that the pointer arguments must be non-null. > > > > + * > > > > + * @param ... > > > > + * Comma separated list of parameter indexes of pointer > > > arguments. > > > > + */ > > > > +#if defined(RTE_CC_GCC) || defined(RTE_CC_CLANG) > > > > +#define __rte_nonnull_params(...) \ > > > > + __attribute__((nonnull(__VA_ARGS__))) > > > > +#else > > > > +#define __rte_nonnull_params(...) > > > > +#endif > > > > + > > > > > > What do you think to have a namespace for macros like > > > '__rte_param_xxx', > > > so name macros as: > > > __rte_param_nonull > > > __rte_param_read_only > > > __rte_param_write_only > > > > > > No strong opinion, it just feels tidier this way > > > > Being a proponent of the world_country_city naming scheme myself, I > would usually agree with this proposal. > > > > However, in the future, we might add macros without _param for use > along with the function parameters, e.g.: > > > > int foo(int bar __rte_nonnull __rte_read_only); > > > > So I decided for this order in the names (treating > nonnull/access_mode as "country" and param/params as "city"), also > somewhat looking at the __rte_deprecated and __rte_deprecated_msg(msg) > macros. > > > > I have no strong preference either, so if anyone does, please speak > up. > > > > Slightly related, also note this: > > > > The nonnull macro is plural (_params), because it can take multiple > pointer parameter indexes. > > The access mode macros are singular (_param), because they only take > one pointer parameter index, and the optional size parameter index. > > > > I considered splitting up the access mode macros even more, making > two variants of each, e.g. __rte_read_only_param(ptr_index) and > __rte_read_only_param_size(ptr_index, size_index), but concluded that > it would be excruciatingly verbose. The only purpose would be to = reduce > the risk of using them incorrectly. I decided against it, thinking = that > any developer clever enough to use these macros is also clever enough > to understand how to use them (or at least read their parameter > descriptions to learn how). > > >=20 > microsoft also has a tool & annotation vehicle for this type of stuff. > this discussion has caused me to wonder what happens if we would like > to > add additional annotations for other tools. just load on the > annotations > and expand them empty conditionally? >=20 > https://learn.microsoft.com/en-us/cpp/code-quality/using-sal- > annotations-to-reduce-c-cpp-code-defects?view=3Dmsvc-170 >=20 > anyway, just a thought. no serious response required here. Excellent input, Tyler! If we want DPDK to be considered truly cross-platform, and not treat = non-Linux/non-GCC as second class citizens, we need to discuss this. Microsoft's Source Code Annotation Language (SAL) seems very good, based = on its finer granularity than GCC's attributes (which in comparison seem = added as an afterthought, not cleanly structured like SAL). I have only = skimmed the documentation, but that is my immediate impression of it. SAL uses a completely different syntax than GCC attributes, and = Microsoft happens to also use memcpy() as an example in the = documentation referred to: void * memcpy( _Out_writes_bytes_all_(count) void *dest, _In_reads_bytes_(count) const void *src, size_t count ); Going back to how we can handle this in DPDK, we can either: 1. Not annotate the functions at all, and miss out on finding the errors = for us. 2. Invent our own language (or find something existing) for function = headers, and use a parser to convert them to compiler specific C/C++ = headers when building the code. 3a. Keep loading on attributes, with empty macros for unsupported = compilers. 3b. Keep loading on attributes, with empty macros for unsupported = compilers. But limit ourselves to GCC/Clang style attributes. 3c. Keep loading on attributes, with empty macros for unsupported = compilers. But limit ourselves to Microsoft SAL style attributes. 3d. Keep loading on attributes, with empty macros for unsupported = compilers. But limit ourselves to the most relevant attributes, using = performance and/or bug detection as criteria when considering relevance. I am strongly against both 1 and 2. If bug detection is the primary driver, we could stick with either 3b or = 3c (i.e. only target one specific build environment) and rely on the = DPDK CI for detecting bugs. But then application developers would not = benefit, because they don't run their code through the DPDK CI. So I am = also against this. I think 3d (keep loading on attributes, but only the most relevant ones) = is the best choice. GCC/Clang style attributes are already supported as macros prefixed by = __rte, so let's not change the way we do that. Regarding the Microsoft SAL, I suppose Microsoft already chose = annotation names to avoid collisions, so we could consider using those = exact names (i.e. without __rte prefix), and define empty macros for = non-Microsoft compilers. This would allow using Microsoft SAL = annotations directly in the DPDK code.