Path: csiph.com!weretis.net!feeder8.news.weretis.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: New features added into C23 standard Date: Sun, 31 Jul 2022 23:25:06 -0700 Organization: None to speak of Lines: 89 Message-ID: <87wnbsv5tp.fsf@nosuchdomain.example.com> References: <3093c98e-d014-47e4-bcf3-3f108d7c2c03n@googlegroups.com>

<87mtcwzwt9.fsf@nosuchdomain.example.com> <40f5c874-ba25-4020-98a0-b6ce01b38dban@googlegroups.com> <87mtcqwaes.fsf@nosuchdomain.example.com> <20220730162133.56@kylheku.com> <87edy0x2r9.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Info: reader01.eternal-september.org; posting-host="9f4a8c8a3c572d647fa545652ca10113"; logging-data="787406"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/8nE3sO55uxGXMCFSnfGx5" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:mBGZWaSPnD2OatX77y4l8UK0+cs= sha1:f7MLlo9hIFX8XhOHxLzDIF30qtE= Xref: csiph.com comp.lang.c:167017 Malcolm McLean writes: > On Monday, 1 August 2022 at 00:48:40 UTC+1, Keith Thompson wrote: >> Kaz Kylheku <480-99...@kylheku.com> writes: >> > On 2022-07-30, Richard Damon wrote: >> >> On 7/30/22 5:36 PM, Keith Thompson wrote: >> >>> David Brown writes: >> >>> [...] >> >>>> The key problem with null pointers in C code is that "0" is a null >> >>>> pointer as well as an integer constant. So it's easy to mix up these >> >>>> very different purposes when writing or reading code. (Let's be >> >>>> honest here - most null pointers in real code are written "0", not >> >>>> "NULL".) >> >>> [...] >> >>> >> >>> That doesn't match my experience at all. In C, I always use NULL for >> >>> null pointer constants. >> >>> >> >>> (I seem to recall that Stroustrup advocated using 0 as a null pointer >> >>> constant before nullptr was introduced in C++11.) >> >> >> >> C++ had the problem that (void *)0 didn't work for NULL as it doesn't >> >> convert to other pointer types, while a constant expression 0 does. >> > >> > That makes no sense, though. A constant expression 1 does not convert >> > to pointer types in C++; the zero-valued expression only converts >> > because there is a hack in the language: that of the expression doubling >> > as a null pointer constant, just like in C. >> > >> > Exactly the same hack can be implemented to allow (void *) 0 to >> > convert in situations where (void *) 1 won't. >> > >> > C++ made a mess of the null pointer area; now the crap is seeping into C. >> I disagree. >> >> C++ added nullptr in the 2011 standard. It's a keyword that >> is a null pointer constant and *only* a null pointer constant, >> not requiring any special case rules about converting integer >> expressions. >> >> In addition, C++ narrowed the definition of "null pointer >> constant", so it can be an integer literal (not a more general >> integer constant expression, and not cast to void*) or a prvalue >> of type std::nullptr_t. >> >> C++ still defines NULL as an implementation-defined null pointer >> constant in . That's necessary to avoid breaking existing >> code. >> >> But if you ignore all that and just use nullptr when you want a >> null pointer constant, the result is IMHO much cleaner. I'm glad >> to see C adopting a similar solution. >> > The question is whether NULL is really a language feature, or just a > construct that programmers tend to find useful. What's the difference? > In original C, char *ptr = 0x1234; would put address 1234 hex in ptr, > unproblematically. So char *ptr = 0; wasn't special. `char *ptr = 0x1234; has been a constraint violation since C89. > Nowadays, C has > been ported to widely different architectures, and absolute addresses > in notionally portable code cannot be supported. So we have a special > rule for the null pointer. > Also, because historically null has been all bits zero, an if statement > is defined to evaluate false if passed a null pointer. Historically, perhaps, but since at least 1989 a null pointer value is treated as false regardless of how it's represented. > But are those tiny areas of explicit language support enough to say that, > therefore, null deserves its own keyword? The whole philosophy of C > is that it is minimal. Everything that can be done by C code rather than > by the compiler is done by C code. The exception, floating point operations > on systems without floating point hardware, is very much a special case. That's not the "whole philosohy" of C. Yes, in my opinion the null pointer deserves its own keyword. So do true and fase (which are keywords in C23). If you don't like them, you don't have to use them. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips void Void(void) { Void(); } /* The recursive call of the void */