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 1 of 5  [1] 2 3 4 5  Next page →

#166921 — New features added into C23 standard

-  nullptr
- typed enumerations
- improved normal enumerations
- Comma omission and comma deletion
- constexpr
- auto
- TIME_MONOTONIC
- bit-precise bit-fields
- relaxed requirements for variadic parameter lists
- embed
...

[toc] | [next] | [standalone]

#166924

Thiago Adams <thiago.adams@gmail.com> writes:

> -  nullptr
> - typed enumerations
> - improved normal enumerations
> - Comma omission and comma deletion
> - constexpr
> - auto
> - TIME_MONOTONIC
> - bit-precise bit-fields
> - relaxed requirements for variadic parameter lists
> - embed

At the late stage, presumably this is all agreed material?

-- 
Ben.

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

#166928

On Friday, 22 July 2022 at 20:32:12 UTC+1, Thiago Adams wrote:
> - nullptr 
> - typed enumerations 
> - improved normal enumerations 
> - Comma omission and comma deletion 
> - constexpr 
> - auto 
> - TIME_MONOTONIC 
> - bit-precise bit-fields 
> - relaxed requirements for variadic parameter lists 
> - embed 
> ...
Comma omission and comma deletion?

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

#166929

In article <916ae40e-0ec2-4acc-9fe3-6e52f40bde86n@googlegroups.com>,
Malcolm McLean  <malcolm.arthur.mclean@gmail.com> wrote:
>On Friday, 22 July 2022 at 20:32:12 UTC+1, Thiago Adams wrote:
>> - nullptr 
>> - typed enumerations 
>> - improved normal enumerations 
>> - Comma omission and comma deletion 
>> - constexpr 
>> - auto 
>> - TIME_MONOTONIC 
>> - bit-precise bit-fields 
>> - relaxed requirements for variadic parameter lists 
>> - embed 
>> ...
>Comma omission and comma deletion?

Check out:

    https://www.open-std.org/JTC1/SC22/WG14/www/docs/n2160.htm

-- 
They say compassion is a virtue, but I don't have the time!

    - David Byrne -

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

#166933

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.

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

#166934

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. 
"

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

#166936

Thiago Adams <thiago.adams@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.)

-- 
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]

#166937

On Monday, July 25, 2022 at 6:50:41 PM UTC-3, 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.) 
> 

I  cannot see any problem with (void*)  0. 

Apparently this  was considered but I didn't found details about the problem.

"After WG14 refused a specification for a simple macro with value (void*)0, as well as a sophisticated 
version with an incomplete type and with a rewriting approach for many contexts, this new version tries 
a middle ground."

I never see anyone complaining or having bugs with NULL. And the original motivation
for C++ was different.

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

#166938

Thiago Adams <thiago.adams@gmail.com> writes:
> On Monday, July 25, 2022 at 6:50:41 PM UTC-3, 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.) 
>> 
>
> I  cannot see any problem with (void*)  0. 
>
> Apparently this  was considered but I didn't found details about the problem.
>
> "After WG14 refused a specification for a simple macro with value (void*)0, as well as a sophisticated 
> version with an incomplete type and with a rewriting approach for many contexts, this new version tries 
> a middle ground."

I think what WG14 refused was defining nullptr as a macro expanding to
((void*)0).  Given that NULL is commonly defined that way, there
wouldn't have been much point.

> I never see anyone complaining or having bugs with NULL. And the original motivation
> for C++ was different.

One example: The (POSIX, not ISO C) execl() function requires its last
argument to be a null pointer, marking the end of the arguments.

    int execl(const char *pathname, const char *arg, ...
              /* (char  *) NULL */);

If you don't cast the NULL argument to an appropriate type, you have
undefined behavior, because it can be of integer type (typically int if
NULL is defined as 0).

