If you were creating C code today and could use a C23 compiler, would
you use nullptr instead of NULL?
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).
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.
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.
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).
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
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.
[*] now obsolete.
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.
On 06.07.2024 16:04, Scott Lurndal wrote:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
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.
Yes, but a 0 pointer value has not the meaning of an int value 0.
I always
use the NULL macro in both C and C++ code.
[*] now obsolete.
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.
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.
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.
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?
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.
[*] now obsolete.
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.
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.
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?
On 06/07/2024 15:04, 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.
You can ignore that requirement and just use all-bits-zero (in memory,
not just in C source code). After all, the only thing you might want
hardware support for is trapping a dereference of a NULL value.
On 07/06/24 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.
But that achieved absolutely nothing over using plain `0` in the source
code.
The `NULL` you used was still defined as `0` (in C++ libs) and 0 or
`(void *) 0` (in C libs).
On 7/6/24 4:23 PM, Chris M. Thomasson wrote:
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:Whereas I spent 6 years programming on an architecture[*] where a
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. >>>
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?
Maybe when the representation of x is examined by reinterpreting it as
an array of character types (like unsigned char).
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
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?
Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
On 07/06/24 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.
But that achieved absolutely nothing over using plain `0` in the source
code.
The `NULL` you used was still defined as `0` (in C++ libs) and 0 or
`(void *) 0` (in C libs).
Which ambiguity is yet another reason to use the NULL or nullptr
tokens.
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, [...]
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).
Using actual zero for a pointer value is crass. This wouldn't work for example:
char *p = 3;
void* a = 0;
void* b = NULL;
a == b, right?
... and for C compilers to support a flag like gcc's "-Wzero-as-null
-pointer-constant" warning ...
void* x = 0;
Should be x = 0xc0eeeeee, right?
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.
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.
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.
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.
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.
Do you always cast NULL to a pointer in those (admittedly rare) cases
when one needs to?
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.
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.
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.
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?
[...]
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.
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.
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++.)
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?
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.
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?
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.
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.
On 08.07.2024 18:23, Ben Bacarisse wrote:
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?
Frankly, no.
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?
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.
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.
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.
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.
So, no. While I too prefer to use `NULL` for pointers and '\0' for
character constants, I realize that do it out of deep-seated habit, or
for nostalgic/luddite reasons mostly. Plain undecorated `0` as a
universal type-agnostic constant should really be my choice everywhere
today.
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.)
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;
On 2024-07-08, Michael S <already5chosen@yahoo.com> 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'.
Floating point: I never use 0.0.
Never say never!
printf("%f\n", 0); // undefined behavior.
printf("%f\n", 0.0); // correct
If you're #define-ing a floating-point constant that has
no fractional part, you should put that .0 there.
Someone's going to pass your constant as a variadic argument,
where it doesn't convert to floating-point.
Also:
1/3 -> 0
1/3.0 -> 0.33333...
If you're #define-ing a floating point constant that has
no fractional part, and don't include the .0, and the
programmer uses it as a division denominator thinking that
it's a floating-point quantity, oops!
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.
On Tue, 9 Jul 2024 02:49:49 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
On 2024-07-08, Michael S <already5chosen@yahoo.com> 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'.
Floating point: I never use 0.0.
Never say never!
printf("%f\n", 0); // undefined behavior.
printf("%f\n", 0.0); // correct
Yes, but that's extremely rare that I want constant (except string
literal) as variable argument to printf().
If you're #define-ing a floating-point constant that has
no fractional part, you should put that .0 there.
I am trying hard to avoid #define-ing floating-point constants.
In rare cases where it is not avoidable, most often the constant does
have fractional part. I am not sure what I would prefer when I can't
avoid #define-ing and the constant has no fractional part. Will I write something like '#define ANSWER ((double)42)' or (42.0) ?
It depends on the mood of the minute.
p = nullptr;
(0 == p == nullptr == NULL == 0) == true ?
Am I missing something here? If so, here is a preemptive: Shit!
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).
On Tue, 9 Jul 2024 02:49:49 -0000 (UTC)
Kaz Kylheku <643-408-1753@kylheku.com> wrote:
On 2024-07-08, Michael S <already5chosen@yahoo.com> 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'.
Floating point: I never use 0.0.
Never say never!
printf("%f\n", 0); // undefined behavior.
printf("%f\n", 0.0); // correct
Yes, but that's extremely rare that I want constant (except string
literal) as variable argument to printf().
If you're #define-ing a floating-point constant that has
no fractional part, you should put that .0 there.
I am trying hard to avoid #define-ing floating-point constants.
In rare cases where it is not avoidable, most often the constant does
have fractional part. I am not sure what I would prefer when I can't
avoid #define-ing and the constant has no fractional part. Will I write something like '#define ANSWER ((double)42)' or (42.0) ?
It depends on the mood of the minute.
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.
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.
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.
On Tue, 09 Jul 2024 04:32:50 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
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.
In comment above "integer constant" meant "within the range of signed
int". But let's accept more general meaning. Then, when it happens, I
have a problem and forced to flex my principles :(
Luckily, it's pretty rare. I mean, it's pretty rare that the constant
is both outside the range of signed int and I really really have to
have it as compile-time constant.
More often big numbers like these are
used in arithmetic/logic, so 'const wide_type' or 'static const
wide_type' is practically as good as a "real" compile-time constant
despite being "less constant" in theory.
On Tue, 09 Jul 2024 04:32:50 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
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.
In comment above "integer constant" meant "within the range of signed
int". But let's accept more general meaning. Then, when it happens, I
have a problem and forced to flex my principles :(
Luckily, it's pretty rare. I mean, it's pretty rare that the constant
is both outside the range of signed int and I really really have to
have it as compile-time constant. More often big numbers like these are
used in arithmetic/logic, so 'const wide_type' or 'static const
wide_type' is practically as good as a "real" compile-time constant
despite being "less constant" in theory.
On 09/07/2024 11:52, Tim Rentsch wrote:
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.
It is only for static analysis.
For instance:
enum E {Z = 0};
int main()
{
int * p;
p = '\0';
p = false;
p = Z;
}
clang has 3 warnings for this code.
https://godbolt.org/z/56fn5PT4h
Especially for p = Z and p = '\0' we have value 0 of type int, but the compiler is not blind for the other characteristics.
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
I don't like to think '\0' is null pointer.
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:It was a bit of pseudo code.
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.
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?
Hmm. I like the idea of a type-agnostic way to express a "zero"
value, [but] C's use of 0 for all scalar types strikes me more as
an historical accident than a design feature.
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
This posting has inspired me to try using (long)0.0
whenever a null pointer constant is needed. As for
example
(void*){ (long)0.0 }
as an argument to a variadic function where a pointer
is expected.
But surely ((void*)('/'/'/'-'/'/'/')) is more elegant.
To be more precise, printf shall be called if p is 0, NULL or
nullptr... They are all the same, in a sense, right?
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
On 08.07.2024 18:23, Ben Bacarisse wrote:
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?
Frankly, no. [...]
OK.
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
This posting has inspired me to try using (long)0.0
whenever a null pointer constant is needed. As for
example
(void*){ (long)0.0 }
as an argument to a variadic function where a pointer
is expected.
But surely ((void*)('/'/'/'-'/'/'/')) is more elegant.
Surely not. Furthermore the form I showed has a point,
whereas this example is roughly the equivalent of a
first grade knock-knock joke.
I was of course joking. I assumed you were as well.
What is the point of (void*){ (long)0.0 }? I don't believe it's a null pointer constant even in C23.
On 09.07.2024 00:55, Ben Bacarisse wrote:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
On 08.07.2024 18:23, Ben Bacarisse wrote:
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?
Frankly, no. [...]
OK.
So the text you snipped from my reply did not trigger any insight?
Another, last try...
Compare it to 'enum' constants. When I code or debug I want to track
(search and find) them by name not by integer number.
Similar with the 'enum' bool type we introduced (when there was not
yet a bool type existing in C or C++) with literal constants 'true'
and 'false'. (Only two values, but still as important.)
Similar with the dedicated pointer value 0 (these days we used the
literal 'null'). (Only one value, still useful for tracking eq/ne
comparisons and initializations.)
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 aSure.
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 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?
... although, one the second thought, one can probably start a Holy War
about what a proper type-agnostic declaration of a `double` variable
should look like
double d = 0;
or
auto d = 0.0;
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 Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
Compare it to 'enum' constants. When I code or debug I want to track
(search and find) them by name not by integer number.
Similar with the 'enum' bool type we introduced (when there was not
yet a bool type existing in C or C++) with literal constants 'true'
and 'false'. (Only two values, but still as important.)
Similar with the dedicated pointer value 0 (these days we used the
literal 'null'). (Only one value, still useful for tracking eq/ne
comparisons and initializations.)
Yes, you've said that before. You want to search for nullptr. I can't
think of how that might help find a real bug, if that's what you mean by bug-tracking.
I was hoping for a story... "Once I had this bug where... and if I'd
been using nullptr I'd have found it a day earlier" kind of thing. I'd
found a lot of bugs over the years, but I don't recall any that would
have been easier to find had I been able to search for nullptr.
I was looking for real-world insight here. Obviously one could make up
a bug where p = nullptr; was written where, say, p = null - ptr; was intended, but that's not what I mean.
Without such an example, your argument seems to be overly generic.
Would you welcome the introduction of the keyword unity -- with the
value 1 and type int -- into C because one could then search for it?
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.
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).
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).
I don't understand why you wouldn't use NULL.
If it's a pointer: NULL
If it's an integer: 0
If it's a double: 0.0
If it's a char: '\0'
Don't you use '\n'? Surely nobody would say 0x0a?
On 2024-07-12, Richard Harnden <richard.nospam@gmail.invalid> wrote:
Don't you use '\n'? Surely nobody would say 0x0a?
But, see, nobody in their right mind would say '\012` for that. '\0'
an octal escape sequence like '\012', not a role-based character
abstraction like '\n'.
On 11.07.2024 01:25, Ben Bacarisse wrote:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
Compare it to 'enum' constants. When I code or debug I want to track
(search and find) them by name not by integer number.
Similar with the 'enum' bool type we introduced (when there was not
yet a bool type existing in C or C++) with literal constants 'true'
and 'false'. (Only two values, but still as important.)
Similar with the dedicated pointer value 0 (these days we used the
literal 'null'). (Only one value, still useful for tracking eq/ne
comparisons and initializations.)
Yes, you've said that before. You want to search for nullptr. I can't
think of how that might help find a real bug, if that's what you mean by
bug-tracking.
I was hoping for a story... "Once I had this bug where... and if I'd
been using nullptr I'd have found it a day earlier" kind of thing. I'd
found a lot of bugs over the years, but I don't recall any that would
have been easier to find had I been able to search for nullptr.
I was looking for real-world insight here. Obviously one could make up
a bug where p = nullptr; was written where, say, p = null - ptr; was
intended, but that's not what I mean.
Without such an example, your argument seems to be overly generic.
That's why I had problems to "explain" the reasons to you; because
it's so universal a property, so obvious (as I said), that I don't
know what else I could say.
On 2024-07-12, Scott Lurndal <scott@slp53.sl.home> wrote:
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2024-07-12, Richard Harnden <richard.nospam@gmail.invalid> wrote:
Don't you use '\n'? Surely nobody would say 0x0a?
But, see, nobody in their right mind would say '\012` for that. '\0'
an octal escape sequence like '\012', not a role-based character >>>abstraction like '\n'.
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2024-07-12, Richard Harnden <richard.nospam@gmail.invalid> wrote:
Don't you use '\n'? Surely nobody would say 0x0a?
But, see, nobody in their right mind would say '\012` for that. '\0'
an octal escape sequence like '\012', not a role-based character >>abstraction like '\n'.
Actually, it's entirely likely that a programmer using C in 1978
would have used \012 for newline - it was the custom to use octal
on the PDP-11. Consider the od(1) utility, for example.
Kaz Kylheku <643-408-1753@kylheku.com> writes:...
On 2024-07-12, Scott Lurndal <scott@slp53.sl.home> wrote:
Kaz Kylheku <643-408-1753@kylheku.com> writes:
But, see, nobody in their right mind would say '\012` for that. '\0'
an octal escape sequence like '\012', not a role-based character
abstraction like '\n'.
Because '\012' is a character. 012 is an int. Using the former
ensures that any overflow will be detected at compile time and
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
On 11.07.2024 01:25, Ben Bacarisse wrote:
[...]
Without such an example, your argument seems to be overly generic.
That's why I had problems to "explain" the reasons to you; because
it's so universal a property, so obvious (as I said), that I don't
know what else I could say.
Yes, that's been the clear for a while now. That's why, when you said
you could not say more, I was happy to leave it at that (my "ok").
What example could I give that explains that if you're looking for
specific dedicated semantical values it's easier to look them up
by [semantical] name than by a [ambiguous] number.
On 11.07.2024 01:25, Ben Bacarisse wrote:
[...]
Would you welcome the introduction of the keyword unity -- with the
value 1 and type int -- into C because one could then search for it?
No. [...]
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).
I don't understand why you wouldn't use NULL.
If it's a pointer: NULL
If it's an integer: 0
If it's a double: 0.0
If it's a char: '\0'
On 13.07.2024 01:59, Ben Bacarisse wrote:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
On 11.07.2024 01:25, Ben Bacarisse wrote:
[...]
Without such an example, your argument seems to be overly generic.
That's why I had problems to "explain" the reasons to you; because
it's so universal a property, so obvious (as I said), that I don't
know what else I could say.
Yes, that's been the clear for a while now. That's why, when you said
you could not say more, I was happy to leave it at that (my "ok").
You again strip the post where my try for an explanation follows:
What example could I give that explains that if you're looking for
specific dedicated semantical values it's easier to look them up
by [semantical] name than by a [ambiguous] number.
Are those semantical names so meaningless to you?
Let's take the 'bool' sample; do you find it more helpful to look
for numerical falues in the code than to look for standard literals
like 'true' and 'false'? (It's not much different concerning 'NULL'.)
(But okay, given your last response patterns you seem to not be
interested.)
Don't you use '\n'? Surely nobody would say 0x0a?
On Fri, 12 Jul 2024 14:19:19 +0100, Richard Harnden wrote:
Don't you use '\n'? Surely nobody would say 0x0a?
Why not full symbolic Unicode names, à la Python:
"\n" == "\N{LINE FEED}"
⇒
True
On 11.07.2024 01:25, Ben Bacarisse wrote:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
Compare it to 'enum' constants. When I code or debug I want to track
(search and find) them by name not by integer number.
Similar with the 'enum' bool type we introduced (when there was not
yet a bool type existing in C or C++) with literal constants 'true'
and 'false'. (Only two values, but still as important.)
Similar with the dedicated pointer value 0 (these days we used the
literal 'null'). (Only one value, still useful for tracking eq/ne
comparisons and initializations.)
Yes, you've said that before. You want to search for nullptr. I
can't think of how that might help find a real bug, if that's what
you mean by bug-tracking.
I was hoping for a story... "Once I had this bug where... and if
I'd been using nullptr I'd have found it a day earlier" kind of
thing. I'd found a lot of bugs over the years, but I don't recall
any that would have been easier to find had I been able to search
for nullptr.
I was looking for real-world insight here. Obviously one could
make up a bug where p = nullptr; was written where, say, p = null -
ptr; was intended, but that's not what I mean.
Without such an example, your argument seems to be overly generic.
That's why I had problems to "explain" the reasons to you; because
it's so universal a property, so obvious (as I said), that I don't
know what else I could say. (Likewise with "real-word examples".)
What example could I give that explains that if you're looking for
specific dedicated semantical values it's easier to look them up
by [semantical] name than by a [ambiguous] number. Yes this speeds
up detection of errors when doing code inspections (for bugs or as
QA measure), and yes, this was helpful for program development and
bug detection in [my professional and private] practice.
Would you welcome the introduction of the keyword unity -- with the
value 1 and type int -- into C because one could then search for it?
No. (Please don't start to be ridiculous. - Or did you really miss
the point? - No offense intended.)
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
Hmm. I like the idea of a type-agnostic way to express a "zero"
value, [but] C's use of 0 for all scalar types strikes me more as
an historical accident than a design feature.
I don't think it was an accident at all. It was chosen to be
consistent with how if(), while(), !, ?:, and so forth, all act.
There is a very consistent design philosophy there. Sometimes
people who come from a strong Pascal background don't like it,
but personally I find the C model easier and more convenient to
work with than the Pascal model.
In early C, int was in a very real sense the default type. In B,
types weren't even explicit, and IIRC variables were effectively "of
type int", or more precisely a 16-bit PDP-11 word. (I'm glossing
over some details of B, many of which I don't know). In that
context 0 made sense as a general-purpose "zero" value.
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
This posting has inspired me to try using (long)0.0
whenever a null pointer constant is needed. As for
example
(void*){ (long)0.0 }
as an argument to a variadic function where a pointer
is expected.
But surely ((void*)('/'/'/'-'/'/'/')) is more elegant.
Surely not. Furthermore the form I showed has a point,
whereas this example is roughly the equivalent of a
first grade knock-knock joke.
I was of course joking. I assumed you were as well.
What is the point of (void*){ (long)0.0 }? I don't believe it's a
null pointer constant even in C23.
My example is.
On 7/10/24 17:23, Keith Thompson wrote:
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
This posting has inspired me to try using (long)0.0
whenever a null pointer constant is needed. As for
example
(void*){ (long)0.0 }
as an argument to a variadic function where a pointer
is expected.
But surely ((void*)('/'/'/'-'/'/'/')) is more elegant.
Surely not. Furthermore the form I showed has a point,
whereas this example is roughly the equivalent of a
first grade knock-knock joke.
I was of course joking. I assumed you were as well.
What is the point of (void*){ (long)0.0 }? I don't believe it's
a null pointer constant even in C23.
I think you're right about that.
"An integer constant expression132) ... shall only have operands
that are ... compound literal constants of arithmetic type that
are the immediate operands of casts. ... Cast operators in an
integer constant expression shall only convert arithmetic types to
integer types, ...", so (long)0.0 is permitted."
While (void*) looks like a cast, in this context it is a compound
literal of pointer type, which is not allowed. [..]
NULL is required to expand
into a null pointer constant ... 0 and (void*)0 are the
two most likely and common choices.
On 7/15/24 18:51, Lawrence D'Oliveiro wrote:[silliness]
Keep in mind that, in text mode, the <stdio.h> library routines use '\n'
in memory to represent whatever platform-specific method is used in
files to indicate a new line. For example, that can be a simple '\n' on typical Unix-like machines, '\n\r' or '\r\n' on other operating systems,
and on a number of older systems, it could be converted to and from a fixed-size block with a character count at the the beginning of the
block. There's no requirement that it be the Unicode line feed character.
On Mon, 15 Jul 2024 19:49:08 -0400, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 7/15/24 18:51, Lawrence D'Oliveiro wrote:[silliness]
Keep in mind that, in text mode, the <stdio.h> library routines use '\n'
in memory to represent whatever platform-specific method is used in
files to indicate a new line. For example, that can be a simple '\n' on
typical Unix-like machines, '\n\r' or '\r\n' on other operating systems,
and on a number of older systems, it could be converted to and from a
fixed-size block with a character count at the the beginning of the
block. There's no requirement that it be the Unicode line feed character.
I never knew any older system that used a fixed-size block (or rather
record, which in those days was not the same as block) AND prefix
count in the same file, although OS/360 et seq used ONE of them.
And Tandem Enscribe used either offset or count fields (depending on structure) at _end_ of block, near but not adjacent to records, except
for textfiles had prefix counts per line AND word (of nonblanks) --
but the initial versions of their C implementation couldn't handle
textfiles, so you had to convert them to and from 'data'.
On Wed, 10 Jul 2024 11:09:41 -0400, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
NULL is required to expand((void*)0)
into a null pointer constant ... 0 and (void*)0 are the
two most likely and common choices.
Otherwise NULL["foo"] gives quite the wrong result
On Mon, 15 Jul 2024 19:49:08 -0400, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 7/15/24 18:51, Lawrence D'Oliveiro wrote:[silliness]
Keep in mind that, in text mode, the <stdio.h> library routines use '\n'
in memory to represent whatever platform-specific method is used in
files to indicate a new line. For example, that can be a simple '\n' on
typical Unix-like machines, '\n\r' or '\r\n' on other operating systems,
and on a number of older systems, it could be converted to and from a
fixed-size block with a character count at the the beginning of the
block. There's no requirement that it be the Unicode line feed character.
I never knew any older system that used a fixed-size block (or rather
record, which in those days was not the same as block) AND prefix
count in the same file, although OS/360 et seq used ONE of them.
And Tandem Enscribe used either offset or count fields (depending on structure) at _end_ of block, near but not adjacent to records, except
for textfiles had prefix counts per line AND word (of nonblanks) --
but the initial versions of their C implementation couldn't handle
textfiles, so you had to convert them to and from 'data'.
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((void*)0)
into a null pointer constant ... 0 and (void*)0 are the
two most likely and common choices.
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."
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 00:48:57 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,573 |