Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

ethan (3163)

ethan
  reversethis-{ed. ... rap.nov.olissat}

Being a 25-year old chap living in the western-most town of Germany. Stuying communication and information science and being a huge fan of XS-related things.

Journal of ethan (3163)

Tuesday May 27, 2003
11:55 AM

dubious quality of GNU source-code

[ #12459 ]

Yesterday within half an hour I hacked together C that will soon hit the CPAN. I simply put all the relevant C-functions from the findutils-package and butchered them into Locate.xs, massaged the whole thing a little to return the data to the caller and that was it essentially.

However, one thing is odd. There is not a single call to C within locate.c and related C files. So it allocates all the memory for the strings it extracts from the locate-db files (more than 12meg for a search for 'mp3' on my computer) but never frees them, benefiting from the fact that locate(2L) is shut-down afterwards anyway. Naturally, when turning that into a module, memory must be cleaned up properly and this turns out to be not that easy. It uses statically allocated memory at some places and my attempts to replace that with dynamic memory allocation have resulted in segfaults so far. Strange. I always though that it would be good style to always release the memory one allocated no matter whether this is necessary in a narrower sense.

Other than that, the style of the code is pretty ancient. It still uses K&R function-declaration style for instance and some other baddies and anachronisms.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • free() ain't free (Score:3, Informative)

    by samtregar (2699) on 2003.05.27 12:14 (#20544) Homepage Journal
    Calling free() takes time. Perl itself declines to actually free() allocated memory at program destruction as an optimization. Maybe it's your knowledge of C which is of dubious quality!

    Perhaps your module should just wrap system("locate") instead of reinventing this wheel.

    -sam

    • Calling free() takes time. Perl itself declines to actually free() allocated memory at program destruction as an optimization.

      And you think that this analogy makes any sense? Perl has different destruct_levels that do different things depending on whether perl was compiled with multiplicity or not. We are talking here about a potentially threading application where not freeing memory can be a valid decision.

      You can't apply that to locate. You run it once and it quits. When you start it again, the not-fr
      • You can't apply that to locate. You run it once and it quits.

        Sure I can. Why would I want to wait for all the various free() calls to return before I get my shell prompt back? exit() is much faster! If you're going to call someone's code quality "dubious" then you'll have to consider why they made the decisions they did. If you don't then someone else should point them out to you, like I just did.

        So spawning off a new process using system() or whatsoever is more efficient than a piece of compiled

        • If you're going to call someone's code quality "dubious" then you'll have to consider why they made the decisions they did. If you don't then someone else should point them out to you, like I just did.

          I might come to the conclusion that there has been no such considerate decision. :-) The findutils-4.1 package stills contains a bug that causes segfaults on every run of locate so various patches exist to address this. However, there is no official GNU patch yet. Instead several non-GNU fixes float around m
  • Another idea (Score:3, Interesting)

    by djberg96 (2603) on 2003.05.27 14:59 (#20555) Journal
    Scrap the whole GNU/locate/locate-db/findutils issue entirely. Write your own from scratch. Use SQLite. Do it the way that *you* think it should be done. Worked for me with "whereis" (although I realize the effort for that is nowhere near what it would be for locate).

    Just a thought.

    • Scrap the whole GNU/locate/locate-db/findutils issue entirely. Write your own from scratch. Use SQLite. Do it the way that *you* think it should be done. Worked for me with "whereis" (although I realize the effort for that is nowhere near what it would be for locate).

      Indeed, it'd be more work but with the benefit of making something that is to my own liking.

      Personally, I do like locate a lot and there were a number of reasons why I wanted to stick to it: First of all there was already a codebase in C (I