Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #166921 > unrolled thread

New features added into C23 standard

Back to article view | Back to comp.lang.c

Contents

  New features added into C23 standard Thiago Adams <thiago.adams@gmail.com> - 2022-07-22 12:32 -0700
    Re: New features added into C23 standard Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-07-22 23:15 +0100
    Re: New features added into C23 standard Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-07-23 01:31 -0700
      Re: New features added into C23 standard gazelle@shell.xmission.com (Kenny McCormack) - 2022-07-23 10:10 +0000
    Re: New features added into C23 standard Thiago Adams <thiago.adams@gmail.com> - 2022-07-25 13:49 -0700
      Re: New features added into C23 standard Thiago Adams <thiago.adams@gmail.com> - 2022-07-25 13:57 -0700
        Re: New features added into C23 standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-25 14:50 -0700
          Re: New features added into C23 standard Thiago Adams <thiago.adams@gmail.com> - 2022-07-25 15:51 -0700
            Re: New features added into C23 standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-25 18:04 -0700
              Re: New features added into C23 standard Thiago Adams <thiago.adams@gmail.com> - 2022-07-25 19:23 -0700
                Re: New features added into C23 standard Opus <ifonly@youknew.org> - 2022-07-26 05:13 +0200
                  Re: New features added into C23 standard Richard Damon <Richard@Damon-Family.org> - 2022-07-25 23:36 -0400
                  Re: New features added into C23 standard Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-07-25 21:52 -0700
                  Re: New features added into C23 standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-26 11:44 -0700
                Re: New features added into C23 standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-26 11:39 -0700
            Re: New features added into C23 standard David Brown <david.brown@hesbynett.no> - 2022-07-30 14:42 +0200
              Re: New features added into C23 standard scott@slp53.sl.home (Scott Lurndal) - 2022-07-30 15:18 +0000
                Re: New features added into C23 standard Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-07-30 09:13 -0700
              Re: New features added into C23 standard Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-07-30 17:31 +0100
                Re: New features added into C23 standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-30 16:46 -0700
              Re: New features added into C23 standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-30 14:36 -0700
                Re: New features added into C23 standard Richard Damon <Richard@Damon-Family.org> - 2022-07-30 18:15 -0400
                  Re: New features added into C23 standard Kaz Kylheku <480-992-1380@kylheku.com> - 2022-07-30 23:28 +0000
                    Re: New features added into C23 standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-31 16:48 -0700
                      Re: New features added into C23 standard Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-07-31 22:42 -0700
                        Re: New features added into C23 standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-31 23:25 -0700
                          Re: New features added into C23 standard Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-08-01 00:10 -0700
                            Re: New features added into C23 standard David Brown <david.brown@hesbynett.no> - 2022-08-01 09:55 +0200
                        Re: New features added into C23 standard Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-01 20:17 +0100
                Re: New features added into C23 standard Kaz Kylheku <480-992-1380@kylheku.com> - 2022-07-30 23:21 +0000
          Re: New features added into C23 standard Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-07-25 22:59 -0700
            Re: New features added into C23 standard Öö Tiib <ootiib@hot.ee> - 2022-07-26 00:48 -0700
              Re: New features added into C23 standard Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-07-26 02:08 -0700
                Re: New features added into C23 standard Richard Damon <Richard@Damon-Family.org> - 2022-07-26 06:59 -0400
                Re: New features added into C23 standard Öö Tiib <ootiib@hot.ee> - 2022-07-26 04:02 -0700
                  Re: New features added into C23 standard Vir Campestris <vir.campestris@invalid.invalid> - 2022-07-29 21:18 +0100
                    Re: New features added into C23 standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-29 16:55 -0700
                Re: New features added into C23 standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-26 11:51 -0700
              Re: New features added into C23 standard David Brown <david.brown@hesbynett.no> - 2022-07-31 11:12 +0200
                Re: New features added into C23 standard Richard Damon <Richard@Damon-Family.org> - 2022-07-31 07:40 -0400
                  Re: New features added into C23 standard Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-07-31 17:40 +0100
                    Re: New features added into C23 standard Richard Damon <Richard@Damon-Family.org> - 2022-07-31 12:56 -0400
                      Re: New features added into C23 standard Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-07-31 19:28 +0100
                        Re: New features added into C23 standard Richard Damon <Richard@Damon-Family.org> - 2022-07-31 14:52 -0400
                          Re: New features added into C23 standard Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-07-31 21:35 +0100
                          Re: New features added into C23 standard Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-15 23:24 -0700
                        Re: New features added into C23 standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-31 16:57 -0700
                  Re: New features added into C23 standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-31 16:55 -0700
                    Re: New features added into C23 standard Richard Damon <Richard@Damon-Family.org> - 2022-07-31 20:09 -0400
                      Re: New features added into C23 standard Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-15 22:52 -0700
                        Re: New features added into C23 standard David Brown <david.brown@hesbynett.no> - 2022-08-16 09:21 +0200
                          Re: New features added into C23 standard Philipp Klaus Krause <pkk@spth.de> - 2022-08-16 09:32 +0200
                            Re: New features added into C23 standard David Brown <david.brown@hesbynett.no> - 2022-08-16 11:06 +0200
                  Re: New features added into C23 standard Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-15 23:17 -0700
                    Re: New features added into C23 standard Richard Damon <Richard@Damon-Family.org> - 2022-08-17 20:11 -0400
                      Re: New features added into C23 standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-17 20:08 -0700
                        Re: New features added into C23 standard Richard Damon <Richard@Damon-Family.org> - 2022-08-17 23:19 -0400
                          Re: New features added into C23 standard Kaz Kylheku <480-992-1380@kylheku.com> - 2022-08-18 07:03 +0000
                      Re: New features added into C23 standard Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-23 09:43 -0700
                        Re: New features added into C23 standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-23 11:02 -0700
                          Re: New features added into C23 standard Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-23 13:40 -0700
            Re: New features added into C23 standard Richard Damon <Richard@Damon-Family.org> - 2022-07-26 07:04 -0400
              Re: New features added into C23 standard Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-07-26 05:24 -0700
                Re: New features added into C23 standard Richard Damon <Richard@Damon-Family.org> - 2022-07-26 22:30 -0400
                  Re: New features added into C23 standard Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-07-29 00:02 +0100
                    Re: New features added into C23 standard Richard Damon <Richard@Damon-Family.org> - 2022-07-28 21:20 -0400
                      Re: New features added into C23 standard William Ahern <william@25thandClement.com> - 2022-07-28 19:36 -0700
                        Re: New features added into C23 standard scott@slp53.sl.home (Scott Lurndal) - 2022-07-29 16:39 +0000
                        Re: New features added into C23 standard Richard Damon <Richard@Damon-Family.org> - 2022-07-29 18:55 -0400
                      Re: New features added into C23 standard Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-07-29 15:17 +0100
            Re: New features added into C23 standard scott@slp53.sl.home (Scott Lurndal) - 2022-07-26 13:27 +0000
            Re: New features added into C23 standard Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-07-26 11:47 -0700
              Re: New features added into C23 standard Kaz Kylheku <480-992-1380@kylheku.com> - 2022-07-26 20:27 +0000
                Re: New features added into C23 standard Philipp Klaus Krause <pkk@spth.de> - 2022-08-16 08:42 +0200
    Re: New features added into C23 standard Bonita Montero <Bonita.Montero@gmail.com> - 2022-07-26 05:37 +0200
      Re: New features added into C23 standard Lynn McGuire <lynnmcguire5@gmail.com> - 2022-07-28 16:47 -0500
        Re: New features added into C23 standard Bonita Montero <Bonita.Montero@gmail.com> - 2022-07-29 07:14 +0200
          Re: New features added into C23 standard Vir Campestris <vir.campestris@invalid.invalid> - 2022-07-29 21:21 +0100
    Re: New features added into C23 standard Grant Mulholland <grantlmul@gmail.com> - 2022-08-13 22:21 -0700
      Re: New features added into C23 standard Lynn McGuire <lynnmcguire5@gmail.com> - 2022-08-15 21:21 -0500
        Re: New features added into C23 standard Bonita Montero <Bonita.Montero@gmail.com> - 2022-08-16 08:39 +0200
      Re: New features added into C23 standard Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-15 22:54 -0700
      Re: New features added into C23 standard Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-08-18 12:03 -0700
        Re: New features added into C23 standard "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-08-18 12:56 -0700
        Re: New features added into C23 standard William Ahern <william@25thandClement.com> - 2022-08-18 16:07 -0700
          Re: New features added into C23 standard Thiago Adams <thiago.adams@gmail.com> - 2022-08-18 18:47 -0700
            Re: New features added into C23 standard Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-08-18 20:23 -0700

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#166998

