3 ms·
I understand the problem, but I am concerned by the solution. The problem is that C semantic is quite clear on the subject[1]: dereferencing a null pointer is u
by lesenek 4y ago
I understand the problem, but I am concerned by the solution. The problem is that C semantic is quite clear on the subject[1]: dereferencing a null pointer is undefined behavior, not "non-standard behavior" which would suggests correct albeit non-portable behavior. I don't know of any compiler switch that tells the compiler to "define" this behavior, like `-fno-strict-aliasing` or `-fwrapv` do.
[1] ISO/IEC 9899:2011 §6.5.3.2
- bheadmaster 4y agoI understand - I deliberately used the vague term "non-standard behavior", since the solution somehow works. There is a GCC flag "-fno-delete-null-pointer-checks" [0] which seems like it might enable this behavior, but I'm not sure. [0] https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc/Optimize-Options.html#:~:text=Use%20%2Dfno%2Ddelete%2Dnull,by%20default%20on%20most%20targets https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc/Optimize-Option.... P.S. Seems like your account is shadowbanned. Might want to contact dang: hn@ycombinator.com if you plan on posting more.
- lesenek 4y agoFrom my understanding, I think that option only prevents the compiler from removing null checks when the pointer was dereferenced before. It was probably motivated by this incident in the Kernel[1] where an optimized-out null check condition (because it was dereferenced right before) caused a vulnerability. I like this story, since both sides (Linux vs GCC) have perfectly reasonable positions IMO. [1] https://lwn.net/Articles/342330/ https://lwn.net/Articles/342330/ PS: I took action by contacting Dang about the shadowban; thank you for warning me, I was wondering why I felt like a ghost.