Or You Could Simplify The Error-Recovery Paths

Posted Dec 29, 2014 19:23 UTC (Mon) by cesarb (subscriber, #6266)
In reply to: Or You Could Simplify The Error-Recovery Paths by rleigh
Parent article: The "too small to fail" memory-allocation rule

> Unless you really want to suffer with C, you can just have it all handled if you use the facilities C++ offers you.

If you are willing to use GNU extensions, you can have it on C too via __attribute__((__cleanup__(...))). One well-known project which uses it is systemd.

But I agree that it's not going to be acceptable in the kernel, since it introduces implicit calls to the cleanup functions, and kernel developers prefer to be explicit.

Or You Could Simplify The Error-Recovery Paths

Posted Dec 29, 2014 23:11 UTC (Mon) by rleigh (guest, #14622) [Link] (2 responses)

This is certainly a partial solution for C. It's akin to a shared_ptr custom deleter. It's not really a great alternative to C++ destructors, because the cleanup still needs specifying by hand for each type instance and it's not really encapsulated as well since the cleanup function is either local to the translation unit or effectively public without additional measures, but it's probably the best you're going to get out of C. If you're going this far into the nonportable and nonstandard with C, I'd argue you'd be better off using standard and portable C++.

Or You Could Simplify The Error-Recovery Paths

Posted Dec 30, 2014 23:28 UTC (Tue) by cesarb (subscriber, #6266) [Link] (1 responses)

Wouldn't it be more like a unique_ptr custom deleter instead of a shared_ptr custom deleter?

Or You Could Simplify The Error-Recovery Paths

Posted Dec 31, 2014 11:17 UTC (Wed) by rleigh (guest, #14622) [Link]

Yes, either works for the example above (I originally wrote it to use shared_ptr but updated the example to use unique_ptr).