That particular problem could be addressed by requiring NULL to be
defined as exactly ((void*)0).  I don't know whether that would leave
problems, but that could just be a lack of imagination on my part.
(Incidentally, C23 updates the section on parenthesized expressions to
make it clear that a parenthesized null pointer constant is a null
pointer constant.)

Just as a matter of personal preference, I like the idea of having a
null pointer constant built into the language, as a lot of other
languages do.  Note that with nullptr as a keyword, you don't have to
include any header to get a null pointer constant (or remember which
headers define NULL).

-- 
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]

#166939

On Monday, July 25, 2022 at 10:05:00 PM UTC-3, Keith Thompson wrote:
> Thiago Adams <thiago...@gmail.com> writes: 
> > On Monday, July 25, 2022 at 6:50:41 PM UTC-3, 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.) 
> >> 
> > 
> > I cannot see any problem with (void*) 0. 
> > 
> > Apparently this was considered but I didn't found details about the problem. 
> > 
> > "After WG14 refused a specification for a simple macro with value (void*)0, as well as a sophisticated 
> > version with an incomplete type and with a rewriting approach for many contexts, this new version tries 
> > a middle ground."
> I think what WG14 refused was defining nullptr as a macro expanding to 
> ((void*)0). Given that NULL is commonly defined that way, there 
> wouldn't have been much point.
> > I never see anyone complaining or having bugs with NULL. And the original motivation 
> > for C++ was different.
> One example: The (POSIX, not ISO C) execl() function requires its last 
> argument to be a null pointer, marking the end of the arguments. 
> 
> int execl(const char *pathname, const char *arg, ... 
> /* (char *) NULL */); 
> 
> If you don't cast the NULL argument to an appropriate type, you have 
> undefined behavior, because it can be of integer type (typically int if 
> NULL is defined as 0). 
> 
> That particular problem could be addressed by requiring NULL to be 
> defined as exactly ((void*)0). I don't know whether that would leave 
> problems, but that could just be a lack of imagination on my part. 
> (Incidentally, C23 updates the section on parenthesized expressions to 
> make it clear that a parenthesized null pointer constant is a null 
> pointer constant.) 
> 
> Just as a matter of personal preference, I like the idea of having a 
> null pointer constant built into the language, as a lot of other 
> languages do. Note that with nullptr as a keyword, you don't have to 
> include any header to get a null pointer constant (or remember which 
> headers define NULL).
> -- 
> Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com 
> Working, but not speaking, for Philips 
> void Void(void) { Void(); } /* The recursive call of the void */

I would like to have NULL as keyword and defined as ((void*) 0).

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

#166940

Le 26/07/2022 à 04:23, Thiago Adams a écrit :
> On Monday, July 25, 2022 at 10:05:00 PM UTC-3, Keith Thompson wrote:
>> Thiago Adams <thiago...@gmail.com> writes:
>>> On Monday, July 25, 2022 at 6:50:41 PM UTC-3, 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.)
>>>>
>>>
>>> I cannot see any problem with (void*) 0.
>>>
>>> Apparently this was considered but I didn't found details about the problem.
>>>
>>> "After WG14 refused a specification for a simple macro with value (void*)0, as well as a sophisticated
>>> version with an incomplete type and with a rewriting approach for many contexts, this new version tries
>>> a middle ground."
>> I think what WG14 refused was defining nullptr as a macro expanding to
>> ((void*)0). Given that NULL is commonly defined that way, there
>> wouldn't have been much point.
>>> I never see anyone complaining or having bugs with NULL. And the original motivation
>>> for C++ was different.
>> One example: The (POSIX, not ISO C) execl() function requires its last
>> argument to be a null pointer, marking the end of the arguments.
>>
>> int execl(const char *pathname, const char *arg, ...
>> /* (char *) NULL */);
>>
>> If you don't cast the NULL argument to an appropriate type, you have
>> undefined behavior, because it can be of integer type (typically int if
>> NULL is defined as 0).
>>
>> That particular problem could be addressed by requiring NULL to be
>> defined as exactly ((void*)0). I don't know whether that would leave
>> problems, but that could just be a lack of imagination on my part.
>> (Incidentally, C23 updates the section on parenthesized expressions to
>> make it clear that a parenthesized null pointer constant is a null
>> pointer constant.)
>>
>> Just as a matter of personal preference, I like the idea of having a
>> null pointer constant built into the language, as a lot of other
>> languages do. Note that with nullptr as a keyword, you don't have to
>> include any header to get a null pointer constant (or remember which
>> headers define NULL).
>> -- 
>> Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
>> Working, but not speaking, for Philips
>> void Void(void) { Void(); } /* The recursive call of the void */
> 
> I would like to have NULL as keyword and defined as ((void*) 0).

