Hacker News Reader

Comment by buserror | Hacker News Reader

I tried the -fanalyser recently with a piece of C code. OMG. pages and pages and pages of "possible-NULL" and other "c/m/realloc(...) could return NULL!". Really, if I'm in a situation where *alloc() returns NULL, I'm happy for the program to SIGBUS, the machine is probably in a sorry state and there's no safe "software" path that would make it all magically better.

The clang analyser, or cppcheck is a LOT more pragmatic about these things. the gcc one is SO noisy as to make it useless at the minute, TBH.

Disclaimer: I'm actually a fan of gcc!

View on HN

If you want "malloc failure is fatal", which I agree is a good idea for a lot of programs, the way to do that is have a wrapper that aborts() if it does, not to just ignore the possibility of error. That way if the unlikely event ever does happen you get an immediate and clear failure, rather than a NULL which might eventually some time later get dereferenced, so if you get a user crash report you don't ever have to spend time debugging "why did this NULL get here in this data structure? was it maybe a memory corruption bug?".

It also means that if you're dealing with untrusted input you have a guard against that data provoking a huge malloc that fails and manages to do something unexpected as a result. Sure, most of the time the "something unexpected" isn't interesting (immediate crash), and there probably ought to have been a range-check on the input data already, but the NULL-check-and-abort means you never have to spend any time thinking about whether the code is the 0.1% "interestingly exploitable" case. Not having to think about a whole class of situations is pretty valuable IME.

An even better reason is that by having an xmalloc() that exits on failure the compiler's code flow analysis will be improved.

That's because it knows it'll be impossible for the return value of that malloc() to be NULL.

Gcc is doing the right thing. You can't blindly assume malloc() never fails. That is up there with assuming int is always 32-bit and painting yourself into a corner with unportable code.

I can almost guarantee that you will add more bugs to your code trying to 'recover' from a malloc failing than just letting your process crash, and hopefully get launched at a better time.

The /correct/ way to write a production code is to assume your program will crash at some point, and it should be able to recover from for example, out of sequence starting. Even if it's not malloc(), the scheduler might kill you for its own reasons.

What do you DO if malloc fails? Cry for help? Oh oops, "cry()" might need to allocate memory.

Also, I was writing code when int was 16 bits, and quite frankly, the size of int was never really a huge problem in porting code, and I ported a LOT of code. I found a lot more problems trying to find code that were trying to 'fix unfixable" errors, like IO errors.

D does have lifetime annotations so it might be interesting to tell the Analyzer that certain things can't escape

Does it? Are they finally done or is it yet another feature left as WIP before the attention switched into ImportC?

The borrow checker aspect doesn't really work but the lifetime annotations themselves are pretty complete i.e. the question is now making it allow more behaviour not catching bugs.

So basically the same history as other WIP features, thanks.

Reply on news.ycombinator.com