David Brown <david.brown@hesbynett.no> 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.)

-- 
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 */

[toc] | [prev] | [next] | [standalone]

#166999

On 7/30/22 5:36 PM, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> 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.

Many C implementations defined it that way then.

[toc] | [prev] | [next] | [standalone]

#167001

On 2022-07-30, Richard Damon <Richard@Damon-Family.org> wrote:
> On 7/30/22 5:36 PM, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> 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.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

[toc] | [prev] | [next] | [standalone]

#167012

Kaz Kylheku <480-992-1380@kylheku.com> writes:
> On 2022-07-30, Richard Damon <Richard@Damon-Family.org> wrote:
>> On 7/30/22 5:36 PM, Keith Thompson wrote:
>>> David Brown <david.brown@hesbynett.no> 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 <cstddef>.  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.

-- 
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 */

[toc] | [prev] | [next] | [standalone]

#167016

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 <Ric...@Damon-Family.org> wrote: 
> >> On 7/30/22 5:36 PM, Keith Thompson wrote: 
> >>> David Brown <david...@hesbynett.no> 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 <cstddef>. 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.
In original C, char *ptr = 0x1234; would put address 1234 hex in ptr,
unproblematically. So char *ptr = 0; wasn't special. 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.

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.

[toc] | [prev] | [next] | [standalone]

