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 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-07-06 23:03 +0000 |
| Message-ID | <e3kiO.19399$7Ej.12485@fx46.iad> |
| In reply to | #386818 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >On 7/6/2024 7:04 AM, Scott Lurndal wrote: >> 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. >> >> 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. > >Where: > >void* x = 0; > >Should be x = 0xc0eeeeee, right? Sort of. In the context of the processor only the low-order 24-bits (6 BCD digits) indicated the null pointer. '0xc' was a positive sign and the following digit selected one of eight base-limit registers.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2024-07-06 21:44 -0400 |
| Message-ID | <v6crt3$1gpa$2@dont-email.me> |
| In reply to | #386818 |
On 7/6/24 4:23 PM, Chris M. Thomasson wrote: > On 7/6/2024 7:04 AM, Scott Lurndal wrote: ... >> 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. > > Where: > > void* x = 0; > > Should be x = 0xc0eeeeee, right? No, 0 is a null pointer constant. The C standard requires that when a null pointer constant is converted to a pointer value, it must be converted to a null pointer of that type. The result will be that the representation of 'x' after such an assignment would be 0xc0eeeeee. Whether or not an integer value of 0xc0eeeeee can be converted to a pointer type, and what that pointer's value would be after the conversion is up to the implementation. Note that even after x acquires that representation, it's still required to compare equal to 0. For the purposes of the comparison, the null pointer constant gets converted to a null pointer of the appropriate type. All null pointers, regardless of representation (the C standard allows there to be multiple ways of representing null pointers) must compare equal.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-07-06 19:29 -0700 |
| Message-ID | <87frsmsznj.fsf@nosuchdomain.example.com> |
| In reply to | #386843 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 7/6/24 4:23 PM, Chris M. Thomasson wrote:
>> On 7/6/2024 7:04 AM, Scott Lurndal wrote:
> ...
>>> 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.
>>
>> Where:
>>
>> void* x = 0;
>>
>> Should be x = 0xc0eeeeee, right?
>
> No, 0 is a null pointer constant. The C standard requires that when a
> null pointer constant is converted to a pointer value, it must be
> converted to a null pointer of that type. The result will be that the
> representation of 'x' after such an assignment would be 0xc0eeeeee.
>
> Whether or not an integer value of 0xc0eeeeee can be converted to a
> pointer type, and what that pointer's value would be after the
> conversion is up to the implementation.
>
> Note that even after x acquires that representation, it's still required
> to compare equal to 0. For the purposes of the comparison, the null
> pointer constant gets converted to a null pointer of the appropriate
> type. All null pointers, regardless of representation (the C standard
> allows there to be multiple ways of representing null pointers) must
> compare equal.
Furthermore, `void* x = 0xc0eeeeee;` is a constraint violation. There
is no implicit conversion from integers to pointers other than the
special case of a null pointer constant, which 0xc0eeeeee is not.
--
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 | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-07-07 12:53 -0700 |
| Message-ID | <v6erne$f608$3@dont-email.me> |
| In reply to | #386844 |
On 7/6/2024 7:29 PM, Keith Thompson wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> On 7/6/24 4:23 PM, Chris M. Thomasson wrote: >>> On 7/6/2024 7:04 AM, Scott Lurndal wrote: >> ... >>>> 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. >>> >>> Where: >>> >>> void* x = 0; >>> >>> Should be x = 0xc0eeeeee, right? >> >> No, 0 is a null pointer constant. The C standard requires that when a >> null pointer constant is converted to a pointer value, it must be >> converted to a null pointer of that type. The result will be that the >> representation of 'x' after such an assignment would be 0xc0eeeeee. >> >> Whether or not an integer value of 0xc0eeeeee can be converted to a >> pointer type, and what that pointer's value would be after the >> conversion is up to the implementation. >> >> Note that even after x acquires that representation, it's still required >> to compare equal to 0. For the purposes of the comparison, the null >> pointer constant gets converted to a null pointer of the appropriate >> type. All null pointers, regardless of representation (the C standard >> allows there to be multiple ways of representing null pointers) must >> compare equal. > > Furthermore, `void* x = 0xc0eeeeee;` is a constraint violation. There > is no implicit conversion from integers to pointers other than the > special case of a null pointer constant, which 0xc0eeeeee is not. > void* x = (void*)(0xc0eeeeee); // aka NULL void* y = 0; // NULL, right? x == y is true... Still shitty?
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-07-07 08:03 +0000 |
| Message-ID | <v6di3s$8f51$6@dont-email.me> |
| In reply to | #386818 |
On Sat, 6 Jul 2024 13:23:30 -0700, Chris M. Thomasson wrote: > void* x = 0; > > Should be x = 0xc0eeeeee, right? Only in the sense of doing an unsafe conversion, like via a union type, for example.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-07-06 23:14 +0100 |
| Message-ID | <877cdyuq0f.fsf@bsb.me.uk> |
| In reply to | #386803 |
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
void *ptr = 0;
if (ptr == 0) ...
being true and also
memcmp(&ptr,
&(union { unsigned int u; void *p; }){ .u=0xc0eeeeee }.p,
sizeof ptr) == 0
being true.
> [*] now obsolete.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-07-06 23:13 +0000 |
| Message-ID | <2ckiO.19403$7Ej.4487@fx46.iad> |
| 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). > >> 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. Horses for courses.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-07-06 20:10 -0700 |
| Message-ID | <86ed85c2x1.fsf@linuxsc.com> |
| In reply to | #386835 |
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, [...] You consider something that is not ambiguous to be ambiguous? You must mean something different by the word ambiguous than I do.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2024-07-07 08:46 +0000 |
| Message-ID | <20240707011357.399@kylheku.com> |
| In reply to | #386835 |
On 2024-07-06, Scott Lurndal <scott@slp53.sl.home> wrote: > Ben Bacarisse <ben@bsb.me.uk> writes: >>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. Horses for courses. The thing is that "null" is a word that means "zero". So it's a bit like saying #define tri 3 is less ambiguous compared to just using 3. I get it that 0 is not exclusively a pointer constant, and syntax alone doesn't indicate which; indeed without type information, we don't know whether p == 0 is a pointer comparison, floating-point comparison or integer comparison. Whereas with some other kinds of expressions, we know more: e.g. p->memb, if correct, tells us that p is a pointer to a struct or union. If we have to use someting other than 0 to help us understand p == 0, maybe the circumstances of the p are not clear enough? What about "if (p)" and "if (!p)". If 0 is ambiguous, these should always be written "if (p != nullptr)" and "if (p == nullptr)". Otherwise p could be a number. (Indeed, there are coding conventions like that: always use NULL, and do not test pointers as if they were Booleans.) -- 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-07 19:59 +0100 |
| Message-ID | <87plrpt4du.fsf@bsb.me.uk> |
| In reply to | #386835 |
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. Ambiguous and explicit are not opposites, so many you did not mean to say that 0 is ambiguous. Its use does require the reader to know the role played by zero integer constant expressions in C. But then NULL might be defined to be 0. It /looks/ more like a pointer but there's lots of code that erroneously assumes that it is, presumably because of that deceptive look. (nullptr is another matter.) Do you always cast NULL to a pointer in those (admittedly rare) cases when one needs to? I think it's easier to remember to do that with 0. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-07-07 19:40 +0000 |
| Message-ID | <9bCiO.7108$sXW9.3805@fx41.iad> |
| In reply to | #386865 |
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. 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. >Do you always cast NULL to a pointer in those (admittedly rare) cases >when one needs to? I may have back in the days when I was using Version 6 C and AT&T C where $ grep NULL /work/reference/usl/uw2.01/usr/src/common/head/stddef.h #ifndef NULL #define NULL 0 I use gcc today and it defines NULL for C as #define NULL ((void *)0)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-07-07 15:17 -0700 |
| Message-ID | <877cdwu9s1.fsf@nosuchdomain.example.com> |
| In reply to | #386866 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Ben Bacarisse <ben@bsb.me.uk> writes:
[...]
>>Do you always cast NULL to a pointer in those (admittedly rare) cases
>>when one needs to?
>
> I may have back in the days when I was using Version 6 C and
> AT&T C where
>
> $ grep NULL /work/reference/usl/uw2.01/usr/src/common/head/stddef.h
> #ifndef NULL
> #define NULL 0
>
>
> I use gcc today and it defines NULL for C as
>
> #define NULL ((void *)0)
Consider a variadic function that uses a null pointer to terminate the
argument list. Then I always use NULL cast to the appropriate pointer
type.
For example, execl() requires a final argument that should be
`(char*)NULL`.
On the other hand, execl() is specified by POSIX, which also happens to
require NULL to be of type void* -- and you can pretty much get away
with using a void* null pointer where a char* null pointer is expected.
But casting NULL to the appropriate type (checked by reading the man
page) requires less thought.
I just about always use NULL, not 0, when I want a null pointer
constant. Similarly, I use '\0', not 0, when I want a null character,
0.0 when I want a floating-point zero, and false when I want a Boolean
zero. I just like being explicit.
In C23, I'll use nullptr rather than NULL *if* I don't care about
portability to pre-C23 compilers. (I use nullptr in C++.)
--
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 | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-07-08 20:11 +0200 |
| Message-ID | <v6ha41$vkip$2@dont-email.me> |
| In reply to | #386870 |
On 08.07.2024 00:17, Keith Thompson wrote: > > I just about always use NULL, not 0, when I want a null pointer > constant. Similarly, I use '\0', not 0, when I want a null character, > 0.0 when I want a floating-point zero, and false when I want a Boolean > zero. I just like being explicit. Same here. Absolutely. Janis
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-07-08 13:32 -0700 |
| Message-ID | <87a5iry68p.fsf@nosuchdomain.example.com> |
| In reply to | #386870 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>>In C23, I'll use nullptr rather than NULL *if* I don't care about
>>portability to pre-C23 compilers. (I use nullptr in C++.)
>
> I haven't made the transition to nullptr in C++ yet, too many years
> of using NULL and code bases that need to compile with older
> standards (pre C++11, until very recently) - granted one might
>
> #define nullptr (void *)NULL
I've thought about doing something like that, but I haven't had the
opportunity so far, and I'm not sure I would.
I might write something like:
#if __STDC_VERSION__ < 202311L
#define nullptr ((void*)NULL)
#endif
But if I had to compile with both pre-C23 and newer compilers, I'd be
more likely to just use NULL (with a cast where necessary). I'd
consider the `#define nullptr` trick if pre-C23 compilers were rare.
--
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 | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-07-08 22:28 +0300 |
| Message-ID | <20240708222804.00001654@yahoo.com> |
| In reply to | #386870 |
On Sun, 07 Jul 2024 15:17:34 -0700 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > > I just about always use NULL, not 0, when I want a null pointer > constant. Similarly, I use '\0', not 0, when I want a null character, > 0.0 when I want a floating-point zero, and false when I want a Boolean > zero. I just like being explicit. > Pointer: I very rarely use NULL. Character: I never use '\0'. Floating point: I never use 0.0. Boolean: I use false much more often than 0.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-07-08 15:23 -0700 |
| Message-ID | <v6hotk$11nib$2@dont-email.me> |
| In reply to | #386874 |
On 7/8/2024 12:28 PM, Michael S wrote:
> On Sun, 07 Jul 2024 15:17:34 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>
>>
>> I just about always use NULL, not 0, when I want a null pointer
>> constant. Similarly, I use '\0', not 0, when I want a null character,
>> 0.0 when I want a floating-point zero, and false when I want a Boolean
>> zero. I just like being explicit.
>>
>
> Pointer: I very rarely use NULL.
> Character: I never use '\0'.
Not even something like:
#define CLINE 128
char x[CLINE] = { '\0' };
?
;^)
> Floating point: I never use 0.0.
> Boolean: I use false much more often than 0.
>
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-07-09 10:48 +0300 |
| Message-ID | <20240709104848.00005732@yahoo.com> |
| In reply to | #386893 |
On Mon, 8 Jul 2024 15:23:47 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
> On 7/8/2024 12:28 PM, Michael S wrote:
> > On Sun, 07 Jul 2024 15:17:34 -0700
> > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> >
> >>
> >> I just about always use NULL, not 0, when I want a null pointer
> >> constant. Similarly, I use '\0', not 0, when I want a null
> >> character, 0.0 when I want a floating-point zero, and false when I
> >> want a Boolean zero. I just like being explicit.
> >>
> >
> > Pointer: I very rarely use NULL.
> > Character: I never use '\0'.
>
> Not even something like:
>
> #define CLINE 128
>
> char x[CLINE] = { '\0' };
>
> ?
>
> ;^)
I see nothing special about your case. {0} is the most appropriate.
And, BTW, I never use #define for integer constants.
>
>
> > Floating point: I never use 0.0.
> > Boolean: I use false much more often than 0.
> >
>
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-07-09 04:32 -0700 |
| Message-ID | <86cynmajh9.fsf@linuxsc.com> |
| In reply to | #386922 |
Michael S <already5chosen@yahoo.com> writes:
> On Mon, 8 Jul 2024 15:23:47 -0700
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
>
>> On 7/8/2024 12:28 PM, Michael S wrote:
>>
>>> On Sun, 07 Jul 2024 15:17:34 -0700
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>
>>>> I just about always use NULL, not 0, when I want a null pointer
>>>> constant. Similarly, I use '\0', not 0, when I want a null
>>>> character, 0.0 when I want a floating-point zero, and false when I
>>>> want a Boolean zero. I just like being explicit.
>>>
>>> Pointer: I very rarely use NULL.
>>> Character: I never use '\0'.
>>
>> Not even something like:
>>
>> #define CLINE 128
>>
>> char x[CLINE] = { '\0' };
>>
>> ?
>>
>> ;^)
>
> I see nothing special about your case. {0} is the most appropriate.
Any use of '\0' almost always strikes me as an affectation. It's
like people want to somehow pretend that it's not the same as
just 0.
> And, BTW, I never use #define for integer constants.
What do you do if you need to define a compile-time constant
whose value is outside the range of signed int? With the
understanding that the context is C as it is now, and not
C++ or some imagined other language.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2024-07-09 09:10 -0300 |
| Message-ID | <v6j9ce$1bvoj$1@dont-email.me> |
| In reply to | #386932 |
On 09/07/2024 08:32, Tim Rentsch wrote: > Any use of '\0' almost always strikes me as an affectation. It's > like people want to somehow pretend that it's not the same as > just 0. I like to pretend '\0' is not int 2 > 1 is not int etc I know it is int, but I think this needs a redesign in C. Meanwhile compilers can just have the type "int" and sub-type. I don't like to think '\0' is null pointer. int * p = '\0';
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-07-09 07:52 -0700 |
| Message-ID | <864j8yaa8u.fsf@linuxsc.com> |
| In reply to | #386933 |
Thiago Adams <thiago.adams@gmail.com> writes: > On 09/07/2024 08:32, Tim Rentsch wrote: > >> Any use of '\0' almost always strikes me as an affectation. It's >> like people want to somehow pretend that it's not the same as >> just 0. > > I like to pretend > > '\0' is not int > 2 > 1 is not int > etc > > I know it is int, but I think this needs a redesign in C. I strongly encourage you not to do that. Based on past experience most of your ideas for improvements make things worse rather than better.
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web