I think the whole idea with C is to break as little existing code as 
possible.

Since NULL was never required to be exactly '(void *) 0' before, making 
it so in C23 would thus potentially break existing code. (Not saying 
that the code it would potentially break would not be questionable, but 
just the way it is.)

So, I get the idea of defining a new keyword here and not "breaking" the 
existing NULL. Adding new 'features' is OK, changing the definition of 
an existing feature in the standard is a lot more difficult. That's 
actually what has made the strength of C and I can understand why the 
commitee wouldn't want to break that.

With that said, if anything, the existence itself of a "null" pointer is 
questionable. It's usually used as an "invalid" pointer (guaranteed to 
be unambiguously invalid), but the fact its value is tied to '0' (and I 
don't think nullptr changes this?) can be problematic. I think the 
underlying value should be made platform-dependent. If that's what 
nullptr is, good, but I am not sure.

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

#166942

On 7/25/22 11:13 PM, Opus wrote:
> Le 26/07/2022 à 04:23, Thiago Adams a écrit :
>> On Monday, July 25, 2022 at 10:05:00 PM UTC-3, Keith Thompson wrote:
>>> Thiago Adams <thiago...@gmail.com> writes:
>>>> On Monday, July 25, 2022 at 6:50:41 PM UTC-3, 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.)
>>>>>
>>>>
>>>> I cannot see any problem with (void*) 0.
>>>>
>>>> Apparently this was considered but I didn't found details about the 
>>>> problem.
>>>>
>>>> "After WG14 refused a specification for a simple macro with value 
>>>> (void*)0, as well as a sophisticated
>>>> version with an incomplete type and with a rewriting approach for 
>>>> many contexts, this new version tries
>>>> a middle ground."
>>> I think what WG14 refused was defining nullptr as a macro expanding to
>>> ((void*)0). Given that NULL is commonly defined that way, there
>>> wouldn't have been much point.
>>>> I never see anyone complaining or having bugs with NULL. And the 
>>>> original motivation
>>>> for C++ was different.
>>> One example: The (POSIX, not ISO C) execl() function requires its last
>>> argument to be a null pointer, marking the end of the arguments.
>>>
>>> int execl(const char *pathname, const char *arg, ...
>>> /* (char *) NULL */);
>>>
>>> If you don't cast the NULL argument to an appropriate type, you have
>>> undefined behavior, because it can be of integer type (typically int if
>>> NULL is defined as 0).
>>>
>>> That particular problem could be addressed by requiring NULL to be
>>> defined as exactly ((void*)0). I don't know whether that would leave
>>> problems, but that could just be a lack of imagination on my part.
>>> (Incidentally, C23 updates the section on parenthesized expressions to
>>> make it clear that a parenthesized null pointer constant is a null
>>> pointer constant.)
>>>
>>> Just as a matter of personal preference, I like the idea of having a
>>> null pointer constant built into the language, as a lot of other
>>> languages do. Note that with nullptr as a keyword, you don't have to
>>> include any header to get a null pointer constant (or remember which
>>> headers define NULL).
>>> -- 
>>> Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
>>> Working, but not speaking, for Philips
>>> void Void(void) { Void(); } /* The recursive call of the void */
>>
>> I would like to have NULL as keyword and defined as ((void*) 0).
> 
> I think the whole idea with C is to break as little existing code as 
> possible.
> 
> Since NULL was never required to be exactly '(void *) 0' before, making 
> it so in C23 would thus potentially break existing code. (Not saying 
> that the code it would potentially break would not be questionable, but 
> just the way it is.)
> 
> So, I get the idea of defining a new keyword here and not "breaking" the 
> existing NULL. Adding new 'features' is OK, changing the definition of 
> an existing feature in the standard is a lot more difficult. That's 
> actually what has made the strength of C and I can understand why the 
> commitee wouldn't want to break that.
> 
> With that said, if anything, the existence itself of a "null" pointer is 
> questionable. It's usually used as an "invalid" pointer (guaranteed to 
> be unambiguously invalid), but the fact its value is tied to '0' (and I 
> don't think nullptr changes this?) can be problematic. I think the 
> underlying value should be made platform-dependent. If that's what 
> nullptr is, good, but I am not sure.
> 
> 

First, some program may correctly depend on an implementation guarentee 
that NULL was a value of 0, which has been perfectly valid in the past. 
Just because it make the program non-portable, doesn't automatically 
make it bad.

Second, as to NULL pointers having the value 0, they don't. Only an 
actual constant value of 0 gets converted to a NULL pointer value, and 
expression that just happens to be 0 doesn't (if you force it with a 
cast, it MAY become a NULL pointer, but that isn't actually guarenteed 
by the standard as a remember).

When converting a pointer value to a bool, a NULL pointer get converted 
to 0, and non-HULL pointers to 1. What happens with a pointer value that 
is all bits 0 depends on if that just happens to be a NULL pointer or not.

Yes, there are a lot of things that make it hard on an implementation if 
all bits 0 isn't a NULL pointer, but nothing says it actually has to 
be), unless I have missed something new.

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

#166943

On 7/25/2022 8:13 PM, Opus wrote:
> 
> With that said, if anything, the existence itself of a "null" pointer is 
> questionable. It's usually used as an "invalid" pointer (guaranteed to 
> be unambiguously invalid), but the fact its value is tied to '0' (and I 
> don't think nullptr changes this?) can be problematic. 
> 

Null pointer constant (NPC) is "tied to 0" at source code level only. 
The underlying physical value - null pointer value - is not zero/does 
not have to be zero. The underlying physical value has always been 
implementation-dependent. There's nothing problematic here and there's 
nothing to change.

-- 
Best regards,
Andrey

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

#166961

Opus <ifonly@youknew.org> writes:
[...]
> I think the whole idea with C is to break as little existing code as
> possible.
>
> Since NULL was never required to be exactly '(void *) 0' before,
> making it so in C23 would thus potentially break existing code. (Not
> saying that the code it would potentially break would not be
> questionable, but just the way it is.)

A small quibble: NULL cannot be `(void*)0`, because library macros are
required to be fully parenthesized.  With that definition, `sizeof NULL`
would be parsed incorrectly.

It's commonly defined as `((void*)0)`.  (Strictly speaking, the language
doesn't guarantee that a parenthesized null pointer constant is a null
pointer constant, but in practice it is, and C23 makes that explicit.)

> So, I get the idea of defining a new keyword here and not "breaking"
> the existing NULL. Adding new 'features' is OK, changing the
> definition of an existing feature in the standard is a lot more
> difficult. That's actually what has made the strength of C and I can
> understand why the commitee wouldn't want to break that.
>
> With that said, if anything, the existence itself of a "null" pointer
> is questionable. It's usually used as an "invalid" pointer (guaranteed
> to be unambiguously invalid), but the fact its value is tied to '0'
> (and I don't think nullptr changes this?) can be problematic. I think
> the underlying value should be made platform-dependent. If that's what 
> nullptr is, good, but I am not sure.

The representation of the null pointer (null pointerS, actually, since
there are different pointer types) is unspecified.  The link to 0 is at
the source code level only.  If an implementation uses a representation
other than all-bits-zero for a null pointer, then the conversion in
`(void*)0` is non-trivial.

Note that converting a non-constant 0 to a pointer type is not
guaranteed to yield a null pointer value.

Most implementations use all-bits-zero for null pointers because it's
simpler.

-- 
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]

