Making null pointers possible in the 21st century

>im retarded and get a lot of run time errors because i copy paste code from the internet and therefore dont know i have to handle if memory allocation, file handling, anything that uses pointers fails

>why is derferencing a piece of memory that doesn't correspond to my object dangerous?

multiply that 700 hundred times, it gets old fast

the absolute state of delusional go-cucks

Attached: btfo.png (1576x1736, 266K)

>Because dereferencing a null pointer is UB, which is why every function which could accept a null pointer must check for it. Otherwise, your compiler might sabotage you.
You don't know anything about compilers or UB. Pointers in C and C++ are assumed to be non null upon dereference so there's no UB and the compiler isn't allowed to sabotage shit as long as the pointer isn't actually null, which is your responsibility.

dereferencing the virtual memory address "0" always triggers segmentation fault errors by most modern operating systems which kill your entire process abruptly

the compiler might sabotage you? get out of here with your schizo bullshit. it'll try and deference 0. this, in most contexts will be illegal and on modern operating systems you can widely expect it to cause the process to exit.
this is easily mitigated by not assigning the value 0 to your pointers unless you specifically need to.
if you're specifically concerned about null pointers you shouldn't be using pointers at all.

...

You also don't know anything about compilers or UB.

you still arguing that null pointers aren't bad after you got totally assblasted you low IQ illiterate nigger?

i'd say I have some idea. I've been developing exploits for enterprise software for the past 2 years, and playing CTFs for several years before that.

If the problem is that the pointer is zero, why don't we just make the null pointer another number, like pi? Problem solved.

Attached: 1501631622001.png (741x568, 29K)

if unsafe { p.is_attributes().contains(megasafelib::pointer::attributes::get("is_null_pointer".to_string())) } {
// handle null pointer
}

Attached: that 35-year-old zoomer.gif (931x682, 426K)

Funny, because you don't actually know anything about compilers, lol. You think null dereference is defined in any way, you think on modern systems it'll crash. You don't know anything at all.
As expected of a "security researcher" that doesn't actually program.

You type like an Indian.

so this... is the power... of go...

Tony hoare apparently felt the need to apologise for inventing the null pointer.

infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare

is this a bait or you're really that retarded?

it literally is defined you dense motherfucker

Attached: 65d.png (434x327, 32K)

>it's the most retarded and dangerous thing from a language perspective
it's dangerous only when you are not white enough for programming.

>which kill your entire process abruptly
which is the safest thing that could happen in that situation. explain how that is "unsafe"

Multi-process system using %TEMP%/myfile.txt for IPC and the other processes are parsing/writing data non-transactionally based on the responses from your crashed process.

well yeah; but that isn't unsafe from a security standpoint, just potentially a business continuity one. same could be said for any type of bug caused by any number of different programming errors.

match p {
Some(p) => do_something_with(p),
None => handle_null_pointer(),
}

Java:

Boolean opHasACock = null;

>get("is_null_pointer".to_string())

Attached: 1547859705369.gif (295x221, 574K)

So if null pointers are bad then how do you perform garbage collection?

You use RAII and have deterministic resource lifetimes, throwing your GC in the nearest trash can.

Do you guys actually even program in C? It's amazing you are still ignorant of UB and the fact that the compiler is allowed to do whatever optimizations it likes, including removing condition blocks and reordering your code.

Attached: null pointer.png (944x762, 80K)

Having had several "real jobs" I can confirm that this level of shitty "enterprise" code is exactly what you can expect from half-dead soulless 40 year old men who haven't seen the outside of a cubicle since college

So you're saying that compilers *don't* generate code like this?
lea ebx,
mov eax, [ebx]

If you actually program in C, you'll know that UB is relied upon to accomplish a lot of real work, whether you like it or not. It's why to this day it's virtually impossible to compile the Linux kernel on clang. It doesn't mean that it's good to rely on UB, but it just highlights the difference between "real" C programmers and the people who masturbate to the C spec all day on #C IRC channels.

Also, to add to this, compiler authors are not fucking retards, and they *know* that tons of people rely on null-pointer checks and they actively try not to fuck up common workflows, even if they don't always succeed.

yeah, i write C
not sure why you seem to believe this is relevant whatsoever
obviously you should check the return value of pci_get_drvdata BEFORE dereferencing dev. that's just fucking dumb.

null pointers aren't that big of an issue
the way they are implemented in C is

wrong

wrong

At least in C, the 0 pointer is not defined to correspond to the 0 address.

holy shit, who wrote that broken code?
obj = get_object("filename")
process_object(obj)
if obj is None:
print "An error occurred!!"
exit()

Why the fuck is python so broken???

Pointers can always be null because addresses are integers and integers can be zero

Once again, the difference between masturbating to the spec and the actual behavior of every compiler ever. Testing null pointers with if (!ptr) {...} is so common that even if some hypothetical compiler made NULL not be 0, nobody would ever use it.

Call me up when you don't have to do

err != nil

on every fucking function call

lazy cunt

which line

Call me when you figure out how code tags work.

line 2

ok

hahaha ok idiot

>If you actually program in C, you'll know that UB is relied upon to accomplish a lot of real work,

Can you show me a portable example of where UB is useful? The only justification I've seen for UB is to simplify compilation and make aggressive optimizations.

>If you actually program in C, you'll know that UB is relied upon to accomplish a lot of real work, whether you like it or not. It's why to this day it's virtually impossible to compile the Linux kernel on clang.
Why are you spewing horseshit? Linux was/is developed against GCC and its extensions, not a conforming C standard, which is what leads to incompatibilities with Clang.

Funny, because NULL is defined as (void *)0

>dereferencing a null pointer is UB
nope, it's just an unchecked exception

>spec
lol, using big boi words now?
>every compiler ever
how would you know?
>if (!ptr)
nothing to do with address 0, webcuck

funny you don't know what the fuck you're talking about ;^)

>spec
>big boi word

found the brainlet

it is defined as zero value but it's special case handled specially by the compiler
C as a language specification doesn't really have null pointer, libc and compiler does

>C as a language specification doesn't really have null pointer
found the webshit

Perfection

A fucking waste of typing that's less logically clear than if (!p) {...}

Give me a compiler that doesn't set NULL to 0, nigger

>set NULL to 0
so this is the power of the csscucks

Javac

In an office setting with a team of fairly average programmers (including myself), null exceptions happen. It's a lot better than the UB in C. Ever debugged a smashed stack? It's a nuisance to be fair.