From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) by sourceware.org (Postfix) with ESMTPS id 6FA633858D39 for ; Mon, 15 Nov 2021 16:01:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6FA633858D39 Received: by mail-wm1-x333.google.com with SMTP id 133so14462483wme.0 for ; Mon, 15 Nov 2021 08:01:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=v5C6WzoL3QtWBOOL/Vb0Jvqlfr9VT8dAbWAG06EjzVs=; b=7l+168YIF1bTuwQgnfYjc81W25PqvaDWkody3M4WvUqBtpn+3/ewKOTZJUzMc+szZS Fmrb+tRzSL/r3ni9CxEc0NqYKKeYZIkC46484fBJokRu+7CKXTOpKciQx2smK0qUnC+v wjj3PEbc/zTFTjXujYpgI05Fq7q7iEJlGI6/sjCXJZTF8eeE44RHgKvus5svSUnkD5kW JFjdcK5lWw246fj5D1OoO8f4k2IhkvP+7xNMK5TIrh5ZDOKBSk9aITncxAjsskUXD3gz oyHUMvgjDslc9uMncT7dTMHvgV0vVpj5T+jsW22kzeSXRtOf7NQbRylboooGazyLeDNa tVmg== X-Gm-Message-State: AOAM532zciZkQIHNMGCdwmd76hoXevBhUbThJydDBgeaOWTUt9zAbi9q pVWkCKEGy2uqrthVc+YpLLoRisIyvUh1cA== X-Google-Smtp-Source: ABdhPJzGlPox4GS/l6vMGf/2ca+bkzIA9UrJxmpI8bcOck3LR9Qt+fnYaEA9rtb35PepZTyslbDCtg== X-Received: by 2002:a05:600c:4104:: with SMTP id j4mr43212801wmi.178.1636992111429; Mon, 15 Nov 2021 08:01:51 -0800 (PST) Received: from [192.168.0.160] ([170.253.36.171]) by smtp.gmail.com with ESMTPSA id m14sm20248692wrp.28.2021.11.15.08.01.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Nov 2021 08:01:50 -0800 (PST) To: JeanHeyd Meneide , gcc@gcc.gnu.org, cfe-dev@lists.llvm.org From: "Alejandro Colomar (man-pages)" Subject: ISO C3X proposal: nonnull qualifier Message-ID: Date: Mon, 15 Nov 2021 17:01:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2021 16:01:58 -0000 Hi all, I'd like to propose the following feature for ISO C (and also ISO C++). It is based on a mix of GCC's [[gnu::nonnull]] and Clang's _Nonnull, with a pinch of salt of mine. I'd like to get some feedback from GCC and Clang, before sending it as an official proposal. BTW, since the working group is probably very busy with C2X, I may delay sending it more than a year. Or I may propose it first to ISO C++, and then to ISO C. I wrote the initial draft in the form of a manual page, whose source code can be found here: It has a Makefile to easily transform it into a PDF. I also rendered it with cat to inline it in this email. Cheers, Alex --- nonnull(3) Nxxxx nonnull(3) NAME nonnull - non‐null pointer SYNOPSIS type‐qualifier: const nonnull restrict volatile _Atomic DESCRIPTION Constraints Types other than pointer types shall not be nonnull‐qualified. Semantics The properties associated with qualified types are mean‐ ingfull only for expressions that are lvalues. If the same qualifier appears more than once in the same specifier‐qualifier list or as declaration specifiers, either directly or via one or more typedefs, the behavior is the same as if it appeared only once. If other quali‐ fiers appear along with the _Atomic qualifier, the re‐ sulting type is the so‐qualified atomic type. If an attempt is made to assign NULL to a pointer defined with the nonnull qualifier, the behavior is undefined. If an attempt is made to refer to a pointer with a non‐‐ nonnull‐qualified type through the use of an lvalue with nonnull‐qualified type, the behavior is undefined. The intended use of the nonnull and restrict qualifiers (like the register storage class) is to promote optimiza‐ tion, and deleting all instances of the qualifier from all preprocessing translation units composing a conform‐ ing program does not change its meaning (i.e., observable behavior). NOTES These rules for nonnull are somewhat of the reverse of const: Instead of forbidding the discarding of the quali‐ fier, we forbid the addition of the qualifier. The rea‐ son is that constant variables are a subset of variables, and the danger is in treating a const as a variable. Similarly, nonnull pointers are a subset of (possibly‐ NULL) pointers, but the danger is in treating possibly‐ NULL pointers as nonnull pointers. Prior art GCC has [[gnu::nonnull]]. Why is this better? It can be applied more specifically in the case of point‐ ers to pointers. And, like with const, the nonnull‐ness can be better enforced by passing the qualifier around. However, we recognize the optimizations allowed by [[gnu::nonnull]], and also allow them, by specifying the behavior as undefined when the qualifier is misused, as GCC does. Clang has _Nonnull. Why is this better? Clang found that using a qualifier was better than an at‐ tribute, since it allowed to more specifically apply it to pointers to pointers. We recognize that, and also use a qualifier. Clang doesn't specify the behavior as being undefined. That forbids optimizations, that would otherwise be pos‐ sible. We prefer to allow for those optimizations. Clang considers this qualifier to be useful only as a di‐ agnostics generator. We not only allow for diagnostics to be issued, but we have stricter rules that make it more difficult to produce incorrect code. Even though the language has reserved identifiers start‐ ing with underscore + uppercase for this kind of key‐ words, Clang has already used _Nonnull, and since we are changing the meaning, it might cause problems to existing code. So nonnull seems a better name, which hopefully is not used by existing code, or at least it is less used. EXAMPLES Correct strcpy(3) may be implemented in the following way, to signify that it cannot accept NULL as input to any of its arguments, and that it cannot ever return NULL either. char *nonnull strcpy(char *nonnull restrict dest, const char *nonnull restrict src) { char *d; d = dest; while ((*d++ = *src++) != '\0'); return dest; } Note that d need not be nonnull‐qualified, since possibly being NULL is a superset of not possibly being NULL. The following variations of the above are incorrect, for the reasons that follow the code examples. Incorrect char *strcpy(char *nonnull restrict dest, const char *nonnull restrict src) { char *d; d = dest; while ((*d++ = *src++) != '\0'); return dest; } Although this would be valid by itself (wouldn't have un‐ defined behavior), it forbids callers of the function from assigning the return value to a nonnull‐qualified pointer. Undefined behavior char *nonnull strcpy(char *restrict dest, const char *nonnull restrict src) { char *d; d = dest; while ((*d++ = *src++) != '\0'); return dest; } This causes undefined behavior, since it assigns a non‐‐ nonnull‐qualified pointer (dest) to a qualified one (the return value). It's also dangerous, since the user isn't properly informed that NULL may cause undefined behavior in the implementation of the function (dest is derefer‐ enced). AUTHORS Alejandro Colomar I must thank the GCC and Clang programmers for having provided a solid base on which I based this proposal. SEE ALSO N2731 ‐ 6.7.3 ⟨https://gcc.gnu.org/onlinedocs/gcc/Common‐Function‐ Attributes.html#Common‐Function‐Attributes⟩ ⟨https://clang.llvm.org/docs/AttributeReference.html #nullability‐attributes⟩ C3X 2021‐11‐15 nonnull(3) -- Alejandro Colomar Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/ http://www.alejandro-colomar.es/