Talk:Null pointer

Lisp NIL

Note that NIL in most Lisps (Common Lisp in particular) is both a symbol and a list. It is not, contra the introduction to the Null pointer, an invalid object, it is the empty list (as well as the equivalent of false in Common Lisp, but not, say, Scheme). As the article does mention, NIL is first class, and the user can (though it is considered bad programming practice) create properties on NIL, as they can for any other symbol. Gorbag42 (talk) 16:55, 28 January 2024 (UTC)

Relational database null

A paragraph in the article contrasts a null pointer with a null in a relational database null. It describes the database null as an unknown value, but the Null (SQL) article says a database null is a non-existent value. So I've removed the whole paragraph.--A bit iffy (talk) 19:40, 20 April 2017 (UTC)

Dereferencing the null pointer in C always undefined or not?

The section C currently says:

"dereferencing the null pointer is a perfectly valid but typically unwanted action that may lead to undefined but non-crashing behavior in the application"

But the section "Dereferencing" currently says:

"In C, the behavior of dereferencing a null pointer is undefined"

These statements are not the same. I think the problem is in the first one, because it seems to assume that the "null pointer" is the same as the pointer to address zero. But I'm no expert, so I thought the proper action is to put it here.. — Preceding unsigned comment added by 185.147.13.130 (talk) 15:01, 7 May 2018 (UTC)

Thank you for your note. You are right: the C standard does not say that the null pointer is the same as the pointer to address zero, and dereferencing the null pointer is always undefined behavior in C (and the implementation is allowed to assume that that any pointer that is dereferenced is not null). The section C is certainly misleading.

I have tried to fix this. Is it better now? – Tea2min (talk) 07:10, 8 May 2018 (UTC)

Thanks. But it still says "There are occasions when dereferencing the null pointer is intentional and well-defined", should that not be "There are occasions when dereferencing the pointer to address zero is intentional and well-defined"? Or am I not understanding the concept? 185.147.13.130 (talk) 09:36, 9 May 2018 (UTC)

You are right. Feel free to fix that section. – Tea2min (talk) 09:54, 9 May 2018 (UTC)

I did that! 185.147.13.130 (talk) 10:19, 9 May 2018 (UTC)

What will happen if you will do this mmap( ( void *) 0, ( size_t ) 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0 ); 2A00:1370:812C:9562:3073:140:AA00:A551 (talk) 11:05, 4 May 2020 (UTC)

Doesn't matter, the C standard still does not define it. Use <code>your code here </code> next time you want to put code somewhere on Wikipedia. Please do not enter it into the article unless you find a citation for it. Holzklöppel (talk) 10:16, 20 August 2022 (UTC)

TenDRA compiler framework and 0x55555555 as NULL

The TenDRA compiler framework, which provides for architecture neutral representation of compiled programs, allows the user to set the null pointer representation to 0x55555555. The representation helps find incorrect and non-portable programs.

I know the statements are correct. I don't know how to cite them since they are on GitHub at https://github.com/tendra/tendra/wiki/About and https://github.com/tendra/tendra/blob/main/trans/man/trans.1/trans.1.xml#L1548.

Jeffrey Walton (talk) 16:01, 23 April 2023 (UTC)

This is a trivial detail, not rising to the level of something that should be covered in the article at all. The lack of proper sourcing is clear evidence of that. MrOllie (talk) 01:11, 19 May 2023 (UTC)

VM claim

"User code running in interpreted or virtual-machine languages generally does not suffer the problem of null pointer dereferencing." I have made the section on mitigation clearer. However, I left the sense of this in, but I think it is a dubious claim. Interpreted of VM languages may certainly have nulls. I think Java does. Ian.joyner (talk) 05:04, 26 August 2024 (UTC)

It is dubious. If you compile a programming language that has pointers or references, and that has a null value for pointer or reference types, into a bytecode and interpret the bytecode, rather than compiling it to machine code, that doesn't magically make it impossible to attempt to dereference a null pointer or reference. Not having pointers or references in a programming language, or not allowing them to be given a null value, would result in code that does not suffer the problems of null pointer or reference dereferencing, regardless of whether it's compiled to machine code or to interpreted bytecode.

Maybe they're thinking that the interpreted code will report dereferencing a null value in a cleaner fashion than a reference to an unmapped part of the address space, but that doesn't mean the problem has gone away, it just means that the user who sees the error will get a different form of noise displayed when it happens.

I've marked that comment with {{dubious}} and pointed it to this talk page section. Guy Harris (talk) 09:55, 20 September 2024 (UTC)