4 ms·
When writing modern C in a disciplined way, it is not as bad as the Rustophiles will make it out to be, but still a problem. Scenarios where I frequently end u
by jstewartmobile 10y ago
When writing modern C in a disciplined way, it is not as bad as the Rustophiles will make it out to be, but still a problem.
Scenarios where I frequently end up fixing other people's memory errors:
1. No Error Handling: not checking an error condition on a function that allocates, then using the uninitialized pointer anyway
2. Sloppy Error Handling: jumping to abort from an error without freeing what has already been allocated
3. Faith in \0: still using the old string functions
I'm on the fence about the whole thing, so others may be able to field something more compelling.
- pjmlp 10y agoTry fixing those errors in binary libraries or enterprise code.
- moosingin3space 10y agoA properly-designed Rust API will not allow code without error handling to compile, so 1) should be much less relevant in Rust. 2) I can't remember if a panic in Rust calls destructors, which would clean up that memory. Can someone answer that please? 3) is only relevant in FFI scenarios in Rust, and everywhere else is irrelevant because Rust does not require the use of such footguns for basic string manipulation.
- steveklabnik 10y agoA panic _may_ call destructors, but it cannot be relied upon. For example, aborting is a perfectly reasonable panic implementation, and your destructors won't get called. If you have unwinding panics, they will call destructors though.
- Manishearth 10y agoI mean, in case of an abort the kernel generally cleans things up for you :) Not all things, but most things. More exotic panics (like an infinite loop panic on a microcontroller) would not call destructors though. Most panic impls will either unwind (which will call destructors) or abort/exit, so this is usually not a problem.
- steveklabnik 10y agoMemory will get cleaned up, but your destructors aren't gonna get called.
- jstewartmobile 10y agoI'm speaking mostly in terms of recoverable errors where it jumps to a logging section, carries on, but leaks memory.
- Manishearth 10y agoYou'd generally use Result<T> for recoverable errors (which won't have any destructor issues), but in some cases you might put a panic::recover at the event loop level (never seen this being done before, but I can imagine it happening) which catches the panic (only calling destructors up to the catch point -- this is done by the unwind mechanism) and moving on to the next event in the loop.