Zeuthen: Writing a C library, part 1

Posted Jun 28, 2011 13:32 UTC (Tue) by nix (subscriber, #2304)
In reply to: Zeuthen: Writing a C library, part 1 by wahern
Parent article: Zeuthen: Writing a C library, part 1

Not least because you can't tell where that library might be used. X.org had to discourage use of its (IIRC) dbus support because that library's behaviour on so many errors is to abort, and when your X server aborts that might leave you with a dead display or a locked-up PCI bus.

The rule I follow is simply that libraries should never ever abort, period, except perhaps in a limited number of functions whose documented purpose is to terminate the process. Yes, it means you have to actually bother with a bit of error handling. That's the least you can expect from a half-competent C programmer, I'd say.

Zeuthen: Writing a C library, part 1

Posted Jun 30, 2011 14:08 UTC (Thu) by stevem (subscriber, #1512) [Link]

Absolutely. 100%.

A library should *never* call abort in an attempt at error-handling. You throw away any chance for the calling code to do sensible stuff such as clean up properly.

Zeuthen: Writing a C library, part 1

Posted Jun 30, 2011 15:19 UTC (Thu) by nix (subscriber, #2304) [Link] (2 responses)

And I see David has linked to this comment with the link text 'people sometimes fail to realize that the caller has a responsibility'. I might respond that people sometimes fail to realize that libraries have a responsibility not to shoot the whole process in the head when the caller could perfectly well recover.

(Ironically, elsewhere in the same post David comments that libraries should not manipulate signal dispositions because these are process-wide state. I'd call the continued existence of a process process-wide state, as well, but apparently David disagrees. I think his attitude leads to appalling and unnecessary instability: he thinks mine leads to unfixed bugs in callers. We are probably both right, but ne'er the twain shall meet.)

Zeuthen: Writing a C library, part 1

Posted Jun 30, 2011 17:49 UTC (Thu) by davidz2525 (guest, #58065) [Link] (1 responses)

I think I even prefaced the word 'people' with 'smart' :-). But, yeah, I completely agree that we're both right which is why the guidance is to establish a policy on what to do when the programmer screws up rather than doing either A or B. I brought this up mostly to address the popular misconception that libdbus-1 is an evil library that eats babies - it's not.

(Btw, another misconception is that libdbus-1 is meant for applications to use; it's really not, it's more intended for a base that you can build language/toolkit bindings on top + the implementation used to implement dbus-daemon(1) which MUST be able to handle OOM.)

Zeuthen: Writing a C library, part 1

Posted Jun 30, 2011 21:12 UTC (Thu) by nix (subscriber, #2304) [Link]

If it's a base that you can build language bindings on top of, then the libdbus-1 authors have even *less* idea than they might have as to what the process is doing, and it's even more critical that it should never die. (But it is true that a lot of Great Big Languages have no hope of handling OOM errors: dynamic allocation is too fundamental to them. However, for others this same property is a benefit, because they often have a lot of dynamically-allocated storage that they can get rid of, and even their own allocators so they can be sure the storage finds its way back to the OS again.)

Damn good articles btw.

Zeuthen: Writing a C library, part 1

Posted Jul 1, 2011 5:28 UTC (Fri) by whot (subscriber, #50317) [Link] (1 responses)

FTR, we discouraged dbus support mostly because the communication API was less than ideal and just talking directly to hal (now udev) was more sensible.

The abort() was extremely annoying while programming but it also lead to the code being very stable. Every small error got punished badly so we had to make sure we fixed up the code properly.

Zeuthen: Writing a C library, part 1

Posted Jul 1, 2011 9:37 UTC (Fri) by nix (subscriber, #2304) [Link]

OK, so my memory was faulty :) not much of a surprise there, some days it seems it consists mostly of faults.