How NOT to write a shared library

[pmasiar]

While I don't agree with j_g's tone, the principle of his pointing out the ill-practice is not to be derided. He just managed to frame a valid criticism in a not-so-constructive way (shooting people? come on now).

Effort is judged by the result.

If post does not persuade readers to do what writer suggests them to do, it can be hardly a success.

I agree wholeheartedly with the goal of making free software more stable and usable. Shooting developers, even figuratively, is not a good way to get there, IMHO. So OP need to make some thinking what exactly he wants to accomplish, and how.

[j_g]

In a real-world situation where you were out of memory, malloc() will not actually return a 0.

I've seen this allegation made numerous times. But it isn't true. We've already seen actual examples of malloc returning a zero, running on actual computers. If your allegation were true, that wouldn't be possible.

If you're allocating 1GB at a time you have bigger problems than malloc checking.

Such as what? Swapping to disk? Memory fragmentation? Not a problem as long as it doesn't cause a process to up and vanish without the enduser being given recourse to try and reclaim free memory in whatever way he deems preferable (ie, closing down unneeded windows, choosing which apps to terminate, unplugging external devices to see if that frees up RAM, stopping unneeded services... um, daemons... to see if that frees RAM etc), nor cause loss of the enduser's work -- you know, like exit() does (or just ignoring the 0 return value, and pretending it isn't 0 -- which ultimately makes the OS do to your app what exit() does).

To those folks who are still arguing that it's "pointless" to attempt to recover from a malloc failure gracefully because Linux somehow or other makes that impossible, this is both wrong, and a disservice to poor endusers who may be stuck using your software. Don't do it. Just... don't. I don't care if other Linux programmers do it already. Just... don't.

[Wybiral]

I'd like to point out that the g_malloc() function in GLib also exits. Where do we fill out the bug report to get glib and everything that uses it removed from Ubuntu, for stability reasons?

You have a point... I guess if everyone else writes unstable code we should jump the bandwagon and join in. [/sarcasm] GLib is a nice library, but that doesn't mean the programmers are Godlike and that you should base all of your work on theirs.

Handling malloc() errors gracefully sounds good, but has little practical value. In a real-world situation where you were out of memory, malloc() will not actually return a 0.

Do you have any examples of this?

And if it did, there's not much you could do about it.

You can let the library user decide what to do with the issue.

[j_g]

Shooting developers, even figuratively, is not a good way to get there

How many developers have you "figuratively shot" to test your theory? Or is this yet another attempt to derail a legitimate programming thread with more off-topic posts, just to "bury" others' Linux programming discussion with noise (because you think that those statements don't portray Linux in the best possible light, and you don't want anyone else to hear them, since you can't/haven't directly responded to the specific thread topic with a convincing counterargument)?

I thought so.

If post does not persuade readers to do what writer suggests them to do, it can be hardly a success.

This thread is not about whether anyone actually uses advice from this forum, nor how successful nor unsuccessful particular attempts to offer advice are.

this thread was always a little rant about how FOSS sucks

Wrong again. This thread was (and still would be if you didn't keep bringing it off-topic) "why bad error handling sucks" -- in particular how bad it is to just fall upon your sword by calling exit() when malloc returns 0, instead of trying to gracefully recover from it -- especially when you do the former in a shared lib that a number of other apps use. That's what it's about (for about the third time. Geez).

Another, less important point, was also about why so many programmers seem to be exposing "wrappers" for malloc in their shared libs. It didn't occur to me, upon reading initial replies to this, that people mistakenly thought I meant, "why put the call to malloc in its own function that also does error handling?". (I should have used the word "exposing", in lieu of "offering", in the initial question. That probably would have cleared some misunderstanding). What I meant was, why expose such a function to apps? For example, pa_xalloc() is documented as part of the Pulse Audio API. I presume that the Pulse Audio author therefore intends for apps to call this too (although I strongly do not recommend this). All pa_xmalloc is, is a (bad) wrapper around malloc. And I've seen the same thing in too many other shared libs (well with Linux anyway. Off the top of my head, I can't remember seeing some Win32 lib code that exposed just a simple wrapper around malloc, GlobalAlloc, or VirtualAlloc. So yes, it's a Linux programming problem that I'm seeing. That's not because I'm "attacking Linux". It's just that this appears to be mostly isolated to Linux. But to the extent it appears anywhere, it's a bad thing). Does a programmer who does this think that (other, app) programmers (who would use his shared lib) are so absent-minded they can't remember malloc is used to allocate memory, so programmers need every shared lib they use to have its own version of malloc in it? That's what I meant. I'm tired of seeing shared libs exposing essentially their own (bad, if it calls exit) version of malloc. malloc is in the C library. That's enough. (Oh, and the same thing with free() -- ie, pa_xfree).

It was those above two points I made, both pertinent to shared libs (using a shared lib example I found to illustrate the points -- the thread wasn't even about Pulse Audio, and surely not Pulse Audio bug reporting) that this thread was/is about, and so why I called it "How NOT to write a shared library.

It doesn't matter if the shared lib is open source or closed source (so your attempt to cause noise by arguing with your own straw man about this being "an attack on FOSS" is now officially exposed and debunked).

If you're calling malloc, check for a 0 return value, and try to recover gracefully. Do it. Especially do it in a shared lib.

I've told you several times what this thread is about. Yet you continue to maintain it's about something else. Perhaps you should stop reading the thread if you can't figure out what it's about. Or, at least stop posting in it. Thanks (in hopeful anticipation that you'll take my advice. Riiiiight).

[nzjrs]

http://www.pulseaudio.org/ticket/158

[j_g]

That URL above was already posted, and debunked.

[SteveHillier]

I tell you. We've got to get computer science courses to teach error handling. Some graduates appear not to know what it entails. .

It is not that I disagree with the comment but it is a thorny problem. I can remember writing code for PC in an IBM MVS -> PC comms package. The problem there was that the mainframe host would give you error codes that conceptually did not exist in a PC. Messages like 'Unexpected Error Occurred' are not helpful to the user or even the developer but then neither is morphing that error message to its nearest lookalike.
I am sure that situations like these occur every time you go cross platform (take the example of Linux v Windows file permissions).
My examples of course should actually highlight the comment in the quote. Developers need to know what it entails otherwise you get a lot of c..p code being written.
Good on you j_g for raising this issue.

[SteveHillier]

I know projects where top developer creates code, with request to someone chime in and write basic docs. And someone does, and community of experts double-check it and make sure it is correct. This creates a way for top developers not to waste time on writing docs, and less expert people to contribute.

And without shooting anyone

and what happens? something gets lost in the translation. Someone once told me they saw a comment in some code that read "When this code was written only God the the programmer knew what it did. Now only God knows!!"
If you did it you should document it!

[bapoumba]

This thread got reported _again_. Temp closing for Staff review.

Edit: reopened.