Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #386797 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2024-07-06 08:49 -0300 |
| Last post | 2024-08-25 23:45 -0400 |
| Articles | 15 on this page of 135 — 19 participants |
Back to article view | Back to comp.lang.c
question about nullptr Thiago Adams <thiago.adams@gmail.com> - 2024-07-06 08:49 -0300
Re: question about nullptr Bonita Montero <Bonita.Montero@gmail.com> - 2024-07-06 14:13 +0200
Re: question about nullptr John McCue <jmccue@neutron.jmcunx.com> - 2024-07-06 12:33 +0000
Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-06 12:54 +0000
Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-06 15:07 +0200
Re: question about nullptr scott@slp53.sl.home (Scott Lurndal) - 2024-07-06 14:04 +0000
Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-06 16:42 +0200
Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-06 16:45 +0200
Re: question about nullptr Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-07-06 10:50 -0700
Re: question about nullptr scott@slp53.sl.home (Scott Lurndal) - 2024-07-06 23:04 +0000
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-06 20:06 -0700
Re: question about nullptr bart <bc@freeuk.com> - 2024-07-06 19:20 +0100
Re: question about nullptr scott@slp53.sl.home (Scott Lurndal) - 2024-07-06 23:09 +0000
Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-06 16:31 -0700
Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-06 13:23 -0700
Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-06 13:28 -0700
Re: question about nullptr Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-07 08:01 +0000
Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-08 22:08 -0700
Re: question about nullptr Richard Damon <richard@damon-family.org> - 2024-07-06 17:04 -0400
Re: question about nullptr scott@slp53.sl.home (Scott Lurndal) - 2024-07-06 23:10 +0000
Re: question about nullptr scott@slp53.sl.home (Scott Lurndal) - 2024-07-06 23:03 +0000
Re: question about nullptr James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-06 21:44 -0400
Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-06 19:29 -0700
Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-07 12:53 -0700
Re: question about nullptr Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-07 08:03 +0000
Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-06 23:14 +0100
Re: question about nullptr scott@slp53.sl.home (Scott Lurndal) - 2024-07-06 23:13 +0000
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-06 20:10 -0700
Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-07 08:46 +0000
Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-07 19:59 +0100
Re: question about nullptr scott@slp53.sl.home (Scott Lurndal) - 2024-07-07 19:40 +0000
Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-07 15:17 -0700
Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-08 20:11 +0200
Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-08 13:32 -0700
Re: question about nullptr Michael S <already5chosen@yahoo.com> - 2024-07-08 22:28 +0300
Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-08 15:23 -0700
Re: question about nullptr Michael S <already5chosen@yahoo.com> - 2024-07-09 10:48 +0300
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-09 04:32 -0700
Re: question about nullptr Thiago Adams <thiago.adams@gmail.com> - 2024-07-09 09:10 -0300
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-09 07:52 -0700
Re: question about nullptr Thiago Adams <thiago.adams@gmail.com> - 2024-07-09 13:16 -0300
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-09 14:22 -0700
Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-09 22:25 +0000
Re: question about nullptr Thiago Adams <thiago.adams@gmail.com> - 2024-07-10 08:50 -0300
Re: question about nullptr Michael S <already5chosen@yahoo.com> - 2024-07-09 15:50 +0300
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-09 07:50 -0700
Re: question about nullptr David Brown <david.brown@hesbynett.no> - 2024-07-09 18:19 +0200
Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-09 02:49 +0000
Re: question about nullptr Michael S <already5chosen@yahoo.com> - 2024-07-09 11:00 +0300
Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-09 08:21 +0000
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-09 03:57 -0700
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-08 20:17 -0700
Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-08 21:01 -0700
Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-08 22:06 -0700
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-10 07:51 -0700
Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-10 14:23 -0700
Re: question about nullptr James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-10 18:50 -0400
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-12 17:42 -0700
Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-12 18:33 -0700
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-12 18:10 -0700
Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-12 18:44 -0700
Re: question about nullptr scott@slp53.sl.home (Scott Lurndal) - 2024-07-08 14:09 +0000
Re: question about nullptr Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-07-08 21:45 -0700
Re: question about nullptr Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-07-08 21:49 -0700
Re: question about nullptr Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-11 02:42 +0000
Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-08 22:58 -0700
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-10 07:36 -0700
Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-10 14:15 -0700
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-11 20:52 -0700
Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-08 20:07 +0200
Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-08 23:55 +0100
Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-10 17:28 +0200
Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-11 00:25 +0100
Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-12 14:08 +0200
Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-13 00:59 +0100
Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-13 04:01 +0200
Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-15 00:00 +0100
Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-13 04:18 +0200
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-17 09:26 -0700
Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-08 12:29 +0200
Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-08 17:23 +0100
Re: question about nullptr James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-08 11:03 -0400
Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-09 02:45 +0000
Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-08 11:08 +0200
Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-08 11:18 +0100
Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-09 02:32 +0000
Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-08 22:02 -0700
Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-09 10:21 +0100
Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-10 17:32 -0700
Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-11 02:12 +0100
Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-10 18:41 -0700
Re: question about nullptr Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-11 02:38 +0000
Re: question about nullptr Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-07-12 14:11 +0200
Re: question about nullptr Richard Damon <richard@damon-family.org> - 2024-07-08 07:18 -0400
Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-08 07:19 +0000
Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-08 00:42 +0100
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-06 20:36 -0700
Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-06 22:11 +0000
Re: question about nullptr bart <bc@freeuk.com> - 2024-07-06 14:51 +0100
Re: question about nullptr Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-07 04:55 +0000
Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-07 00:04 -0700
Re: question about nullptr bart <bc@freeuk.com> - 2024-07-07 18:40 +0100
Re: question about nullptr Richard Harnden <richard.nospam@gmail.invalid> - 2024-07-12 14:19 +0100
Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-12 21:52 +0000
Re: question about nullptr scott@slp53.sl.home (Scott Lurndal) - 2024-07-12 22:27 +0000
Re: question about nullptr Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-12 23:28 +0000
Re: question about nullptr scott@slp53.sl.home (Scott Lurndal) - 2024-07-13 00:10 +0000
Re: question about nullptr James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-12 20:28 -0400
Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-12 17:30 -0700
Re: question about nullptr Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-13 17:21 -0700
Re: question about nullptr Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-15 22:51 +0000
Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-15 16:32 -0700
Re: question about nullptr James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-15 19:49 -0400
Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-15 18:22 -0700
Re: question about nullptr dave_thompson_2@comcast.net - 2024-08-25 16:55 -0400
Re: question about nullptr Richard Damon <richard@damon-family.org> - 2024-08-25 17:09 -0400
Re: question about nullptr James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-25 23:46 -0400
Re: question about nullptr Richard Damon <richard@damon-family.org> - 2024-07-06 10:39 -0400
Re: question about nullptr David Brown <david.brown@hesbynett.no> - 2024-07-06 18:57 +0200
Re: question about nullptr Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-07 08:00 +0000
Re: question about nullptr David Brown <david.brown@hesbynett.no> - 2024-07-07 12:07 +0200
Re: question about nullptr Thiago Adams <thiago.adams@gmail.com> - 2024-07-07 08:40 -0300
Re: question about nullptr Richard Harnden <richard.nospam@gmail.invalid> - 2024-07-09 06:42 +0100
Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-08 23:17 -0700
Re: question about nullptr Richard Harnden <richard.nospam@gmail.invalid> - 2024-07-09 08:02 +0100
Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-09 00:12 -0700
Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-09 11:14 +0100
Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-09 13:24 -0700
Re: question about nullptr "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-07-09 13:28 -0700
Re: question about nullptr Ben Bacarisse <ben@bsb.me.uk> - 2024-07-10 14:27 +0100
Re: question about nullptr James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-10 11:09 -0400
Re: question about nullptr dave_thompson_2@comcast.net - 2024-08-25 16:56 -0400
Re: question about nullptr James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-25 20:48 -0400
Re: question about nullptr Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-25 18:18 -0700
Re: question about nullptr James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-25 23:45 -0400
Page 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-07-07 12:07 +0200 |
| Message-ID | <v6dpd9$9qv4$1@dont-email.me> |
| In reply to | #386855 |
On 07/07/2024 10:00, Lawrence D'Oliveiro wrote: > On Sat, 6 Jul 2024 18:57:08 +0200, David Brown wrote: > >> ... and for C compilers to support a flag like gcc's "-Wzero-as-null >> -pointer-constant" warning ... > > The trouble with compiler flags is they can never be part of any language > spec. > That is both their advantage, and their disadvantage. Let the C standards define what the language requires when the source code is correct, and have everyone agree on that. Let compiler implementations go beyond that and give options that some might want, and others not want. /I/ will probably use nullptr in C23 coding, and I like tools to enforce my style (because I make mistakes) but I would certainly not want to force others to change their style based on /my/ preferences.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2024-07-07 08:40 -0300 |
| Message-ID | <v6duqm$akaf$1@dont-email.me> |
| In reply to | #386807 |
Em 7/6/2024 1:57 PM, David Brown escreveu: > On 06/07/2024 16:39, Richard Damon wrote: >> On 7/6/24 7:49 AM, Thiago Adams wrote: >>> If you were creating C code today and could use a C23 compiler, would >>> you use nullptr instead of NULL? >>> >>> I am asking because I think I will keep using NULL. >>> >>> I like nullptr semantics but I don't like to introduce new element >>> (nullptr) inside the code with no guarantee that the code will not >>> mix both. >>> >>> In the past we also didn't have a guarantee we are not mixing 0 or NULL. >>> >>> I think the best scenario for a team guideline would be a style >>> warning if 0 or nullptr is used and NULL to be defined as nullptr in >>> a C23 compiler. >>> >> >> The (small) problem with 0 or NULL being use is that in a context >> where you THINK you are passing a pointer, but the function actually >> is taking an integer value, 0 or NULL (defined as a 0) passes the >> syntax check. >> >> If C23 REQURIED NULL to be defined as nullptr, then NULL would have >> been used, but as far as I know, it is still allowed to be defined as >> 0 (unless you also have POSIX compatibility). >> >> With POSIX Compatibility, where NULL must have the type of (void*) you >> also avoid the possible error, and thus the desire to use nullptr. > > I hope that defining NULL as nullptr will become common - but I would be > surprised to ever see it being required by C standards. > > The ideal would be for C libraries to define NULL as nullptr and for C > compilers to support a flag like gcc's "-Wzero-as-null-pointer-constant" > warning (it is currently C++ only). Then people can easily eliminate > any mixup between integer 0 and null pointer constants by using that > flag and either NULL or nullptr, according to taste. (And those who > don't want such checks, are not required to change.) > > I want a compiler flag "define NULL as nullptr"
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2024-07-09 06:42 +0100 |
| Message-ID | <v6iik7$1948o$1@dont-email.me> |
| In reply to | #386807 |
On 06/07/2024 17:57, David Brown wrote: > On 06/07/2024 16:39, Richard Damon wrote: >> On 7/6/24 7:49 AM, Thiago Adams wrote: >>> If you were creating C code today and could use a C23 compiler, would >>> you use nullptr instead of NULL? >>> >>> I am asking because I think I will keep using NULL. >>> >>> I like nullptr semantics but I don't like to introduce new element >>> (nullptr) inside the code with no guarantee that the code will not >>> mix both. >>> >>> In the past we also didn't have a guarantee we are not mixing 0 or NULL. >>> >>> I think the best scenario for a team guideline would be a style >>> warning if 0 or nullptr is used and NULL to be defined as nullptr in >>> a C23 compiler. >>> >> >> The (small) problem with 0 or NULL being use is that in a context >> where you THINK you are passing a pointer, but the function actually >> is taking an integer value, 0 or NULL (defined as a 0) passes the >> syntax check. >> >> If C23 REQURIED NULL to be defined as nullptr, then NULL would have >> been used, but as far as I know, it is still allowed to be defined as >> 0 (unless you also have POSIX compatibility). >> >> With POSIX Compatibility, where NULL must have the type of (void*) you >> also avoid the possible error, and thus the desire to use nullptr. > > I hope that defining NULL as nullptr will become common - but I would be > surprised to ever see it being required by C standards. > > The ideal would be for C libraries to define NULL as nullptr and for C > compilers to support a flag like gcc's "-Wzero-as-null-pointer-constant" > warning (it is currently C++ only). Then people can easily eliminate > any mixup between integer 0 and null pointer constants by using that > flag and either NULL or nullptr, according to taste. (And those who > don't want such checks, are not required to change.) > > So, if malloc was changed to 'returns nullptr and sets errno on error', will you still be able to say: if ( p == NULL ) ... if ( !p ) ... ?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-07-08 23:17 -0700 |
| Message-ID | <v6iklk$19cv8$1@dont-email.me> |
| In reply to | #386916 |
On 7/8/2024 10:42 PM, Richard Harnden wrote: > On 06/07/2024 17:57, David Brown wrote: >> On 06/07/2024 16:39, Richard Damon wrote: >>> On 7/6/24 7:49 AM, Thiago Adams wrote: >>>> If you were creating C code today and could use a C23 compiler, >>>> would you use nullptr instead of NULL? >>>> >>>> I am asking because I think I will keep using NULL. >>>> >>>> I like nullptr semantics but I don't like to introduce new element >>>> (nullptr) inside the code with no guarantee that the code will not >>>> mix both. >>>> >>>> In the past we also didn't have a guarantee we are not mixing 0 or >>>> NULL. >>>> >>>> I think the best scenario for a team guideline would be a style >>>> warning if 0 or nullptr is used and NULL to be defined as nullptr in >>>> a C23 compiler. >>>> >>> >>> The (small) problem with 0 or NULL being use is that in a context >>> where you THINK you are passing a pointer, but the function actually >>> is taking an integer value, 0 or NULL (defined as a 0) passes the >>> syntax check. >>> >>> If C23 REQURIED NULL to be defined as nullptr, then NULL would have >>> been used, but as far as I know, it is still allowed to be defined as >>> 0 (unless you also have POSIX compatibility). >>> >>> With POSIX Compatibility, where NULL must have the type of (void*) >>> you also avoid the possible error, and thus the desire to use nullptr. >> >> I hope that defining NULL as nullptr will become common - but I would >> be surprised to ever see it being required by C standards. >> >> The ideal would be for C libraries to define NULL as nullptr and for C >> compilers to support a flag like gcc's >> "-Wzero-as-null-pointer-constant" warning (it is currently C++ only). >> Then people can easily eliminate >> any mixup between integer 0 and null pointer constants by using that >> flag and either NULL or nullptr, according to taste. (And those who >> don't want such checks, are not required to change.) >> >> > > So, if malloc was changed to 'returns nullptr and sets errno on error', > will you still be able to say: > > if ( p == NULL ) ... > if ( !p ) ... > > ? This of a pointer p where: p = 0; p == NULL == true; p == 0 == true; Therefore (! p) means that p is 0, or NULL if you will.. Fair enough? Side note: Tell NULL and 0 to NAND CAT: https://youtu.be/kdCJunw_Jgg How long can you listen to this before you snuff it?
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2024-07-09 08:02 +0100 |
| Message-ID | <v6inai$19q6r$1@dont-email.me> |
| In reply to | #386918 |
On 09/07/2024 07:17, Chris M. Thomasson wrote: > On 7/8/2024 10:42 PM, Richard Harnden wrote: >> On 06/07/2024 17:57, David Brown wrote: >>> On 06/07/2024 16:39, Richard Damon wrote: >>>> On 7/6/24 7:49 AM, Thiago Adams wrote: >>>>> If you were creating C code today and could use a C23 compiler, >>>>> would you use nullptr instead of NULL? >>>>> >>>>> I am asking because I think I will keep using NULL. >>>>> >>>>> I like nullptr semantics but I don't like to introduce new element >>>>> (nullptr) inside the code with no guarantee that the code will not >>>>> mix both. >>>>> >>>>> In the past we also didn't have a guarantee we are not mixing 0 or >>>>> NULL. >>>>> >>>>> I think the best scenario for a team guideline would be a style >>>>> warning if 0 or nullptr is used and NULL to be defined as nullptr >>>>> in a C23 compiler. >>>>> >>>> >>>> The (small) problem with 0 or NULL being use is that in a context >>>> where you THINK you are passing a pointer, but the function actually >>>> is taking an integer value, 0 or NULL (defined as a 0) passes the >>>> syntax check. >>>> >>>> If C23 REQURIED NULL to be defined as nullptr, then NULL would have >>>> been used, but as far as I know, it is still allowed to be defined >>>> as 0 (unless you also have POSIX compatibility). >>>> >>>> With POSIX Compatibility, where NULL must have the type of (void*) >>>> you also avoid the possible error, and thus the desire to use nullptr. >>> >>> I hope that defining NULL as nullptr will become common - but I would >>> be surprised to ever see it being required by C standards. >>> >>> The ideal would be for C libraries to define NULL as nullptr and for >>> C compilers to support a flag like gcc's >>> "-Wzero-as-null-pointer-constant" warning (it is currently C++ only). >>> Then people can easily eliminate >>> any mixup between integer 0 and null pointer constants by using that >>> flag and either NULL or nullptr, according to taste. (And those who >>> don't want such checks, are not required to change.) >>> >>> >> >> So, if malloc was changed to 'returns nullptr and sets errno on >> error', will you still be able to say: >> >> if ( p == NULL ) ... >> if ( !p ) ... >> >> ? > > This of a pointer p where: > > p = 0; No, I mean when p = nullptr
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-07-09 00:12 -0700 |
| Message-ID | <v6insm$19uag$1@dont-email.me> |
| In reply to | #386920 |
On 7/9/2024 12:02 AM, Richard Harnden wrote: > On 09/07/2024 07:17, Chris M. Thomasson wrote: >> On 7/8/2024 10:42 PM, Richard Harnden wrote: >>> On 06/07/2024 17:57, David Brown wrote: >>>> On 06/07/2024 16:39, Richard Damon wrote: >>>>> On 7/6/24 7:49 AM, Thiago Adams wrote: >>>>>> If you were creating C code today and could use a C23 compiler, >>>>>> would you use nullptr instead of NULL? >>>>>> >>>>>> I am asking because I think I will keep using NULL. >>>>>> >>>>>> I like nullptr semantics but I don't like to introduce new element >>>>>> (nullptr) inside the code with no guarantee that the code will not >>>>>> mix both. >>>>>> >>>>>> In the past we also didn't have a guarantee we are not mixing 0 or >>>>>> NULL. >>>>>> >>>>>> I think the best scenario for a team guideline would be a style >>>>>> warning if 0 or nullptr is used and NULL to be defined as nullptr >>>>>> in a C23 compiler. >>>>>> >>>>> >>>>> The (small) problem with 0 or NULL being use is that in a context >>>>> where you THINK you are passing a pointer, but the function >>>>> actually is taking an integer value, 0 or NULL (defined as a 0) >>>>> passes the syntax check. >>>>> >>>>> If C23 REQURIED NULL to be defined as nullptr, then NULL would have >>>>> been used, but as far as I know, it is still allowed to be defined >>>>> as 0 (unless you also have POSIX compatibility). >>>>> >>>>> With POSIX Compatibility, where NULL must have the type of (void*) >>>>> you also avoid the possible error, and thus the desire to use nullptr. >>>> >>>> I hope that defining NULL as nullptr will become common - but I >>>> would be surprised to ever see it being required by C standards. >>>> >>>> The ideal would be for C libraries to define NULL as nullptr and for >>>> C compilers to support a flag like gcc's >>>> "-Wzero-as-null-pointer-constant" warning (it is currently C++ >>>> only). Then people can easily eliminate >>>> any mixup between integer 0 and null pointer constants by using that >>>> flag and either NULL or nullptr, according to taste. (And those who >>>> don't want such checks, are not required to change.) >>>> >>>> >>> >>> So, if malloc was changed to 'returns nullptr and sets errno on >>> error', will you still be able to say: >>> >>> if ( p == NULL ) ... >>> if ( !p ) ... >>> >>> ? >> >> This of a pointer p where: >> >> p = 0; > > No, I mean when p = nullptr > > p = nullptr; (0 == p == nullptr == NULL == 0) == true ? Am I missing something here? If so, here is a preemptive: Shit!
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-07-09 11:14 +0100 |
| Message-ID | <874j8yswha.fsf@bsb.me.uk> |
| In reply to | #386921 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: > p = nullptr; (p having been declared void *) > (0 == p == nullptr == NULL == 0) == true ? > > Am I missing something here? If so, here is a preemptive: Shit! You are missing that 0 == p == nullptr == NULL == 0 does not mean what you want! It means (((0 == p) == nullptr) == NULL) == 0 and that is a constraint violation. Why? Well 0 == p has value 1 and is of type int and equality comparisons between int and nullptr_t values (of which there is only one) are not permitted. Catching this sort of thing is one of the benefits of nullptr and its associated type nullptr_t. It means that while #define nullptr ((void *)0) can help to get C23 code to compile with a pre-C23 compiler, it might result in some C23 constraint violations going undetected. Anyway, that aside, I know what you meant. To clarify, all of the following have the value 1: 0 == p p == nullptr nullptr == NULL NULL == 0 0 == nullptr !p Note that 0 == nullptr /is/ allowed even though 0 has type int. That is because 0 is also a null pointer constant, and the rules for == and != specifically allow it. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-07-09 13:24 -0700 |
| Message-ID | <v6k6a3$1gsq2$3@dont-email.me> |
| In reply to | #386929 |
On 7/9/2024 3:14 AM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>
>
>> p = nullptr;
>
> (p having been declared void *)
>
>> (0 == p == nullptr == NULL == 0) == true ?
>>
>> Am I missing something here? If so, here is a preemptive: Shit!
>
> You are missing that 0 == p == nullptr == NULL == 0 does not mean what
> you want! It means
>
> (((0 == p) == nullptr) == NULL) == 0
>
> and that is a constraint violation.
>
> Why? Well 0 == p has value 1 and is of type int and equality
> comparisons between int and nullptr_t values (of which there is only
> one) are not permitted. Catching this sort of thing is one of the
> benefits of nullptr and its associated type nullptr_t. It means that
> while
>
> #define nullptr ((void *)0)
>
> can help to get C23 code to compile with a pre-C23 compiler, it might
> result in some C23 constraint violations going undetected.
>
> Anyway, that aside, I know what you meant. To clarify, all of the
> following have the value 1:
>
> 0 == p
> p == nullptr
> nullptr == NULL
> NULL == 0
> 0 == nullptr
> !p
>
> Note that 0 == nullptr /is/ allowed even though 0 has type int. That is
> because 0 is also a null pointer constant, and the rules for == and !=
> specifically allow it.
>
It was a bit of pseudo code. Here is a program:
__________________________
#include <stdio.h>
#include <stdlib.h>
int main()
{
void* p = 0;
if ((p == NULL) && (! p))
{
printf("Good!\n");
}
else
{
printf("Strange? Humm...\n");
}
return 0;
}
__________________________
Good shall be printed even with the following condition right?
__________________________
if ((p == NULL) && (! p) && (p == nullptr))
{
printf("Good!\n");
}
__________________________
Any better Ben?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-07-09 13:28 -0700 |
| Message-ID | <v6k6ha$1gsq2$4@dont-email.me> |
| In reply to | #386958 |
On 7/9/2024 1:24 PM, Chris M. Thomasson wrote:
> On 7/9/2024 3:14 AM, Ben Bacarisse wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>
>>
>>> p = nullptr;
>>
>> (p having been declared void *)
>>
>>> (0 == p == nullptr == NULL == 0) == true ?
>>>
>>> Am I missing something here? If so, here is a preemptive: Shit!
>>
>> You are missing that 0 == p == nullptr == NULL == 0 does not mean what
>> you want! It means
>>
>> (((0 == p) == nullptr) == NULL) == 0
>>
>> and that is a constraint violation.
>>
>> Why? Well 0 == p has value 1 and is of type int and equality
>> comparisons between int and nullptr_t values (of which there is only
>> one) are not permitted. Catching this sort of thing is one of the
>> benefits of nullptr and its associated type nullptr_t. It means that
>> while
>>
>> #define nullptr ((void *)0)
>>
>> can help to get C23 code to compile with a pre-C23 compiler, it might
>> result in some C23 constraint violations going undetected.
>>
>> Anyway, that aside, I know what you meant. To clarify, all of the
>> following have the value 1:
>>
>> 0 == p
>> p == nullptr
>> nullptr == NULL
>> NULL == 0
>> 0 == nullptr
>> !p
>>
>> Note that 0 == nullptr /is/ allowed even though 0 has type int. That is
>> because 0 is also a null pointer constant, and the rules for == and !=
>> specifically allow it.
>>
>
> It was a bit of pseudo code. Here is a program:
> __________________________
> #include <stdio.h>
> #include <stdlib.h>
>
> int main()
> {
> void* p = 0;
>
> if ((p == NULL) && (! p))
> {
> printf("Good!\n");
> }
>
> else
> {
> printf("Strange? Humm...\n");
> }
>
> return 0;
> }
> __________________________
>
> Good shall be printed even with the following condition right?
> __________________________
> if ((p == NULL) && (! p) && (p == nullptr))
> {
> printf("Good!\n");
> }
> __________________________
>
> Any better Ben?
To be more precise, printf shall be called if p is 0, NULL or nullptr...
They are all the same, in a sense, right?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-07-10 14:27 +0100 |
| Message-ID | <87ttgxnzqm.fsf@bsb.me.uk> |
| In reply to | #386959 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> On 7/9/2024 1:24 PM, Chris M. Thomasson wrote:
>> On 7/9/2024 3:14 AM, Ben Bacarisse wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>
>>>
>>>> p = nullptr;
>>>
>>> (p having been declared void *)
>>>
>>>> (0 == p == nullptr == NULL == 0) == true ?
>>>>
>>>> Am I missing something here? If so, here is a preemptive: Shit!
>>>
>>> You are missing that 0 == p == nullptr == NULL == 0 does not mean what
>>> you want! It means
>>>
>>> (((0 == p) == nullptr) == NULL) == 0
>>>
>>> and that is a constraint violation.
>>>
>>> Why? Well 0 == p has value 1 and is of type int and equality
>>> comparisons between int and nullptr_t values (of which there is only
>>> one) are not permitted. Catching this sort of thing is one of the
>>> benefits of nullptr and its associated type nullptr_t. It means that
>>> while
>>>
>>> #define nullptr ((void *)0)
>>>
>>> can help to get C23 code to compile with a pre-C23 compiler, it might
>>> result in some C23 constraint violations going undetected.
>>>
>>> Anyway, that aside, I know what you meant. To clarify, all of the
>>> following have the value 1:
>>>
>>> 0 == p
>>> p == nullptr
>>> nullptr == NULL
>>> NULL == 0
>>> 0 == nullptr
>>> !p
>>>
>>> Note that 0 == nullptr /is/ allowed even though 0 has type int. That is
>>> because 0 is also a null pointer constant, and the rules for == and !=
>>> specifically allow it.
>>>
>> It was a bit of pseudo code.
It looked like C!
>> Here is a program:
>> __________________________
>> #include <stdio.h>
>> #include <stdlib.h>
>> int main()
>> {
>> void* p = 0;
>> if ((p == NULL) && (! p))
>> {
>> printf("Good!\n");
>> }
>> else
>> {
>> printf("Strange? Humm...\n");
>> }
>> return 0;
>> }
>> __________________________
>> Good shall be printed even with the following condition right?
>> __________________________
>> if ((p == NULL) && (! p) && (p == nullptr))
>> {
>> printf("Good!\n");
>> }
>> __________________________
>> Any better Ben?
>
> To be more precise, printf shall be called if p is 0, NULL or
> nullptr... They are all the same, in a sense, right?
In a sense, yes. If you want to know the senses in which they are not
all the same, ask some more (or read the C23 draft PDF).
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2024-07-10 11:09 -0400 |
| Message-ID | <v6m87m$1v1rh$1@dont-email.me> |
| In reply to | #386959 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
...
> To be more precise, printf shall be called if p is 0, NULL or
> nullptr... They are all the same, in a sense, right?
0 and nullptr are null pointer constants. NULL is required to expand
into a null pointer constant, but it's not required to expand into
either 0 or nullptr; it could expand into '\0' or 0ULL or ('a' - 'a'),
among an infinite variety of other possibilities. 0 and (void*)0 are the
two most likely and common choices.
Whenever they occur in a pointer context, null pointer constants get
implicitly converted to the corresponding pointer type, and the result
of that conversion is a null pointer of that type. All null pointers are
required to compare equal. In that sense, 0, NULL and nullptr are all
equivalent.
However, 0 can be used wherever an integer value is required. while
nullptr cannot, which is one of the key reasons for the existence of
nullptr. NULL can expand into an integer constant expression with a
value of 0, but it can also expand into such an expression, converted to
void*. If an implementation chooses the first option, NULL can be used
wherever an integer is allowed. If it chooses the second option, NULL
can only be used where a pointer is allowed.
[toc] | [prev] | [next] | [standalone]
| From | dave_thompson_2@comcast.net |
|---|---|
| Date | 2024-08-25 16:56 -0400 |
| Message-ID | <cj6ncj93220a0hmgj64itsrlmngfmur44h@4ax.com> |
| In reply to | #387001 |
On Wed, 10 Jul 2024 11:09:41 -0400, James Kuyper <jameskuyper@alumni.caltech.edu> wrote: > NULL is required to expand > into a null pointer constant ... 0 and (void*)0 are the > two most likely and common choices. > ((void*)0) Otherwise NULL["foo"] gives quite the wrong result
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2024-08-25 20:48 -0400 |
| Message-ID | <vagjcl$25csn$1@dont-email.me> |
| In reply to | #387775 |
On 8/25/24 16:56, dave_thompson_2@comcast.net wrote: > On Wed, 10 Jul 2024 11:09:41 -0400, James Kuyper > <jameskuyper@alumni.caltech.edu> wrote: > >> NULL is required to expand >> into a null pointer constant ... 0 and (void*)0 are the >> two most likely and common choices. >> > ((void*)0) > > Otherwise NULL["foo"] gives quite the wrong result Correct. Sorry.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-08-25 18:18 -0700 |
| Message-ID | <87wmk4dqu8.fsf@nosuchdomain.example.com> |
| In reply to | #387782 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 8/25/24 16:56, dave_thompson_2@comcast.net wrote:
>> On Wed, 10 Jul 2024 11:09:41 -0400, James Kuyper
>> <jameskuyper@alumni.caltech.edu> wrote:
>>
>>> NULL is required to expand
>>> into a null pointer constant ... 0 and (void*)0 are the
>>> two most likely and common choices.
>>>
>> ((void*)0)
>>
>> Otherwise NULL["foo"] gives quite the wrong result
>
> Correct. Sorry.
A mostly meaningless price of trivia: In C17 and earlier, an excessively
literal reading of the standard implies that ((void*)0) is not a null
pointer constant. It says that a null pointer constant is "An integer
constant expression with the value 0, or such an expression cast to type
void *". It does not say that a parenthesized null pointer constant is
a null pointer constant. (And (void*)0 is a null pointer constant but
not a valid definition for NULL.)
C23 fixes this by updating the wording for parenthesized expressions.
C17: "A *parenthesized expression* is a primary expression. Its type and
value are identical to those of the unparenthesized expression. It is an
lvalue, a function designator, or a void expression if the
unparenthesized expression is, respectively, an lvalue, a function
designator, or a void expression."
C23: "A *parenthesized expression* is a primary expression. Its type,
value, and semantics are identical to those of the unparenthesized
expression."
This was surely the intent all along.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2024-08-25 23:45 -0400 |
| Message-ID | <vagtpa$2ahdn$1@dont-email.me> |
| In reply to | #387783 |
On 8/25/24 21:18, Keith Thompson wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> On 8/25/24 16:56, dave_thompson_2@comcast.net wrote: >>> On Wed, 10 Jul 2024 11:09:41 -0400, James Kuyper >>> <jameskuyper@alumni.caltech.edu> wrote: >>> >>>> NULL is required to expand >>>> into a null pointer constant ... 0 and (void*)0 are the >>>> two most likely and common choices. >>>> >>> ((void*)0) >>> Otherwise NULL["foo"] gives quite the wrong result >> >> Correct. Sorry. > > A mostly meaningless price of trivia: In C17 and earlier, an excessively > literal reading of the standard implies that ((void*)0) is not a null > pointer constant. It says that a null pointer constant is "An integer > constant expression with the value 0, or such an expression cast to type > void *". It does not say that a parenthesized null pointer constant is > a null pointer constant. (And (void*)0 is a null pointer constant but > not a valid definition for NULL.) > > C23 fixes this by updating the wording for parenthesized expressions. > > C17: "A *parenthesized expression* is a primary expression. Its type and > value are identical to those of the unparenthesized expression. It is an > lvalue, a function designator, or a void expression if the > unparenthesized expression is, respectively, an lvalue, a function > designator, or a void expression." > > C23: "A *parenthesized expression* is a primary expression. Its type, > value, and semantics are identical to those of the unparenthesized > expression." I remembered that you had raised this issue before, and I think my memory of that issue is what led me to leave out the outer parentheses. I'm glad to know that they cleared it up.
[toc] | [prev] | [standalone]
Page 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]
Back to top | Article view | comp.lang.c
csiph-web