#166960

Thiago Adams <thiago.adams@gmail.com> writes:
[...]
> I would like to have NULL as keyword and defined as ((void*) 0).

If it were a keyword, it wouldn't be defined as anything.

If it were a macro (as it currently is), it wouldn't be a keyword.

I suppose you could have NULL both as a keyword and as a macro,
but I don't see the point of that.

-- 
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]

#166994

On 26/07/2022 00:51, Thiago Adams wrote:
> On Monday, July 25, 2022 at 6:50:41 PM UTC-3, 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.)
>>
> 
> I  cannot see any problem with (void*)  0.
> 
> Apparently this  was considered but I didn't found details about the problem.
> 
> "After WG14 refused a specification for a simple macro with value (void*)0, as well as a sophisticated
> version with an incomplete type and with a rewriting approach for many contexts, this new version tries
> a middle ground."
> 
> I never see anyone complaining or having bugs with NULL. And the original motivation
> for C++ was different.

As I see it, the point of "nullptr" is not because there is something 
wrong with NULL, 0, or "(void*) 0".  It is because "nullptr" is 
/better/, and gives you a clearer way to write your code, more 
opportunities for checking, and thus lower risk of errors in your code 
(for those that take advantage of the new feature and appropriate 
tools).  It does this without affecting existing code.

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".)

If you get in the habit of using "nullptr" as your null pointer, that 
mixup is gone.  And your tools can check this, giving a warning whenever 
"0" is used in the context of a pointer.

"nullptr" is not as useful in C as it is in C++, since there is no 
function overloading and thus no need to determine if "foo(0)" meant an 
integer parameter or a pointer parameter, but it might still be handy 
with _Generic.

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

#166995

David Brown <david.brown@hesbynett.no> writes:
>On 26/07/2022 00:51, Thiago Adams wrote:
>> On Monday, July 25, 2022 at 6:50:41 PM UTC-3, Keith Thompson wrote:

>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".)

Actually, I've been programming for quite a while in C and C++,
mainly in the OS/Hypervisor space, and I've not seen any use "0" instead of
NULL at the source level.  Not since Unix v6, anyway.

I have seen common usage like this in modern code:

 char *ptr = NULL;
...
 if (ptr) ...

however, most coding guidelines we've used prefer 'if (ptr != NULL)',
particularly in C++.

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

#166996

On Saturday, 30 July 2022 at 16:18:31 UTC+1, Scott Lurndal wrote:
> David Brown <david...@hesbynett.no> writes: 
> >On 26/07/2022 00:51, Thiago Adams wrote: 
> >> On Monday, July 25, 2022 at 6:50:41 PM UTC-3, Keith Thompson wrote: 
> 
> >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".)
> Actually, I've been programming for quite a while in C and C++, 
> mainly in the OS/Hypervisor space, and I've not seen any use "0" instead of 
> NULL at the source level. Not since Unix v6, anyway. 
> 
> I have seen common usage like this in modern code: 
> 
> char *ptr = NULL; 
> ... 
> if (ptr) ... 
> 
> however, most coding guidelines we've used prefer 'if (ptr != NULL)', 
> particularly in C++.
>
Our code base uses 0 and NULL interchangeably, with no particular rules
or preferences. I've never found this to be a problem. 

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

#166997

David Brown <david.brown@hesbynett.no> writes:

