Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "Chris M. Thomasson" Newsgroups: comp.lang.c Subject: Re: question about nullptr Date: Mon, 8 Jul 2024 23:17:23 -0700 Organization: A noiseless patient Spider Lines: 73 Message-ID: References: <90c2181ae4c7aac8f17f076093923d5b357c43aa@i2pn2.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Tue, 09 Jul 2024 08:17:25 +0200 (CEST) Injection-Info: dont-email.me; posting-host="ce358e0d0d9664a700ff455d87f9b3cd"; logging-data="1356776"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19+4yj9mkJuPTxAv1YvVp6nk34LuO21abI=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:jiS4PdbyDITvw2c+Rf8ATRyaJuY= Content-Language: en-US In-Reply-To: Bytes: 3568 On 7/8/2024 10:42 PM, Richard Harnden wrote: > On 06/07/2024 17:57, David Brown wrote: >> On 06/07/2024 16:39, Richard Damon wrote: >>> On 7/6/24 7:49 AM, Thiago Adams wrote: >>>> If you were creating C code today and could use a C23 compiler, >>>> would you use nullptr instead of NULL? >>>> >>>> I am asking because I think I will keep using NULL. >>>> >>>> I like nullptr semantics but I don't like to introduce new element >>>> (nullptr) inside the code with no guarantee that the code will not >>>> mix both. >>>> >>>> In the past we also didn't have a guarantee we are not mixing 0 or >>>> NULL. >>>> >>>> I think the best scenario for a team guideline would be a style >>>> warning if 0 or nullptr is used and NULL to be defined as nullptr in >>>> a C23 compiler. >>>> >>> >>> The (small) problem with 0 or NULL being use is that in a context >>> where you THINK you are passing a pointer, but the function actually >>> is taking an integer value, 0 or NULL (defined as a 0) passes the >>> syntax check. >>> >>> If C23 REQURIED NULL to be defined as nullptr, then NULL would have >>> been used, but as far as I know, it is still allowed to be defined as >>> 0 (unless you also have POSIX compatibility). >>> >>> With POSIX Compatibility, where NULL must have the type of (void*) >>> you also avoid the possible error, and thus the desire to use nullptr. >> >> I hope that defining NULL as nullptr will become common - but I would >> be surprised to ever see it being required by C standards. >> >> The ideal would be for C libraries to define NULL as nullptr and for C >> compilers to support a flag like gcc's >> "-Wzero-as-null-pointer-constant" warning (it is currently C++ only). >> Then people can easily eliminate >> any mixup between integer 0 and null pointer constants by using that >> flag and either NULL or nullptr, according to taste.  (And those who >> don't want such checks, are not required to change.) >> >> > > So, if malloc was changed to 'returns nullptr and sets errno on error', > will you still be able to say: > > if ( p == NULL ) ... > if ( !p ) ... > > ? This of a pointer p where: p = 0; p == NULL == true; p == 0 == true; Therefore (! p) means that p is 0, or NULL if you will.. Fair enough? Side note: Tell NULL and 0 to NAND CAT: https://youtu.be/kdCJunw_Jgg How long can you listen to this before you snuff it?