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 | 20 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 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-07-08 17:23 +0100 |
| Message-ID | <8734ojua2s.fsf@bsb.me.uk> |
| In reply to | #386876 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: > On 08.07.2024 12:18, Ben Bacarisse wrote: >> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >>> >>> What's superfluous to one is useful for others (e.g. for grep'ing >>> occurrences of a null-pointer value in source codes); >> >> This is been suggested twice now but I'm struggling to see why that is >> useful. I can see management wanting one to find all uses of a null >> pointer constant to check that they have all been replaced by the >> "safer" nullptr, but what's the value in searching for nullptr? > > Bug-tracking. Can you say more? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2024-07-08 11:03 -0400 |
| Message-ID | <v6gv4f$tp07$1@dont-email.me> |
| In reply to | #386866 |
On 7/7/24 19:42, Ben Bacarisse wrote: > scott@slp53.sl.home (Scott Lurndal) writes: ... >> I.e. it can either be a null pointer or the value zero >> depending on context, which makes it ambiguous to the casual >> reader. Particularly when reading code that someone >> else has written. NULL makes the programmers intent crystal >> clear. > > That's a rather niche readership -- one that might consider > > char *p = 0; > > unclear. Do you want such people reading your C code with a view to > working on it? The problem is not "char p=0;". If you're sure what type p has, there's no problem. The problem comes with code like "p=0", where "p=NULL" would serve to remind you that p should be a pointer, while "p=nullptr" guarantees a diagnostic if p is not a pointer. I have fixed bugs which would have been caught a lot earlier if nullptr had existed, and had been the only permitted kind of null pointer constant.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2024-07-09 02:45 +0000 |
| Message-ID | <20240708193402.610@kylheku.com> |
| In reply to | #386879 |
On 2024-07-08, James Kuyper <jameskuyper@alumni.caltech.edu> wrote: > On 7/7/24 19:42, Ben Bacarisse wrote: >> scott@slp53.sl.home (Scott Lurndal) writes: > ... >>> I.e. it can either be a null pointer or the value zero >>> depending on context, which makes it ambiguous to the casual >>> reader. Particularly when reading code that someone >>> else has written. NULL makes the programmers intent crystal >>> clear. >> >> That's a rather niche readership -- one that might consider >> >> char *p = 0; >> >> unclear. Do you want such people reading your C code with a view to >> working on it? > > > The problem is not "char p=0;". If you're sure what type p has, there's > no problem. The problem comes with code like "p=0", where "p=NULL" would > serve to remind you that p should be a pointer, while "p=nullptr" > guarantees a diagnostic if p is not a pointer. The programming world has moved away from tying syntax to concrete implementation though. For every time you worry in p = 0, p is floating, integer or pointer, a thousand coders somewhere are doing writing obj.foo(), where the type of obj can be one of half a dozen different things at run-time. p = 0 is nicely generic: "make p null, whatever it is". A pointer "responds" to this "method" by becoming null. And anyway, if the expression is p + 3 instead, what tells you then whether it's an integer, float or pointer. Should we have a ptrplus keyword for displacing pointers? Ancient C, or pre-C, had separate operators for floating-point, prefixed with a hash: #+, #-, #*, ... > I have fixed bugs which > would have been caught a lot earlier if nullptr had existed, and had > been the only permitted kind of null pointer constant. All the ones I remember were about 0 being used as a variadic pointer argument, without a cast. I can't think of anywhere else it would be a problem. nullptr being the only null pointer constant would prevent that where the type is void * or char *, (or where pointers of all types all have the same representation). -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-07-08 11:08 +0200 |
| Message-ID | <v6gab6$qdd2$1@dont-email.me> |
| In reply to | #386866 |
On 08.07.2024 09:19, Kaz Kylheku wrote: > On 2024-07-07, Ben Bacarisse <ben@bsb.me.uk> wrote: >> I find myself completely out of step with many posters here about >> "explicit code" should look like. I think >> >> char *p = 0; >> >> is explicit enough and, in fact, I consider it a plus point if someone >> reading it goes "hey, what's going on here?" and ends up learning that 0 >> is null pointer constant in C. > > And if that person is on the C or C++ langauge committee, that bit of > learning could just prevent a superfluous non-invention like nullptr. What's superfluous to one is useful for others (e.g. for grep'ing occurrences of a null-pointer value in source codes); if it's not defined in a standard it gets explicitly defined individually, and then likely in different (non-uniform, non-standard) ways. To me it's more likely that because of that it had been deliberately added to support such desires, and less likely that the C-standards folks need to learn "C" and wouldn't know what 0 as a pointer value would mean or that it has a clear semantic in such pointer contexts. Janis
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-07-08 11:18 +0100 |
| Message-ID | <878qyctcdt.fsf@bsb.me.uk> |
| In reply to | #386880 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: > On 08.07.2024 09:19, Kaz Kylheku wrote: >> On 2024-07-07, Ben Bacarisse <ben@bsb.me.uk> wrote: >>> I find myself completely out of step with many posters here about >>> "explicit code" should look like. I think >>> >>> char *p = 0; >>> >>> is explicit enough and, in fact, I consider it a plus point if someone >>> reading it goes "hey, what's going on here?" and ends up learning that 0 >>> is null pointer constant in C. >> >> And if that person is on the C or C++ langauge committee, that bit of >> learning could just prevent a superfluous non-invention like nullptr. > > What's superfluous to one is useful for others (e.g. for grep'ing > occurrences of a null-pointer value in source codes); This is been suggested twice now but I'm struggling to see why that is useful. I can see management wanting one to find all uses of a null pointer constant to check that they have all been replaced by the "safer" nullptr, but what's the value in searching for nullptr? > if it's not > defined in a standard it gets explicitly defined individually, and > then likely in different (non-uniform, non-standard) ways. > > To me it's more likely that because of that it had been deliberately > added to support such desires, That would be a sound suggestion if "such desires" could be explained. Until then, I suggest it is simply harmonisation with C++. C now has true and false, [[...]] attributes, typeof, __has_include and no doubt quite a few more I've forgotten. nullptr is, until some other argument can be made, just another one of those. > and less likely that the C-standards > folks need to learn "C" and wouldn't know what 0 as a pointer value > would mean or that it has a clear semantic in such pointer contexts. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2024-07-09 02:32 +0000 |
| Message-ID | <20240708192708.531@kylheku.com> |
| In reply to | #386888 |
On 2024-07-08, Ben Bacarisse <ben@bsb.me.uk> wrote: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: > >> On 08.07.2024 09:19, Kaz Kylheku wrote: >>> On 2024-07-07, Ben Bacarisse <ben@bsb.me.uk> wrote: >>>> I find myself completely out of step with many posters here about >>>> "explicit code" should look like. I think >>>> >>>> char *p = 0; >>>> >>>> is explicit enough and, in fact, I consider it a plus point if someone >>>> reading it goes "hey, what's going on here?" and ends up learning that 0 >>>> is null pointer constant in C. >>> >>> And if that person is on the C or C++ langauge committee, that bit of >>> learning could just prevent a superfluous non-invention like nullptr. >> >> What's superfluous to one is useful for others (e.g. for grep'ing >> occurrences of a null-pointer value in source codes); > > This is been suggested twice now but I'm struggling to see why that is > useful. I can see management wanting one to find all uses of a null > pointer constant to check that they have all been replaced by the > "safer" nullptr, but what's the value in searching for nullptr? We could patch GCC to have a -Wnull-ptr-zero, which will give you a diagnostic for every occurrence of a zero valued integer expression that becomes a null pointer constant rather than an integer or floating-point value (and that isn't cast to pointer type). (If this were so hugely useful, someone woulda done it by now?) (Of course, it would go off on occurrences of NULL where NULL is defined as just zero; the diagnostic could be clever enough not to go off on expressions that are the expansion descendants of NULL, or optionally so.) (The option would actually be useful to someone wanting to convert 0 to NULL or nullptr.) (Just like -Wold-style-cast in GNU C++ helps coders who only want to use static_cast and friends.) -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-07-08 22:02 -0700 |
| Message-ID | <v6ig8t$18sp0$1@dont-email.me> |
| In reply to | #386903 |
On 7/8/2024 7:32 PM, Kaz Kylheku wrote: > On 2024-07-08, Ben Bacarisse <ben@bsb.me.uk> wrote: >> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> >>> On 08.07.2024 09:19, Kaz Kylheku wrote: >>>> On 2024-07-07, Ben Bacarisse <ben@bsb.me.uk> wrote: >>>>> I find myself completely out of step with many posters here about >>>>> "explicit code" should look like. I think >>>>> >>>>> char *p = 0; >>>>> >>>>> is explicit enough and, in fact, I consider it a plus point if someone >>>>> reading it goes "hey, what's going on here?" and ends up learning that 0 >>>>> is null pointer constant in C. >>>> >>>> And if that person is on the C or C++ langauge committee, that bit of >>>> learning could just prevent a superfluous non-invention like nullptr. >>> >>> What's superfluous to one is useful for others (e.g. for grep'ing >>> occurrences of a null-pointer value in source codes); >> >> This is been suggested twice now but I'm struggling to see why that is >> useful. I can see management wanting one to find all uses of a null >> pointer constant to check that they have all been replaced by the >> "safer" nullptr, but what's the value in searching for nullptr? > > We could patch GCC to have a -Wnull-ptr-zero, which will give you a > diagnostic for every occurrence of a zero valued integer expression that > becomes a null pointer constant rather than an integer or floating-point > value (and that isn't cast to pointer type). I would not mind that! :^) [...]
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-07-09 10:21 +0100 |
| Message-ID | <87bk36syx7.fsf@bsb.me.uk> |
| In reply to | #386903 |
Kaz Kylheku <643-408-1753@kylheku.com> writes: > On 2024-07-08, Ben Bacarisse <ben@bsb.me.uk> wrote: >> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> >>> On 08.07.2024 09:19, Kaz Kylheku wrote: >>>> On 2024-07-07, Ben Bacarisse <ben@bsb.me.uk> wrote: >>>>> I find myself completely out of step with many posters here about >>>>> "explicit code" should look like. I think >>>>> >>>>> char *p = 0; >>>>> >>>>> is explicit enough and, in fact, I consider it a plus point if someone >>>>> reading it goes "hey, what's going on here?" and ends up learning that 0 >>>>> is null pointer constant in C. >>>> >>>> And if that person is on the C or C++ langauge committee, that bit of >>>> learning could just prevent a superfluous non-invention like nullptr. >>> >>> What's superfluous to one is useful for others (e.g. for grep'ing >>> occurrences of a null-pointer value in source codes); >> >> This is been suggested twice now but I'm struggling to see why that is >> useful. I can see management wanting one to find all uses of a null >> pointer constant to check that they have all been replaced by the >> "safer" nullptr, but what's the value in searching for nullptr? > > We could patch GCC to have a -Wnull-ptr-zero, which will give you a > diagnostic for every occurrence of a zero valued integer expression that > becomes a null pointer constant rather than an integer or floating-point > value (and that isn't cast to pointer type). Sure. I once tried to persuade the compiler team where I worked to write a "tool box" for diagnostics that would have a meta-language in which users could describe the conditions that wanted to be diagnosed. The idea was half-baked so it never went anywhere. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-07-10 17:32 -0700 |
| Message-ID | <v6n96p$23rhi$5@dont-email.me> |
| In reply to | #386928 |
On 7/9/2024 2:21 AM, Ben Bacarisse wrote: > Kaz Kylheku <643-408-1753@kylheku.com> writes: > >> On 2024-07-08, Ben Bacarisse <ben@bsb.me.uk> wrote: [...] >> We could patch GCC to have a -Wnull-ptr-zero, which will give you a >> diagnostic for every occurrence of a zero valued integer expression that >> becomes a null pointer constant rather than an integer or floating-point >> value (and that isn't cast to pointer type). > > Sure. > > I once tried to persuade the compiler team where I worked to write a > "tool box" for diagnostics that would have a meta-language in which > users could describe the conditions that wanted to be diagnosed. The > idea was half-baked so it never went anywhere. > No funding?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-07-11 02:12 +0100 |
| Message-ID | <8734ogn33a.fsf@bsb.me.uk> |
| In reply to | #387030 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: > On 7/9/2024 2:21 AM, Ben Bacarisse wrote: >> Kaz Kylheku <643-408-1753@kylheku.com> writes: >> >>> On 2024-07-08, Ben Bacarisse <ben@bsb.me.uk> wrote: > [...] >>> We could patch GCC to have a -Wnull-ptr-zero, which will give you a >>> diagnostic for every occurrence of a zero valued integer expression that >>> becomes a null pointer constant rather than an integer or floating-point >>> value (and that isn't cast to pointer type). >> Sure. >> I once tried to persuade the compiler team where I worked to write a >> "tool box" for diagnostics that would have a meta-language in which >> users could describe the conditions that wanted to be diagnosed. The >> idea was half-baked so it never went anywhere. > > No funding? No. As I said the idea was half-baked. I could not pin it down and nether could anyone else. Without a clear specification, it could not go forward. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-07-10 18:41 -0700 |
| Message-ID | <v6nd8a$28u97$1@dont-email.me> |
| In reply to | #387031 |
On 7/10/2024 6:12 PM, Ben Bacarisse wrote: > "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: > >> On 7/9/2024 2:21 AM, Ben Bacarisse wrote: >>> Kaz Kylheku <643-408-1753@kylheku.com> writes: >>> >>>> On 2024-07-08, Ben Bacarisse <ben@bsb.me.uk> wrote: >> [...] >>>> We could patch GCC to have a -Wnull-ptr-zero, which will give you a >>>> diagnostic for every occurrence of a zero valued integer expression that >>>> becomes a null pointer constant rather than an integer or floating-point >>>> value (and that isn't cast to pointer type). >>> Sure. >>> I once tried to persuade the compiler team where I worked to write a >>> "tool box" for diagnostics that would have a meta-language in which >>> users could describe the conditions that wanted to be diagnosed. The >>> idea was half-baked so it never went anywhere. >> >> No funding? > > No. As I said the idea was half-baked. I could not pin it down and > nether could anyone else. Without a clear specification, it could not > go forward. > shit happens! Sometimes, those half-baked ideas can turn out to be interesting.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-07-11 02:38 +0000 |
| Message-ID | <v6ngj6$29e0c$1@dont-email.me> |
| In reply to | #386880 |
On Mon, 8 Jul 2024 11:08:53 +0200, Janis Papanagnou wrote: > To me it's more likely that because of that it had been deliberately > added to support such desires, and less likely that the C-standards > folks need to learn "C" and wouldn't know what 0 as a pointer value > would mean or that it has a clear semantic in such pointer contexts. Back in the 1980s: “I like C because it’s not Pascal.” And now: yet another Pascal feature added to C. Of course, we called it “nil” in Pascal. Which is a name that comes from Lisp.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-07-12 14:11 +0200 |
| Message-ID | <v6r6hg$3122q$2@dont-email.me> |
| In reply to | #387036 |
On 11.07.2024 04:38, Lawrence D'Oliveiro wrote: > On Mon, 8 Jul 2024 11:08:53 +0200, Janis Papanagnou wrote: > >> To me it's more likely that because of that it had been deliberately >> added to support such desires, and less likely that the C-standards >> folks need to learn "C" and wouldn't know what 0 as a pointer value >> would mean or that it has a clear semantic in such pointer contexts. > > Back in the 1980s: “I like C because it’s not Pascal.” > > And now: yet another Pascal feature added to C. > > Of course, we called it “nil” in Pascal. Which is a name that comes from > Lisp. You're replying to (part of) my post, so I wonder what do you want to say (or allege) here? Janis
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-07-08 07:18 -0400 |
| Message-ID | <361be2220e25f56edb8511175ae5eadcf9115703@i2pn2.org> |
| In reply to | #386866 |
On 7/8/24 3:19 AM, Kaz Kylheku wrote: > On 2024-07-07, Ben Bacarisse <ben@bsb.me.uk> wrote: >> I find myself completely out of step with many posters here about >> "explicit code" should look like. I think >> >> char *p = 0; >> >> is explicit enough and, in fact, I consider it a plus point if someone >> reading it goes "hey, what's going on here?" and ends up learning that 0 >> is null pointer constant in C. > > And if that person is on the C or C++ langauge committee, that bit of > learning could just prevent a superfluous non-invention like nullptr. > Remember, it was invented on the C++ side, where it has some very useful uses due to overloading. And then brought over to C to minimize the differences. Nothing made it manditory, so if you want to make your reader learn more about C, go ahead and use things that are somewhat obscure.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2024-07-08 07:19 +0000 |
| Message-ID | <20240708001722.280@kylheku.com> |
| In reply to | #386866 |
On 2024-07-07, Ben Bacarisse <ben@bsb.me.uk> wrote: > I find myself completely out of step with many posters here about > "explicit code" should look like. I think > > char *p = 0; > > is explicit enough and, in fact, I consider it a plus point if someone > reading it goes "hey, what's going on here?" and ends up learning that 0 > is null pointer constant in C. And if that person is on the C or C++ langauge committee, that bit of learning could just prevent a superfluous non-invention like nullptr. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-07-08 00:42 +0100 |
| Message-ID | <87jzhwu5v9.fsf@bsb.me.uk> |
| In reply to | #386866 |
scott@slp53.sl.home (Scott Lurndal) writes: > Ben Bacarisse <ben@bsb.me.uk> writes: >>scott@slp53.sl.home (Scott Lurndal) writes: >> >>> Ben Bacarisse <ben@bsb.me.uk> writes: >>>>scott@slp53.sl.home (Scott Lurndal) writes: >>>> >>>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >>>>>>On 06.07.2024 14:54, Kaz Kylheku wrote: >>>>>>> On 2024-07-06, Thiago Adams <thiago.adams@gmail.com> wrote: >>>>>>>> If you were creating C code today and could use a C23 compiler, would >>>>>>>> you use nullptr instead of NULL? >>>>>>> >>>>>>> In greenfield projects under my dictatorship, I use 0, as in: >>>>>>> >>>>>>> char *p = 0; >>>>>>> >>>>>>> I was still 20 something when I (easily) wrapped my head around the 0 >>>>>>> null pointer constant, and have not had any problems with it. >>>>>>> Once I learned the standard-defined truth about null pointer constants, >>>>>>> and their relationship to the NULL macro, I dropped NULL like a hot >>>>>>> potato, and didn't look back (except when working in code bases that use >>>>>>> NULL). >>>>>> >>>>>>We also used 0 as "universal" pointer value regularly without >>>>>>problems. >>>> >>>>I also like to use 0, but I'm not sure I could say exactly why. Maybe >>>>because of pre-C exposure (B and BCPL). >>>> >>>>> Whereas I spent 6 years programming on an architecture[*] where a >>>>> null pointer was represented in hardware by the value 0xc0eeeeee. I always >>>>> use the NULL macro in both C and C++ code. >>>> >>>>I'm sure you know (but maybe some other readers might not) that that >>>>does not stop one using 0 in C source code. Whatever a null pointer >>>>"really" is on some hardware, 0 must work in C, including in comparisons >>>>with == and !=. You can have >>> >>> Yes. However, I consider that ambiguous, I prefer to be explicit and >>> use NULL or nullptr. >> >>In what sense is using 0 ambiguous? I can't see it. > > the digit zero is context dependent, which makes it ambiguous. Ah. I thought we were talking about a pointer context so I thought you meant that using 0 in a pointer context was ambiguous. In char *p = 0; the 0 is not ambiguous (i.e. open to more than one meaning). It's open to being misunderstood by people who don't know C, but that true of the 'char', the '*' and the '=' (and possibly the 'p' and the ';' too). > I.e. it can either be a null pointer or the value zero > depending on context, which makes it ambiguous to the casual > reader. Particularly when reading code that someone > else has written. NULL makes the programmers intent crystal > clear. That's a rather niche readership -- one that might consider char *p = 0; unclear. Do you want such people reading your C code with a view to working on it? I find myself completely out of step with many posters here about "explicit code" should look like. I think char *p = 0; is explicit enough and, in fact, I consider it a plus point if someone reading it goes "hey, what's going on here?" and ends up learning that 0 is null pointer constant in C. They may, along the way, learn a few other things that they should also know before fiddling with the code. At the very least, they will have learnt that they don't know it all. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-07-06 20:36 -0700 |
| Message-ID | <865xthc1qu.fsf@linuxsc.com> |
| In reply to | #386823 |
Ben Bacarisse <ben@bsb.me.uk> writes: > scott@slp53.sl.home (Scott Lurndal) writes: > >> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> >>> On 06.07.2024 14:54, Kaz Kylheku wrote: >>> >>>> On 2024-07-06, Thiago Adams <thiago.adams@gmail.com> wrote: >>>> >>>>> If you were creating C code today and could use a C23 compiler, would >>>>> you use nullptr instead of NULL? >>>> >>>> In greenfield projects under my dictatorship, I use 0, as in: >>>> >>>> char *p = 0; >>>> >>>> I was still 20 something when I (easily) wrapped my head around the 0 >>>> null pointer constant, and have not had any problems with it. >>>> Once I learned the standard-defined truth about null pointer constants, >>>> and their relationship to the NULL macro, I dropped NULL like a hot >>>> potato, and didn't look back (except when working in code bases that use >>>> NULL). >>> >>> We also used 0 as "universal" pointer value regularly without >>> problems. > > I also like to use 0, but I'm not sure I could say exactly why. Maybe > because of pre-C exposure (B and BCPL). Me too. If I had to guess about why, I think I would say (1) being used to it from the original K&R, and (2) it's philosophically consistent with how if(), for(), while(), and logical expressions work. Speaking for myself that consistency is worth a lot, and using NULL sticks out like a sore thumb.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2024-07-06 22:11 +0000 |
| Message-ID | <20240706150642.898@kylheku.com> |
| In reply to | #386801 |
On 2024-07-06, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: > On 06.07.2024 14:54, Kaz Kylheku wrote: >> On 2024-07-06, Thiago Adams <thiago.adams@gmail.com> wrote: >>> If you were creating C code today and could use a C23 compiler, would >>> you use nullptr instead of NULL? >> >> In greenfield projects under my dictatorship, I use 0, as in: >> >> char *p = 0; >> >> I was still 20 something when I (easily) wrapped my head around the 0 >> null pointer constant, and have not had any problems with it. >> Once I learned the standard-defined truth about null pointer constants, >> and their relationship to the NULL macro, I dropped NULL like a hot >> potato, and didn't look back (except when working in code bases that use >> NULL). > > We also used 0 as "universal" pointer value regularly without problems. Instead of inventing a new keyword "nullptr", the C++ people should have made the 0p and 0P tokens have that meaning. In the preprocessing phases, 0p and 0P are already pp-number tokens, which are invalid tokens, requiring a diagnostic. > One practical advantage of adding a named entity (with a value of 0) > was to easily grep (find) appearances of this value in source code. 0[Pp] ticks off that box. So does NULL. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-07-06 14:51 +0100 |
| Message-ID | <v6bi4m$3qvgh$1@dont-email.me> |
| In reply to | #386800 |
On 06/07/2024 13:54, Kaz Kylheku wrote:
> On 2024-07-06, Thiago Adams <thiago.adams@gmail.com> wrote:
>> If you were creating C code today and could use a C23 compiler, would
>> you use nullptr instead of NULL?
>
> In greenfield projects under my dictatorship, I use 0, as in:
>
> char *p = 0;
>
> I was still 20 something when I (easily) wrapped my head around the 0
> null pointer constant, and have not had any problems with it.
> Once I learned the standard-defined truth about null pointer constants,
> and their relationship to the NULL macro, I dropped NULL like a hot
> potato, and didn't look back (except when working in code bases that use
> NULL).
>
Using actual zero for a pointer value is crass. This wouldn't work for
example:
char *p = 3;
Nor this:
int a = 0;
char *p = a;
Although this does:
char *p = 3/4;
And this:
enum {a=42, b=a};
char *p = a-b; // or a&1, but not a&2
It walks all over the language's type system, such as it is.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-07-07 04:55 +0000 |
| Message-ID | <v6d73i$6r8h$3@dont-email.me> |
| In reply to | #386802 |
On Sat, 6 Jul 2024 14:51:19 +0100, bart wrote:
> Using actual zero for a pointer value is crass. This wouldn't work for
> example:
>
> char *p = 3;
But of course this does:
char *p = 0;
From the C23 spec, I found this footnote in §6.6:
A named constant or compound literal constant of integer type and
value zero is a null pointer constant. A named constant or
compound literal constant with a pointer type and a value null is
a null pointer but not a null pointer constant; it may only be
used to initialize a pointer object if its type implicitly
converts to the target type.
That first sentence is so important, you’d think it would be in the main
text somewhere.
[toc] | [prev] | [next] | [standalone]
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web