Page 10 of 10 FirstFirst ... 8910
Results 91 to 99 of 99

Thread: How NOT to write a shared library

  1. #91
    Join Date
    Jun 2006
    Location
    CT, USA
    Beans
    5,267
    Distro
    Ubuntu 6.10 Edgy

    Re: How NOT to write a shared library

    Quote Originally Posted by samjh View Post
    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.

  2. #92
    Join Date
    Feb 2007
    Beans
    236

    Re: How NOT to write a shared library

    Quote Originally Posted by NutMonkey View Post
    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.
    Last edited by j_g; November 19th, 2007 at 05:10 AM.

  3. #93
    Join Date
    Oct 2006
    Location
    Austin, Texas
    Beans
    2,712
    Distro
    Ubuntu 7.10 Gutsy Gibbon

    Re: How NOT to write a shared library

    Quote Originally Posted by NutMonkey View Post
    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.

    Quote Originally Posted by NutMonkey View Post
    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?

    Quote Originally Posted by NutMonkey View Post
    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.

  4. #94
    Join Date
    Feb 2007
    Beans
    236

    Re: How NOT to write a shared library

    Quote Originally Posted by pmasiar View Post
    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).
    Last edited by j_g; November 19th, 2007 at 05:21 AM.

  5. #95
    Join Date
    Jan 2005
    Beans
    33

    Re: How NOT to write a shared library


  6. #96
    Join Date
    Feb 2007
    Beans
    236

    Re: How NOT to write a shared library

    That URL above was already posted, and debunked.

  7. #97
    Join Date
    May 2007
    Location
    Basildon, England
    Beans
    338
    Distro
    Ubuntu 12.04 Precise Pangolin

    Re: How NOT to write a shared library

    Quote Originally Posted by j_g View Post

    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.
    Mick 'n Keef rock, Chas beats time and Ronnie is the new boy
    Registered as user 466848 with the Linux Counter. Registered Ubuntu User 22858. Our company website or our new venture

  8. #98
    Join Date
    May 2007
    Location
    Basildon, England
    Beans
    338
    Distro
    Ubuntu 12.04 Precise Pangolin

    Re: How NOT to write a shared library

    Quote Originally Posted by pmasiar View Post
    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!
    Last edited by SteveHillier; November 19th, 2007 at 10:54 AM. Reason: missing words
    Mick 'n Keef rock, Chas beats time and Ronnie is the new boy
    Registered as user 466848 with the Linux Counter. Registered Ubuntu User 22858. Our company website or our new venture

  9. #99
    Join Date
    Sep 2006
    Location
    France.
    Beans
    Hidden!
    Distro
    Lubuntu 14.04 Trusty Tahr

    Re: How NOT to write a shared library

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

    Edit: reopened.
    Last edited by bapoumba; November 21st, 2007 at 07:37 PM.

Page 10 of 10 FirstFirst ... 8910

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •