How does /g/ feel about the humble null pointer?

>>61106998
>/g/
>knowing about pointers

/g/ is a safe space
only garbage collected languages are allowed here

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

>>61106998
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

>>61107479
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

>>61107524
Sounds ambiguous and most likely much less efficient.

>>61107566
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)

>>61107524
>>61107566
>>61107596
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.

File: zoomedpepe.jpg (18KB, 600x315px) Image search: [Google]

18KB, 600x315px

>>61107627

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

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

totally agree with u

>>61106998
>How does /g/ 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.

File: 1496706150082.png (453KB, 498x717px) Image search: [Google]

453KB, 498x717px

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

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

feels very bad man

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

File: malloc_chan.jpg (571KB, 3840x2160px) Image search: [Google]

571KB, 3840x2160px

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

>>61107524
>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.

>>61106998
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.

>>61108027
>benefitical
kek

>>61107524
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.

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

>>61108774
Don't lie to me anon, 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?

>>61108803
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.

>>61108842
>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?

>>61108893
nullptr was a mistake

>>61108863
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.

>>61107524
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.

>>61107709
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?

>>61107778
>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.

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

>>61108893
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.

>>61109399
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

>>61109417
*can't ever use y without dereferencing