> On 26/07/2022 00:51, Thiago Adams wrote:
>> On Monday, July 25, 2022 at 6:50:41 PM UTC-3, 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.)
>>>
>> I  cannot see any problem with (void*)  0.
>> Apparently this  was considered but I didn't found details about the problem.
>> "After WG14 refused a specification for a simple macro with value (void*)0, as well as a sophisticated
>> version with an incomplete type and with a rewriting approach for many contexts, this new version tries
>> a middle ground."
>> I never see anyone complaining or having bugs with NULL. And the original motivation
>> for C++ was different.
>
> As I see it, the point of "nullptr" is not because there is something
> wrong with NULL, 0, or "(void*) 0".  It is because "nullptr" is
> /better/, and gives you a clearer way to write your code, more
> opportunities for checking, and thus lower risk of errors in your code
> (for those that take advantage of the new feature and appropriate
> tools).  It does this without affecting existing code.

Except for those programs that have decided to use that perfectly
ordinary name!

> 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.

The only problem I see is not really a case of confusing the two, and
that's using 0 in variable arguments where a pointer is expected.  Here,
nullptr wins over the NULL because, at least technically, NULL might be
plain 0 (or some other constant integer expression)

The lowest impact change would have been to require the expansion of
NULL to be an expression of type void *.  But I think the new committee
is inclined to go the C++ route: more changes, and more alignment, even
at the cost of some code breakage.

> (Let's be honest here - most null pointers in real code are written
> "0", not "NULL".)

Technically, using NULL is not a fix, since NULL /could/ expand to 0.
No implementation I know of does this (because of the var args problem)
but it's possible.

Using NULL might avoid what you see as the possibility of confusing the
two uses, but then I don't think I've come across that.

> If you get in the habit of using "nullptr" as your null pointer, that
> mixup is gone.  And your tools can check this, giving a warning
> whenever "0" is used in the context of a pointer.

Bu the only case that really matters can't be warned against.

> "nullptr" is not as useful in C as it is in C++, since there is no
> function overloading and thus no need to determine if "foo(0)" meant
> an integer parameter or a pointer parameter, but it might still be
> handy with _Generic.

How?  (I've not see the new draft so there may be something I',
missing...)

-- 
Ben.

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

#167002

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 26/07/2022 00:51, Thiago Adams wrote:
>>> On Monday, July 25, 2022 at 6:50:41 PM UTC-3, 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.)
>>>>
>>> I  cannot see any problem with (void*)  0.
>>> Apparently this  was considered but I didn't found details about the problem.
>>> "After WG14 refused a specification for a simple macro with value (void*)0, as well as a sophisticated
>>> version with an incomplete type and with a rewriting approach for many contexts, this new version tries
>>> a middle ground."
>>> I never see anyone complaining or having bugs with NULL. And the original motivation
>>> for C++ was different.
>>
>> As I see it, the point of "nullptr" is not because there is something
>> wrong with NULL, 0, or "(void*) 0".  It is because "nullptr" is
>> /better/, and gives you a clearer way to write your code, more
>> opportunities for checking, and thus lower risk of errors in your code
>> (for those that take advantage of the new feature and appropriate
>> tools).  It does this without affecting existing code.
>
> Except for those programs that have decided to use that perfectly
> ordinary name!

Right.  I wonder how much code defines nullptr as an identifer.  I
suspect it's not much, especially given that it's a keyword in C++.

Except that I can imagine some programmers might do something like
    #define nullptr ((void*)0)
just because they like the name.  But a macro definition likely
wouldn't cause any problems.

[...]

>> "nullptr" is not as useful in C as it is in C++, since there is no
>> function overloading and thus no need to determine if "foo(0)" meant
>> an integer parameter or a pointer parameter, but it might still be
>> handy with _Generic.
>
> How?  (I've not see the new draft so there may be something I',
> missing...)

nullptr is of the distinct type nullptr_t, which is a scalar type but
not a pointer or integer type, so a generic selection might have to
account for it.

(nullptr_t is not a keyword; rather it's defined in <stddef.h> as
something like `typeof(nullptr)`).

-- 
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]

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

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

csiph-web