Every story and comment from the Hacker News API, in a layout borrowed from 2001.
A comment on Undefined behavior is often a thing for C programmers (2011). Parent comment
Why would you not actively avoid undefined behaviour and instead take risk.
Zeroing out variables, checking pointers coming from external modules etc. Not rallying on a compiler to resolve fancy stuff.
Like the example:
void contains_null_check(int P) { int dead = P; if (P == 0) return; P = 4; }
Leave declarations uninitialized or zeroed Check input. Work with data.
void contains_null_check(int P) { int dead; if (P == 0) return; int dead = P //work P = 4; }
This leaves less space for error/interpretation and IMHO it keeps code cleaner.
Any fancy optimizations should be used only for critical path and only when absolutely necessary.
There are no comments on this comment yet.
Why would you not actively avoid undefined behaviour and instead take risk.
Zeroing out variables, checking pointers coming from external modules etc. Not rallying on a compiler to resolve fancy stuff.
Like the example:
void contains_null_check(int P) { int dead = P; if (P == 0) return; P = 4; }
Leave declarations uninitialized or zeroed Check input. Work with data.
void contains_null_check(int P) { int dead; if (P == 0) return; int dead = P //work P = 4; }
This leaves less space for error/interpretation and IMHO it keeps code cleaner.
Any fancy optimizations should be used only for critical path and only when absolutely necessary.