Hacker News Reader

Comment by EpicEng | Hacker News Reader

Well apparently I do know C. If the author wanted to be as contrived a possible there are certainly more devious edge cases which could have been trotted out. The fact that e.g. the compiler may optimize out a NULL check after you've already dereferenced the darn thing shouldn't be surprising. Just fix your silly bug.

View on HN

The problem is that (correct me if I'm wrong) an expression like "&foo->bar" counts as a dereference of foo, even though the result of the expression is simple pointer arithmetic involving foo (adding the offset of the bar member).

Yes, you're correct [1], and that's why offsetof is a builtin in gcc and clang.

Even more insidious is the fact that memcpy of zero bytes from or to null is undefined behavior.

[1]: http://stackoverflow.com/questions/26906621/does-struct-name...

That's what offsetof() is for! http://man7.org/linux/man-pages/man3/offsetof.3.html

I've worked on a system where NULL mapped to valid memory. (It was an embedded system, so the memory map was custom and bizarre). Of course, insanity ensued when new programmers worked on it.

Is it the kind of system for which memset(somestruct, 0, sizeof(somestruct)) doesn't work if the struct has pointers (NULL isn't 0, so null checks will fail if one inits such struct like this)?

Not really, NULL is still 0, but the address "0" is valid and readable/writable.

NULL does not have to be 0 in the sense that it is represented by all 0 bits, it need only compare equal to 0.

Yeah but to fix that, you only have to not use that byte of memory. Or not have to point to it. Not a real issue.

Clever pseudonym mr Sweeney ;)

Ha, I wish! I just happen to work for another 'Epic'ly named company.

Reply on news.ycombinator.com