How does Sup Forums feel about the humble null pointer?

How does Sup Forums feel about the humble null pointer?

>Sup Forums
>knowing about pointers

Sup Forums is a safe space
only garbage collected languages are allowed here

In spite of what neets often claim, not the worst mistake by far.

it's funny because it allows people to hack shit

The concept of null values would get "invented" at some point regardless of garbage collected languages. You're retarded if you think null references were a "mistake". It's like saying the number 0 is a mistake.

I don't really see any viable alternative to null pointers. They serve a very clear purpose.

I find it hard to imagine a low-level language without them

a viable alternative is something that doesn't let you dereference if you're not sure the value isn't null. I mean something like option/maybe

Sounds ambiguous and most likely much less efficient.

there is an implementation of Maybe in Haskell that uses null pointers under the hood, so it can be implemented as a zero-cost abstraction (though you can't do something like Just Nothing with it I think)

This is why everyone hates you people. You make vague specious arguments that you believe make you sound smart, but everyone knows that you are just circlejerking each other. Do you know why people don't challenge your bullshit? It's because you aren't worth their time!

Fuck off.

...

I wish you could still allocate to 0x0000
Those were the good days when controlling eip was easy

I think it's extremely useful and that retard in your picture is retarded.

totally agree with u

>How does Sup Forums feel about the humble null pointer?

Well, you only have two choices: it can point to null, or it can point to a defined object.

If it points to a defined object, then you have to deal with the case where the object is not logically present. (For example, in a linked list, where the final element is physically present, but it's not considered to be a logical element of the list.)

The only way I know to treat a physical object as "not logically present" is with some kind of extra bool field, enum field, or similar. (For example: "bool exists;")

So whatever code you need to test that extra field -- that's pretty much the same kind of code you would need if you allowed null pointers. So I don't see much of a difference from a logic perspective: no matter what, you still have to deal with ends of lists, childless nodes, etc.

I think the main disadvantage of the null pointer is illegal dereferencing. But that's purely a function of the risk/efficiency trade-off of the language. For example, C tries for maximum efficiency -- so it won't check for null dereferencing and it will just assume that the error will be either caught or ignored by the OS (if there even is an OS). But in a managed execution environment (JVM, CLR, etc.) the trade-off is opposite: dereferencing is performed less efficiently, but it's safer, because the error path is totally predictable.

Maybe it sucks for the average dev, but for us low-level embedded systems guys, they're great mate

HHHHHHNNNGGGGG
>tfw you'll never be strangled by hefty asian thighs

feels very bad man

Nice fake news. Tony hawk was a fictional character from a 90s skateboarding computer game, not a programmer.

>some people are retarded and can't use a tool properly
>somehow the tool is the problem

>a viable alternative is something that doesn't let you dereference if you're not sure the value isn't null. I mean something like option/maybe

You need to define what "doesn't let you dereference" means.

If the language has null pointers, then the some programs are going to attempt to dereference null pointers. There's nothing you can do to prevent the *attempt* to dereference a null pointer.

But you do have a choice about what safeguards are in place to make sure that null dereferences result in a well-defined code path. Some languages have no well-defined code path, and some do.

For languages that don't have a well-defined code path for null dereferences, you need to rely on testing for robustness. (You can see how well that worked out.)

For languages that do have a well-defined code path for null dereferences, it's usually implemented through the exception-handling (try/catch) mechanism. Every dereference must be checked at run-time -- which reduces the efficiency of the code. That's no surprise: you can be safe, or you can be fast, but you can't be both at the same time. The only thing left to do is to choose your trade-off wisely.

null is considered benefitical.
Only dumb javafags who think that "if it compiles it work" have problem with null.

If you appreciate type safety, then you should hate null. Null is the absence of a value masquerading as the type you're referencing. A type should always point to a value of that type, it's absence should be a different type.

The Maybe or Option monads as well as Unit (the nothing value). This is the best way to deal with it, having experience with both imperative and functional. In this way, you will rarely, if ever, get a null reference exception. Plus Pattern Matching is a much more effective way of dealing with the potential absence of data.

>benefitical
kek

this
optional types are superior. null is not a pointer, is is the absence of a pointer. This should be represented within the type system.

>Mister malloc is a wizard who answers the requests of everyone!

Don't lie to me user, does it really say that?

Also, Tony Hoare is the relational model guy and yet we're all talking about pointers? So which came first?

The blue dialog says that. The other text in figures tells you what you say to malloc and what malloc responds when using it.The text in the bottom continues the lesson, apparently.

>Tfw tricked into learning C from K&R instead of a book with cute waifus

int* x = nullptr;
int& y = *x;


Where is your god now?

nullptr was a mistake

If you knew runes then it might not have been a problem to learn from that book.
But I'm guessing you don't and I don't think this is going to ever get a translation.

That's basically what null pointers do. The problem isn't "dereferencing a null pointer", the problem is dereferencing an INVALID pointer. Null pointers minimize the danger, by having programmers follow the practice that every pointer must be either valid, or null. That way, if that practice is followed, you can simply compare a pointer to NULL, and if it compares unequal, then you can safely dereference it.

Does the existence of a null pointer address mean that the address space is 1 byte smaller than calculated? i.e. with 32 bit pointers = 2^32 byte = 4 GiB address space. But since one address has to be reserved for the null pointer, isn't the usable memory actually 4 GiB minus 1 byte?

>The only way I know to treat a physical object as "not logically present" is with some kind of extra bool field, enum field, or similar. (For example: "bool exists;")
Perhaps in a linked-list implementation, if it's only going to store positive integer values (and you don't need the range provided by unsigned), you could perhaps use a negative integer as an end-of-list sentinel value. Though that wouldn't be compatible if you want to use your linked list to store other types.

Hoare, not Hawk. He's the guy that invented quicksort.

Pretty sure this doesn't let you get around the "no null reference" rule, since even with lazy evaluation you can't ever use C without dereferencing a null pointer, which is UB and usually results in a segmentation fault.

The entire first page isnt mappable in memory so it's would be 2^32 - 0x1000
Up until windows 7? You could write to the first page, so you'd dump code there and find a null deref and gain code exec

*can't ever use y without dereferencing