From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) by sourceware.org (Postfix) with ESMTPS id 49CCF3858D37 for ; Fri, 28 Apr 2023 21:34:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 49CCF3858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-2fa36231b1cso124413f8f.2 for ; Fri, 28 Apr 2023 14:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682717669; x=1685309669; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=xCMqliRY1a183AWPpPk6NhJjUkltwQYIpIMkdvPafus=; b=MZ9cSQRKpItVc37xKHX+j9Jdd55BdccOUPA+W22ybeNrDNudH1249zhZ58GyiWETHl 2jEvJIMZX79HYR2rQbczI2MAuCDq8B1QCimRHYSB1rKUA1O5QdSbdjGJInilVYyXDnHs o2fyGewxBhgoWcg6BDo5SMwKlRIewkNkmirq62zhVfU0h1QkvGvKBJKfE9OOmFIo+wP8 xLX4Q0u6s7tYw/NipzH5kE0POkiJ3Wi0WEG1YJV9g6aMfW1LPQdSnErM/OC3mgsiEDgg 3RZWpHaeTHjDsJoMVWGFqp75KG8yhT41x3/pTg6d1LX0XVTIWaEkQEbGIVAAU76JMRUu smCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682717669; x=1685309669; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xCMqliRY1a183AWPpPk6NhJjUkltwQYIpIMkdvPafus=; b=WJXibmgmN9TaCIAeiou8Wb9PfBH9aafRZV3sEnrdEOV1DihCmk3Zrmz/RE+5HzTN5t VNcwibRGBhGm4bgKSRcylqbzb5oSwpsKjwhIIzL8jrs5Ht9/s3VBI9RSSNv1LSBTNAdn qrQ61EiTW13vesTiwazIhUdzr4e8QJs2/PgYSFVspMOeGNc3IwETjm5LrR8Pu7I9/AyA HxRnx3EXhf50u+fYGHSAPWW0F+pSRESdLOFVsVvgEl9cATcSXL2bdfRlrBGKhVMaRvN0 HI/xGR8eiYZ+GQtLyySOBL5XgHtHhe5wfES0QMSS7nb1T5QeG78C95TskSpqXFehYjOp H7Ww== X-Gm-Message-State: AC+VfDyIMESCGDX84Fo2Za0HBDofjYdj92Mcd8JRajIIPo39ItpjnEe7 rA4wdyw2niEiVr99pzEMSrLq0nZhzRkLrnGRWOow/GOFpj6FansW X-Google-Smtp-Source: ACHHUZ5PBXqBK3Z2hMrN96B/N3+Gj1VJsUrARql1l8GieHvGbH9Whm85OX/GSCKW/yQy10jUFtmhpyhz/pWYLjvKgFQ= X-Received: by 2002:a5d:6906:0:b0:303:2702:6d66 with SMTP id t6-20020a5d6906000000b0030327026d66mr4570057wru.63.1682717668659; Fri, 28 Apr 2023 14:34:28 -0700 (PDT) MIME-Version: 1.0 References: <13261922.uLZWGnKmhe@localhost.localdomain> In-Reply-To: <13261922.uLZWGnKmhe@localhost.localdomain> From: Christopher Bazley Date: Fri, 28 Apr 2023 22:34:17 +0100 Message-ID: Subject: Re: can-be-null can-not-be-null break-instruction for better handling pointers. To: =?UTF-8?Q?S=C5=82awomir_Lach?= Cc: gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi, I agree with you that C would benefit from a new type qualifier to indicate pointer nullability, although not with your suggestion that such a qualifier should indicate the property cannot-be-null. If you just want a syntax for declaring that a function parameter is not a null pointer, C already supports that (with the same limitation as for C++ references, that the type of the referenced object cannot be void): int get_vector_size(struct vector vec[static 1]) { return vec->size; } You can even implement the other behaviour of C++ references, which is that they can only point to one object during their lifetime: int get_vector_size(struct vector vec[const static 1]) { return vec->size; } In GCC, -Wnonnull is required to get a warning about passing null to such a function, and (in my experience) it won't warn about non-trivial cases where the null pointer isn't passed as an immediate constant. Regardless of what the language formally guarantees, most C source code in the real world already assumes that pointers are not null in the absence of information to the contrary. This assumption is necessary, for example, because the first argument to every function in a C language interface is typically a pointer which fulfils the same role as 'this' (aka 'self') in an object-oriented language. You will also see, if you study the C standard library, that functions which have well-defined behaviour for null pointer values are in a minority. I recently wrote a paper on this topic, which proposes a new qualifier as well as modified semantics for the unary & operator. This paper is currently with the relevant ISO committee for consideration. My related article on Medium examines a lot of prior art in the area, as well as explaining why I think none of the existing solutions is adequate: https://itnext.io/why-c-needs-a-new-type-qualifier-61ad553cbe71 The article contains links (at the end) to my paper, as well as to a working prototype implementation of the functionality I propose (albeit using Clang rather than GCC). I previously posted on this mailing list to enquire about whether it would be worthwhile to implement the same functionality in GCC, but got slapped down. It seems to me that the era of compiler extensions informing the language standardization process (rather than vice versa) is over, but that's just my perception based on limited feedback. There's a reason why C programmers haven't replaced all of their 'int *ip' pointer arguments with 'int ip[const static 1]' during the past 24 years, and I don't think they ever will. It doesn't resemble Kernighan & Ritchie's "pleasant, expressive, and versatile" language which featured "economy of expression". Nor does it conform to K&R's intent that declaration syntax be mnemonic, since 'int ip[const static 1]' doesn't resemble anything: neither a pointer declaration in any other context, nor a real array declaration, nor the syntax for array usage in expressions. Best regards, -- Christopher Bazley