From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) by sourceware.org (Postfix) with ESMTPS id 29D313858D28 for ; Tue, 23 Nov 2021 11:45:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 29D313858D28 Received: by mail-wm1-x335.google.com with SMTP id p27-20020a05600c1d9b00b0033bf8532855so1728944wms.3 for ; Tue, 23 Nov 2021 03:45:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=WMK7+opr8B2WpM/1YmXHO4om17s0Jk1VHpA6Gjz9nmE=; b=g3kFZVwvYffoaxVLj3+/MQ/0VLsvXl9IHPXkA4vU+IZRvcuG3u/l1MBNjtkJc0exCD fHKfVh4VxD7kaRLX4FpCSjrV0E5KdBVuTbFJ76xSNA5MoVP+8MwFUj14iizAE4IcaXo3 idHlErQ2DhXLVmVBrbYvVaTLZCKtmPI6irMCeuXCzU9PTG7oF9w5RyftGdgmTUjk9S6B d/9phLHoeDSQnwTr2KBZ20AUZzYQPa3m37FMgoPlDKg9uljg23ekdj7lK66ccjN8UBCy X3k/Jsag2ySV6FBi38AANL+rKNTXXOw4ek/X8CIphc4M1br4jYML8pe/Gl2cNe9PqZcH JNDg== X-Gm-Message-State: AOAM531zz6udst53xc9C/ipvhNtypjN6pq2FTmgl0vYK7jeTbhWKNPdJ rz4shKfwoA21CYtCcZaSgD8= X-Google-Smtp-Source: ABdhPJwyqtjxg8gszJR7mSPsgL09j9KkszvyHvmdkDMsNsZ5RS1RWtLfFr9IAvB6sGge5kAO4Hx2DA== X-Received: by 2002:a1c:183:: with SMTP id 125mr2395714wmb.0.1637667908025; Tue, 23 Nov 2021 03:45:08 -0800 (PST) Received: from [10.168.10.170] ([170.253.36.171]) by smtp.gmail.com with ESMTPSA id q123sm886305wma.30.2021.11.23.03.45.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Nov 2021 03:45:07 -0800 (PST) Sender: Alejandro Colomar Message-ID: <93576cba-19f8-8cf6-6597-7377bda9647f@gmail.com> Date: Tue, 23 Nov 2021 12:45:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: [cfe-dev] ISO C3X proposal: nonnull qualifier Content-Language: en-US To: Dmitri Gribenko Cc: Joseph Myers , gcc@gcc.gnu.org, cfe-dev References: <56a1a945-608e-0e5e-7610-c35481abb980@gmail.com> <4883fa8c-2d99-2611-a8e2-6c7612283da4@gmail.com> From: "Alejandro Colomar (man-pages)" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, 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: Tue, 23 Nov 2021 11:45:11 -0000 Hi Dmitry, On 11/23/21 12:17, Dmitri Gribenko wrote: > Hi Alejandro, > > On Tue, Nov 16, 2021 at 1:34 PM Alejandro Colomar (man-pages) via > cfe-dev wrote: >> First of all, >> I see unnecessary (probably over-engineered) qualifiers: >> >> - _Null_unspecified seems to me the same as nothing. >> If I didn't specify its nullability, >> it's by definition unspecified. Right? >> >> - _Nullable seems to me also the same as nothing. >> The language allows for a pointer to be NULL, >> so if you don't specify if it can or not be null, >> you better stay on the safe side and consider it as nullable. > > _Nullable is used in conjunction with the `#pragma clang > assume_nonnull begin/end` pragma that flips the default: > > ``` > #pragma clang assume_nonnull begin > int *global_int_ptr; // implicitly _Nonnull > #pragma clang assume_nonnull end > ``` > > Within these pragma brackets, you need to use _Nullable to get the > opposite behavior. > > The pragma itself is useful because it reduces the amount of noise the > annotations introduce. When these annotations were adopted in Apple > SDKs, it was found that in practice most pointers are non-nullable. So > if we only had _Nonnull, we would have to annotate most pointers. > Instead, Apple's SDKs bracket every header contents with this pragma, > and instead annotate nullable pointers, significantly reducing the > amount of annotations. That's interesting. Most of my functions also tipically are full of [[gnu::nonnull]], so the _Nonnull default seems the best thing. However, would that be viable in old code that relies on standard C? I think that it would, but maybe you have more experience. Do you agree with the following? Let's imagine a scenario where C3X specifies that non-qualified pointers are nonnull. And there's only a qualifier, _Nullable, to allow NULL. Asigning _Nullable to nonnull would issue a diagnostic. Old code will stop compiling if it uses NULL, but that can easily be fixed by marking the pointers as _Nullable, and maybe while at that, programmers will find a few bugs. Compilers will have to be carefull, because memcpy() will make NULL members of structures, so they'll need to know if that can be done or not, and many structure members will need to be marked as _Nullable, if the structure is expected to be bzero()ed. Also, do you have any experience in avoiding to diagnose a _Nullable to nonnull assignment _after_ explicitly comparing to NULL? I.e., allow the following: int *_Nullable p; int *q; if (!p) q = p; Thanks, Alex