All the Perl that's Practical to Extract and Report
use Perl Log In
ethan (3163)
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.
dubious quality of GNU source-code
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.
an endless discussion thread about what features to include.
-- Jarkko Hietaniemi
free() ain't free (Score:3, Informative)
Perhaps your module should just wrap system("locate") instead of reinventing this wheel.
-sam
Reply to This
Re:free() ain't free (Score:2, Insightful)
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
Re:free() ain't free (Score:3, Insightful)
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.
Re:free() ain't free (Score:3, Interesting)
I might come to the conclusion that there has been no such considerate decision.
Another idea (Score:3, Interesting)
Just a thought.
Reply to This
Re:Another idea (Score:1)
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