No, observing a pointer is not the same as dereferencing it.C compilers remove your bounds checks and null checks that you, the programmer, explicitly wrote in the program, even if they are known to fail, and then crash on input that your checks would have prevented. The real scary thing is that people had to write code to determine that you're checking array bounds and more code to remove the check.
if(ptr == NULL) puts("Hey, this pointer is NULL!"); does NOT get optimized out, because checking whether a pointer is NULL is NOT undefined behavior, and so the compiler cannot assume that the pointer is never null. Likewise with bounds checking, trying to ACCESS an array beyond its bounds is undefined behavior, but doing a simple arithmetical comparison on the number before using it as an array index is not. As for overflow, just compare to INT_MAX before doing any operation that will increase the value, and use unsigned wherever you can. The one serious flaw with C is that it has the "const" qualifier which really only means readonly; you can't use const objects as the size of static arrays, since the compiler can't guarantee that the object won't be modified via a pointer-to-mutable-object. does NOT get optimized out, because checking whether a pointer is NULL is NOT undefined behavior, and so the compiler cannot assume that the pointer is never nullYou're right that it doesn't ``optimize out'' anything. It removes code the programmer wrote.
The idiom here is to get a pointer to a device struct, test it for null, and then use it. But there’s a problem! In this function, the pointer is dereferenced before the null check. This leads an optimizing compiler (for example, gcc at -O2 or higher) to perform the following case analysis:
As we can now easily see, neither case necessitates a null pointer check. The check is removed, potentially creating an exploitable security vulnerability.
That a pointer dereference preceding a NULL check made it into kernel code indicates a flaw in coding practices, not a flaw in the compiler.
element struct has 32-bits of padding, and it's not CPU cache friendly. You should use two orthogonal arrays instead of a struct.qsort is slow as fug. Do a fucking parallel bitonic sort with OMP or a radix sort.khash. Who the fuck uses khash? https://github.com/attractivechaos/klib/blob/master/khash.hfgets? If you're using non-standard shit like khash, why not use POSIX libraries like read and read in huge blocks from the file, instead of 4K at once. Way faster for large files.it's because before the NULL check is even reached, the program has ALREADY entered an undefined state.The kernel has control over the memory. NULL is just a pointer which, on every architecture Linux runs on, can be mapped to valid memory. There is nothing wrong with accessing page 0 or triggering a page fault because the kernel has control over the fault handler.
C makes undefined behavior trivial to invoke by accidentBad compilers are the problem. C semantics is the problem. C was always an unsafe language, but standardization made it worse. If you add to an address, the C compiler can break your code. Compilers can magically know where a pointer comes from and use it to break code, not a real optimization like constant folding a pointer calculation, but actually making code that works no longer work.
register to put something in a real register to use with inline assembly. That also means there is a ton of architectures C can't run on. C won't run on decimal computers, descriptor architectures, etc. and that's no problem because C wouldn't be a systems language on that hardware anyway. Why do you want to use a systems language on hardware where it couldn't be a systems language?It's a fine language for 1970s systems programming, but in the present day we have different concerns.The designers and users of PL/I, Ada, Multics, and mainframes would very strongly disagree with you. They had those same concerns back then.
UB is generally caused by programmer error
I bet we could get the C version running in half the time of Rust.
This code IS an exploitable security vulnerabilityackshually, null derefs aren't exploitable in the kernel anymore because low memory addresses are not mappable
Rust beats C in a single benchmark that is also dependent on third party code on the C side (``use either khash or CK_HT for C language k-nucleotide programs. [..] Please don't implement your own custom "hash table" - it will not be accepted.'')
The headline reads
Rust is now faster than C
The Lisp machine people wanted to be able to run C even though it couldn't be a systems languageah yes, the all-powerful Lisp machine industry which controls the world. and they want everyone to use C because undefined behaviour makes C an acceptable Lisp!
tfw PHP is faster than Chttp://benchmarksgame.alioth.debian.org/u64q/performance.php?test=regexdna