#167017

Malcolm McLean <malcolm.arthur.mclean@gmail.com> 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 <Ric...@Damon-Family.org> wrote: 
>> >> On 7/30/22 5:36 PM, Keith Thompson wrote: 
>> >>> David Brown <david...@hesbynett.no> 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 <cstddef>. 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 */

[toc] | [prev] | [next] | [standalone]

#167018

On Monday, 1 August 2022 at 07:25:20 UTC+1, Keith Thompson wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes: 
> 
> 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.
>
No, that's naive. 

[toc] | [prev] | [next] | [standalone]

#167019

On 01/08/2022 09:10, Malcolm McLean wrote:
> On Monday, 1 August 2022 at 07:25:20 UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> 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.
>>
> No, that's naive.

Not in this case, no.

When a new feature is added to the language core or the standard 
library, you might come across it in other people's code even if you 
don't use it yourself.  That's always a possibility.  (But the same can 
be said of any construct in any language, regardless of changes - I 
don't like shouty all-caps macro names, but I still have to use them in 
code from elsewhere.)

I think it is probably fair to say that almost any C code that uses 
identifiers "true" or "false" in a way that conflicts with having them 
as keywords representing constants of type _Bool is either pathological 
(such as using "sizeof(false)"), incorrect code (such as accidentally 
using "false" as a null pointer), or weird legacy code from the dark 
ages (such as code that #define's "true" as -1).

Exceptions will be pretty much negligible.

The only place I could imagine getting trouble would be code that 
defines "true" and "false" itself, rather than using <stdbool.h>. 
Hopefully such legacy code will be relatively rare now, but it is 
clearly a possible issue.


The likelihood of the identifier "nullptr" being used for anything other 
than a null pointer (usually for compatibility with C++) is almost 
non-existent, as is the likelihood of misunderstanding it when you read 
it (even if you are unfamiliar with C++ or C23).

[toc] | [prev] | [next] | [standalone]

#167021

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> The question is whether NULL is really a language feature, or just a
> construct that programmers tend to find useful.
> In original C, char *ptr = 0x1234; would put address 1234 hex in ptr,
> unproblematically.

No.  The conversion from integer types to pointer types required a cast
in "original C" (by which I mean K&R C).  K&R C included accesses that
are not conversions (due to not having function prototypes) and they
have always been considered risky.  K&R (the book) has a section
"Pointer are not integers" to explain this pitfall -- one that no longer
exists in modern C.

> So char *ptr = 0; wasn't special.

0 has always been special in regard to pointer.  How special has indeed
changed over the years, but it has never been "just another number" in
relation to pointers.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#167000

On 2022-07-30, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> David Brown <david.brown@hesbynett.no> 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 dislike it that NULL may or may not just be zero.  If it expands to
((void *) 0), then certain misuses of NULL fail to be diagnosed.

On the one hand, something silly like  char x = NULL does get
diagnosed, while printf("%p", NULL) looks correct.

Take the code #define-NULL-0 platform, and this reverses; char x = NULL
is nonchalantly accepted, whereas if there are printf format string
diagnostics, printf("%p", NULL) warns.

Defining NULL as 0 should have been deprecated decades ago, with
implementations strongly encouraged to abandon the practice.

I'd be in favor of making NULL the language built-in; i.e.
use that as the spelling of nullptr.

Implementations could #define NULL NULL so that there is a macro.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

[toc] | [prev] | [next] | [standalone]

#166944

On Monday, 25 July 2022 at 22:50:41 UTC+1, Keith Thompson wrote:
> Thiago Adams <thiago...@gmail.com> writes: 
> > On Monday, July 25, 2022 at 5:49:30 PM UTC-3, Thiago Adams wrote: 
> >> It's hard to believe how nullptr was accepted. 
> >> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3039.htm 
> >> The same for auto and constexpr. 
> > 
> > In 2018 I suggested nullptr 
> > 
> > https://groups.google.com/g/comp.lang.c/c/YJmom4rC2FI/m/DJzGmwXmCQAJ 
> > 
> > In 2019 I replied my own message saying that was a bad idea. 
> > https://groups.google.com/g/comp.lang.c/c/YJmom4rC2FI/m/Daz0AvxHAwAJ 
> > 
> > I agree with myself from 2019. 
> > " 
> > One difference between adding _Bool into the language is that BOOL 
> > was never added into the language headers. (Am I right? I didn't find 
> > BOOL or TRUE FALSE at the language specification). 
> > 
> > On the other hand if you search for NULL at the standard you will 
> > find that NULL is defined in stddef.h 
> > 
> > This means that adding _Bool didn't added a new way to declare booleans, 
> > but adding nullptr will create this confusion that is two ways of 
> > writing code that means NULL. 
> > 
> > In C we also have different ((void*)0) conversion rules compared with 
> > C++ that is more strict. 
> > 
> > Then for C, I believe that the literal that corresponds nullptr already 
> > exists and it is ((void*)0). 
> > 
> > What could be done is adding flags to static analysis to decide what 
> > to do with ((void*)0) conversions. 
> > "
> I don't see the problem. There are already arbitrarily many ways to 
> write a null pointer constant in C. For example, '\0' '-'-'-', and 
> 0x0ULL are all null pointer constants. 
> 
> A null pointer constant can be of any integer type, or of type void*. 
> 
> Adding nullptr and nullptr_t adds one more form of null pointer 
> constant, and an unambiguous type for nullptr. Of course NULL and 
> (void*)0 are still valid, because invalidating them would break tons of 
> existing code -- but nullptr is the new preferred way to write a null 
> pointer constant. Old code is still valid, but new code can be cleaner 
> -- and if a user writes nullptr, there's no question that it was 
> *intended* to be a null pointer constant, which could result in clearer 
> diagnostic messages. 
> 
> (It's likely that if the language were being defined from scratch, 
> nullptr would be the *only* way to write a null pointer constant. The 
> stuff about using integer constant expressions exists only for backward 
> compatibility, and we're stuck with it.) 
> 
There are two issues.
One is that on some architectures, writing to memory address zero is a
valid thing to do. Whilst you can argue that, in that case, a null pointer
should not be all bits zero, in reality it will be, and it will be obvious from 
context where a write to address zero is intended.

The other one is that you often have pointers embedded in structures,
which you zero-initialise. Again, you can argue that this is wrong because
a null pointer isn't necessarily all bits zero, but it is a widely used practice.
Also the struct s = {0}; syntax implies that null == zero, even though it
doesn't actually require that.
  

[toc] | [prev] | [next] | [standalone]

#166946

On Tuesday, 26 July 2022 at 09:00:06 UTC+3, Malcolm McLean wrote:
> On Monday, 25 July 2022 at 22:50:41 UTC+1, Keith Thompson wrote: 
> > Thiago Adams <thiago...@gmail.com> writes: 
> > > On Monday, July 25, 2022 at 5:49:30 PM UTC-3, Thiago Adams wrote: 
> > >> It's hard to believe how nullptr was accepted. 
> > >> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3039.htm 
> > >> The same for auto and constexpr. 
> > > 
> > > In 2018 I suggested nullptr 
> > > 
> > > https://groups.google.com/g/comp.lang.c/c/YJmom4rC2FI/m/DJzGmwXmCQAJ 
> > > 
> > > In 2019 I replied my own message saying that was a bad idea. 
> > > https://groups.google.com/g/comp.lang.c/c/YJmom4rC2FI/m/Daz0AvxHAwAJ 
> > > 
> > > I agree with myself from 2019. 
> > > " 
> > > One difference between adding _Bool into the language is that BOOL 
> > > was never added into the language headers. (Am I right? I didn't find 
> > > BOOL or TRUE FALSE at the language specification). 
> > > 
> > > On the other hand if you search for NULL at the standard you will 
> > > find that NULL is defined in stddef.h 
> > > 
> > > This means that adding _Bool didn't added a new way to declare booleans, 
> > > but adding nullptr will create this confusion that is two ways of 
> > > writing code that means NULL. 
> > > 
> > > In C we also have different ((void*)0) conversion rules compared with 
> > > C++ that is more strict. 
> > > 
> > > Then for C, I believe that the literal that corresponds nullptr already 
> > > exists and it is ((void*)0). 
> > > 
> > > What could be done is adding flags to static analysis to decide what 
> > > to do with ((void*)0) conversions. 
> > > " 
> > I don't see the problem. There are already arbitrarily many ways to 
> > write a null pointer constant in C. For example, '\0' '-'-'-', and 
> > 0x0ULL are all null pointer constants. 
> > 
> > A null pointer constant can be of any integer type, or of type void*. 
> > 
> > Adding nullptr and nullptr_t adds one more form of null pointer 
> > constant, and an unambiguous type for nullptr. Of course NULL and 
> > (void*)0 are still valid, because invalidating them would break tons of 
> > existing code -- but nullptr is the new preferred way to write a null 
> > pointer constant. Old code is still valid, but new code can be cleaner 
> > -- and if a user writes nullptr, there's no question that it was 
> > *intended* to be a null pointer constant, which could result in clearer 
> > diagnostic messages. 
> > 
> > (It's likely that if the language were being defined from scratch, 
> > nullptr would be the *only* way to write a null pointer constant. The 
> > stuff about using integer constant expressions exists only for backward 
> > compatibility, and we're stuck with it.) 
> >
> There are two issues. 
> One is that on some architectures, writing to memory address zero is a 
> valid thing to do. Whilst you can argue that, in that case, a null pointer 
> should not be all bits zero, in reality it will be, and it will be obvious from 
> context where a write to address zero is intended. 

Said corner case (when accessing memory at address zero is actually
intended) should happen only to people who are implementing
executive environment on such architecture. That means they are on
side of providers of whatever guarantees not on side of consumers
of those. 

> The other one is that you often have pointers embedded in structures, 
> which you zero-initialise. Again, you can argue that this is wrong because 
> a null pointer isn't necessarily all bits zero, but it is a widely used practice. 
> Also the struct s = {0}; syntax implies that null == zero, even though it 
> doesn't actually require that.

Nothing implies that struct s = {nullptr}; results with s having all bits zero.
When all platforms that the code is targeting guarantee that it results (and
it matters) then there is nothing to worry. When there is doubt (and as you
already said it has likely no ground) then static_assert has been in 
<assert.h> for decade. 

[toc] | [prev] | [next] | [standalone]

#166947

On Tuesday, 26 July 2022 at 08:48:15 UTC+1, Öö Tiib wrote:
> On Tuesday, 26 July 2022 at 09:00:06 UTC+3, Malcolm McLean wrote: 
> > On Monday, 25 July 2022 at 22:50:41 UTC+1, Keith Thompson wrote: 
> > > Thiago Adams <thiago...@gmail.com> writes: 
> > > > On Monday, July 25, 2022 at 5:49:30 PM UTC-3, Thiago Adams wrote: 
> > > >> It's hard to believe how nullptr was accepted. 
> > > >> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3039.htm 
> > > >> The same for auto and constexpr. 
> > > > 
> > > > In 2018 I suggested nullptr 
> > > > 
> > > > https://groups.google.com/g/comp.lang.c/c/YJmom4rC2FI/m/DJzGmwXmCQAJ 
> > > > 
> > > > In 2019 I replied my own message saying that was a bad idea. 
> > > > https://groups.google.com/g/comp.lang.c/c/YJmom4rC2FI/m/Daz0AvxHAwAJ 
> > > > 
> > > > I agree with myself from 2019. 
> > > > " 
> > > > One difference between adding _Bool into the language is that BOOL 
> > > > was never added into the language headers. (Am I right? I didn't find 
> > > > BOOL or TRUE FALSE at the language specification). 
> > > > 
> > > > On the other hand if you search for NULL at the standard you will 
> > > > find that NULL is defined in stddef.h 
> > > > 
> > > > This means that adding _Bool didn't added a new way to declare booleans, 
> > > > but adding nullptr will create this confusion that is two ways of 
> > > > writing code that means NULL. 
> > > > 
> > > > In C we also have different ((void*)0) conversion rules compared with 
> > > > C++ that is more strict. 
> > > > 
> > > > Then for C, I believe that the literal that corresponds nullptr already 
> > > > exists and it is ((void*)0). 
> > > > 
> > > > What could be done is adding flags to static analysis to decide what 
> > > > to do with ((void*)0) conversions. 
> > > > " 
> > > I don't see the problem. There are already arbitrarily many ways to 
> > > write a null pointer constant in C. For example, '\0' '-'-'-', and 
> > > 0x0ULL are all null pointer constants. 
> > > 
> > > A null pointer constant can be of any integer type, or of type void*. 
> > > 
> > > Adding nullptr and nullptr_t adds one more form of null pointer 
> > > constant, and an unambiguous type for nullptr. Of course NULL and 
> > > (void*)0 are still valid, because invalidating them would break tons of 
> > > existing code -- but nullptr is the new preferred way to write a null 
> > > pointer constant. Old code is still valid, but new code can be cleaner 
> > > -- and if a user writes nullptr, there's no question that it was 
> > > *intended* to be a null pointer constant, which could result in clearer 
> > > diagnostic messages. 
> > > 
> > > (It's likely that if the language were being defined from scratch, 
> > > nullptr would be the *only* way to write a null pointer constant. The 
> > > stuff about using integer constant expressions exists only for backward 
> > > compatibility, and we're stuck with it.) 
> > > 
> > There are two issues. 
> > One is that on some architectures, writing to memory address zero is a 
> > valid thing to do. Whilst you can argue that, in that case, a null pointer 
> > should not be all bits zero, in reality it will be, and it will be obvious from 
> > context where a write to address zero is intended.
> Said corner case (when accessing memory at address zero is actually 
> intended) should happen only to people who are implementing 
> executive environment on such architecture. That means they are on 
> side of providers of whatever guarantees not on side of consumers 
> of those.
> > The other one is that you often have pointers embedded in structures, 
> > which you zero-initialise. Again, you can argue that this is wrong because 
> > a null pointer isn't necessarily all bits zero, but it is a widely used practice. 
> > Also the struct s = {0}; syntax implies that null == zero, even though it 
> > doesn't actually require that.
> Nothing implies that struct s = {nullptr}; results with s having all bits zero. 
> When all platforms that the code is targeting guarantee that it results (and 
> it matters) then there is nothing to worry. When there is doubt (and as you 
> already said it has likely no ground) then static_assert has been in 
> <assert.h> for decade.
>
You often see memset(&s, 0, sizeof(struct s)); Microsoft even provide a function called
ZeroMemory() to make this a bit more explicit. It's expected that any embedded pointers
will be set to null. If we treat nullptr as an abstract symbol rather than a bit pattern,
then it's less obvious what this code is doing. However you can argue that it is
broken anyway. But you'd be hard-pressed to find an architecture on which it
actually breaks. 

[toc] | [prev] | [next] | [standalone]

#166951

On 7/26/22 5:08 AM, Malcolm McLean wrote:
> You often see memset(&s, 0, sizeof(struct s)); Microsoft even provide a function called
> ZeroMemory() to make this a bit more explicit. It's expected that any embedded pointers
> will be set to null. If we treat nullptr as an abstract symbol rather than a bit pattern,
> then it's less obvious what this code is doing. However you can argue that it is
> broken anyway. But you'd be hard-pressed to find an architecture on which it
> actually breaks.

It may be "expected", but in general it isn't defined to be, even though 
it will work on most machines.

And today it probably works on most machines because it is expected to 
work and more efficient if it is that way. Some machines even bent them 
selves a bit to make sure that an all zero pointer was valid as a NULL 
pointer value.

[toc] | [prev] | [next] | [standalone]

#166952

On Tuesday, 26 July 2022 at 12:08:55 UTC+3, Malcolm McLean wrote:
> On Tuesday, 26 July 2022 at 08:48:15 UTC+1, Öö Tiib wrote: 
> > On Tuesday, 26 July 2022 at 09:00:06 UTC+3, Malcolm McLean wrote: 
> > > On Monday, 25 July 2022 at 22:50:41 UTC+1, Keith Thompson wrote: 
> > > > Thiago Adams <thiago...@gmail.com> writes: 
> > > > > On Monday, July 25, 2022 at 5:49:30 PM UTC-3, Thiago Adams wrote: 
> > > > >> It's hard to believe how nullptr was accepted. 
> > > > >> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3039.htm 
> > > > >> The same for auto and constexpr. 
> > > > > 
> > > > > In 2018 I suggested nullptr 
> > > > > 
> > > > > https://groups.google.com/g/comp.lang.c/c/YJmom4rC2FI/m/DJzGmwXmCQAJ 
> > > > > 
> > > > > In 2019 I replied my own message saying that was a bad idea. 
> > > > > https://groups.google.com/g/comp.lang.c/c/YJmom4rC2FI/m/Daz0AvxHAwAJ 
> > > > > 
> > > > > I agree with myself from 2019. 
> > > > > " 
> > > > > One difference between adding _Bool into the language is that BOOL 
> > > > > was never added into the language headers. (Am I right? I didn't find 
> > > > > BOOL or TRUE FALSE at the language specification). 
> > > > > 
> > > > > On the other hand if you search for NULL at the standard you will 
> > > > > find that NULL is defined in stddef.h 
> > > > > 
> > > > > This means that adding _Bool didn't added a new way to declare booleans, 
> > > > > but adding nullptr will create this confusion that is two ways of 
> > > > > writing code that means NULL. 
> > > > > 
> > > > > In C we also have different ((void*)0) conversion rules compared with 
> > > > > C++ that is more strict. 
> > > > > 
> > > > > Then for C, I believe that the literal that corresponds nullptr already 
> > > > > exists and it is ((void*)0). 
> > > > > 
> > > > > What could be done is adding flags to static analysis to decide what 
> > > > > to do with ((void*)0) conversions. 
> > > > > " 
> > > > I don't see the problem. There are already arbitrarily many ways to 
> > > > write a null pointer constant in C. For example, '\0' '-'-'-', and 
> > > > 0x0ULL are all null pointer constants. 
> > > > 
> > > > A null pointer constant can be of any integer type, or of type void*. 
> > > > 
> > > > Adding nullptr and nullptr_t adds one more form of null pointer 
> > > > constant, and an unambiguous type for nullptr. Of course NULL and 
> > > > (void*)0 are still valid, because invalidating them would break tons of 
> > > > existing code -- but nullptr is the new preferred way to write a null 
> > > > pointer constant. Old code is still valid, but new code can be cleaner 
> > > > -- and if a user writes nullptr, there's no question that it was 
> > > > *intended* to be a null pointer constant, which could result in clearer 
> > > > diagnostic messages. 
> > > > 
> > > > (It's likely that if the language were being defined from scratch, 
> > > > nullptr would be the *only* way to write a null pointer constant. The 
> > > > stuff about using integer constant expressions exists only for backward 
> > > > compatibility, and we're stuck with it.) 
> > > > 
> > > There are two issues. 
> > > One is that on some architectures, writing to memory address zero is a 
> > > valid thing to do. Whilst you can argue that, in that case, a null pointer 
> > > should not be all bits zero, in reality it will be, and it will be obvious from 
> > > context where a write to address zero is intended. 
> > Said corner case (when accessing memory at address zero is actually 
> > intended) should happen only to people who are implementing 
> > executive environment on such architecture. That means they are on 
> > side of providers of whatever guarantees not on side of consumers 
> > of those. 
> > > The other one is that you often have pointers embedded in structures, 
> > > which you zero-initialise. Again, you can argue that this is wrong because 
> > > a null pointer isn't necessarily all bits zero, but it is a widely used practice. 
> > > Also the struct s = {0}; syntax implies that null == zero, even though it 
> > > doesn't actually require that. 
> > Nothing implies that struct s = {nullptr}; results with s having all bits zero. 
> > When all platforms that the code is targeting guarantee that it results (and 
> > it matters) then there is nothing to worry. When there is doubt (and as you 
> > already said it has likely no ground) then static_assert has been in 
> > <assert.h> for decade. 
> >
> You often see memset(&s, 0, sizeof(struct s)); Microsoft even provide a function called 
> ZeroMemory() to make this a bit more explicit.

Computer architectures and operating systems can provide guarantees that
are not in C standard. Programmers can use those. But why should C standard
dictate requirements to underlying architecture or operating system? It is not
in its sphere of influence.

> It's expected that any embedded pointers will be set to null.

It is reasonable expectation that is guaranteed by things outside of C standard. 

> If we treat nullptr as an abstract symbol rather than a bit pattern, 
> then it's less obvious what this code is doing. However you can argue that it is 
> broken anyway. But you'd be hard-pressed to find an architecture on which it 
> actually breaks.

Then I'd look C FAQ question 5.17 <https://c-faq.com/null/machexamp.html>
Even when that would become clear that such platforms are inferior somehow,
(how?) then why it matters? C standard is not meant to address everything in
our industry.  
   

[toc] | [prev] | [next] | [standalone]

#166987

On 26/07/2022 12:02, Öö Tiib wrote:
> Then I'd look C FAQ question 5.17<https://c-faq.com/null/machexamp.html>
> Even when that would become clear that such platforms are inferior somehow,
> (how?) then why it matters? C standard is not meant to address everything in
> our industry.

I could add another architecture into that FAQ - if I had an account.

<https://en.wikipedia.org/wiki/ICL_2900_Series#Addressing_mechanisms>

describes the ICL 2900 descriptor register. This contains address, data 
size of target, array index limit, and various other stuff.

Setting DR to all zeroes would give a trap on access luckily.

I wrote assembler for it _many_ years ago, but never C.

Andy

[toc] | [prev] | [next] | [standalone]

#166990

Vir Campestris <vir.campestris@invalid.invalid> writes:
> On 26/07/2022 12:02, Öö Tiib wrote:
>> Then I'd look C FAQ question 5.17<https://c-faq.com/null/machexamp.html>
>> Even when that would become clear that such platforms are inferior somehow,
>> (how?) then why it matters? C standard is not meant to address everything in
>> our industry.
>
> I could add another architecture into that FAQ - if I had an account.
>
> <https://en.wikipedia.org/wiki/ICL_2900_Series#Addressing_mechanisms>
>
> describes the ICL 2900 descriptor register. This contains address,
> data size of target, array index limit, and various other stuff.

There is no "account".  Steve Summit maintains the FAQ personally.

> Setting DR to all zeroes would give a trap on access luckily.
>
> I wrote assembler for it _many_ years ago, but never C.

-- 
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 */

[toc] | [prev] | [next] | [standalone]

#166963

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> You often see memset(&s, 0, sizeof(struct s)); Microsoft even provide
> a function called ZeroMemory() to make this a bit more explicit. It's
> expected that any embedded pointers will be set to null. If we treat
> nullptr as an abstract symbol rather than a bit pattern, then it's
> less obvious what this code is doing. However you can argue that it is
> broken anyway. But you'd be hard-pressed to find an architecture on
> which it actually breaks.

Yes, you can write non-portable code if you're targeting an
implementation that makes additional guarantees beyond those provided by
the language standard.

If your code will only run under an implementation that guarantees that
null pointers and floating-point zeros are represented as all-bits-zero,
you can safely zero your structures and assume that its members will
have the values you want.

Non-portable code isn't necessarily wrong or "broken".  It's just
non-portable.

-- 
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 */

[toc] | [prev] | [next] | [standalone]

#167004

On 26/07/2022 09:48, Öö Tiib wrote:
> On Tuesday, 26 July 2022 at 09:00:06 UTC+3, Malcolm McLean wrote:
>> On Monday, 25 July 2022 at 22:50:41 UTC+1, Keith Thompson wrote:
>>> Thiago Adams <thiago...@gmail.com> writes:
>>>> On Monday, July 25, 2022 at 5:49:30 PM UTC-3, Thiago Adams wrote:
>>>>> It's hard to believe how nullptr was accepted.
>>>>> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3039.htm
>>>>> The same for auto and constexpr.
>>>>
>>>> In 2018 I suggested nullptr
>>>>
>>>> https://groups.google.com/g/comp.lang.c/c/YJmom4rC2FI/m/DJzGmwXmCQAJ
>>>>
>>>> In 2019 I replied my own message saying that was a bad idea.
>>>> https://groups.google.com/g/comp.lang.c/c/YJmom4rC2FI/m/Daz0AvxHAwAJ
>>>>
>>>> I agree with myself from 2019.
>>>> "
>>>> One difference between adding _Bool into the language is that BOOL
>>>> was never added into the language headers. (Am I right? I didn't find
>>>> BOOL or TRUE FALSE at the language specification).
>>>>
>>>> On the other hand if you search for NULL at the standard you will
>>>> find that NULL is defined in stddef.h
>>>>
>>>> This means that adding _Bool didn't added a new way to declare booleans,
>>>> but adding nullptr will create this confusion that is two ways of
>>>> writing code that means NULL.
>>>>
>>>> In C we also have different ((void*)0) conversion rules compared with
>>>> C++ that is more strict.
>>>>
>>>> Then for C, I believe that the literal that corresponds nullptr already
>>>> exists and it is ((void*)0).
>>>>
>>>> What could be done is adding flags to static analysis to decide what
>>>> to do with ((void*)0) conversions.
>>>> "
>>> I don't see the problem. There are already arbitrarily many ways to
>>> write a null pointer constant in C. For example, '\0' '-'-'-', and
>>> 0x0ULL are all null pointer constants.
>>>
>>> A null pointer constant can be of any integer type, or of type void*.
>>>
>>> Adding nullptr and nullptr_t adds one more form of null pointer
>>> constant, and an unambiguous type for nullptr. Of course NULL and
>>> (void*)0 are still valid, because invalidating them would break tons of
>>> existing code -- but nullptr is the new preferred way to write a null
>>> pointer constant. Old code is still valid, but new code can be cleaner
>>> -- and if a user writes nullptr, there's no question that it was
>>> *intended* to be a null pointer constant, which could result in clearer
>>> diagnostic messages.
>>>
>>> (It's likely that if the language were being defined from scratch,
>>> nullptr would be the *only* way to write a null pointer constant. The
>>> stuff about using integer constant expressions exists only for backward
>>> compatibility, and we're stuck with it.)
>>>
>> There are two issues.
>> One is that on some architectures, writing to memory address zero is a
>> valid thing to do. Whilst you can argue that, in that case, a null pointer
>> should not be all bits zero, in reality it will be, and it will be obvious from
>> context where a write to address zero is intended.
> 
> Said corner case (when accessing memory at address zero is actually
> intended) should happen only to people who are implementing
> executive environment on such architecture. That means they are on
> side of providers of whatever guarantees not on side of consumers
> of those.
> 

It is also not uncommon in microcontrollers for address zero to be a 
useful address - and then it is user code that needs access.  But it is 
rarely an issue in practice.  The most common situation is having it as 
part of the flash for code, and it is typically part of the interrupt 
vectors or reset vector.  You would only want to read it for something 
like a CRC check of the flash, and if you are concerned about the 
compiler handling a pointer to address zero in an unhelpful manner, you 
can use a pointer-to-volatile.  The other cases I have seen are having 
memory mapped peripherals there - and again, you always use volatile 
accesses.

>> The other one is that you often have pointers embedded in structures,
>> which you zero-initialise. Again, you can argue that this is wrong because
>> a null pointer isn't necessarily all bits zero, but it is a widely used practice. >> Also the struct s = {0}; syntax implies that null == zero, even 
though it
>> doesn't actually require that.
> 
> Nothing implies that struct s = {nullptr}; results with s having all bits zero.

Indeed.  The same applies to "struct s = { 0 };", if the first field is 
a pointer.  Logically, the fields are initialised exactly as they would 
be if they were individual variables of the appropriate types.

> When all platforms that the code is targeting guarantee that it results (and
> it matters) then there is nothing to worry. When there is doubt (and as you
> already said it has likely no ground) then static_assert has been in
> <assert.h> for decade.
> 

[toc] | [prev] | [next] | [standalone]

#167005

On 7/31/22 5:12 AM, David Brown wrote:
> 
> It is also not uncommon in microcontrollers for address zero to be a 
> useful address - and then it is user code that needs access.  But it is 
> rarely an issue in practice.  The most common situation is having it as 
> part of the flash for code, and it is typically part of the interrupt 
> vectors or reset vector.  You would only want to read it for something 
> like a CRC check of the flash, and if you are concerned about the 
> compiler handling a pointer to address zero in an unhelpful manner, you 
> can use a pointer-to-volatile.  The other cases I have seen are having 
> memory mapped peripherals there - and again, you always use volatile 
> accesses.

And for machine specific case like this, the fact that derefencing a 
NULL pointer is "just" Undefined Behavior, that can be Implementaton 
Defined to do what is wanted, as opposed to some how PROHIBITED.

*(char *0) = 0;

Is a fully legal statement that must be translated.

Yes, when you execute it, you get undefined behavior, but that might be 
just simply defined to write to location 0.

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web