I just added Packard Bell support to my Digital Jukebox using LIRC.
I'm quite happy with it and the responsiveness of the Packard Bell
remote is much better than advertised.
That said, I have a API style complaint about the client library call
lirc_nextcode(**code). In general, it's bad practice to have library
APIs malloc things that the API user is then responsible for freeing.
There are a number of reasons you don't want to do this:
1. It's non-intuitive, and very un-Unix like. Look at read, readln,
sscanf (and friends). You'll see that most api calls require the api
user to allocate the space for the data.
2. This makes it difficult for applications to manage their own
memory space. For instance, you may be writing a Glib/Gtk program and
you want to exclusively use the g_ routines.
3. Performance. In the case of lirc_nextcode, most of the time the
data is not going to outlive the function scope, and probably won't be
needed past a call to lirc_code2char(). Hence, it makes much more
sense to have an array of chars allocated on the stack for this
- A stack array requires ZERO instructions to allocate or free!!
(There is one instruction to increment the stack, whether you have
local variables or not). A call to malloc can result in a system call.
- Stack data will not fragment memory. Multiple calls to malloc and
free can cause memory fragmentation.
To avoid this, I've written a lirc_read(char *code, size_t n) function.
This function essentially be the same as lirc_nextcode, except that
code points to a valid character array "n" bytes long. lirc_read()
uses the same semantics as strncpy() in that it will never copy more
than "n" bytes (in fact, it just calls strncpy). I've also modified
lirc_code2char() to use a stack allocated array rather than malloc and
free. lirc_nextcode() still mallocs as it used to and then just calls
Finally, I also added a lirc_poll(long timeout) interface. Using
select/poll is far superior to looping non-blocking reads. This is
what the AddInput routines of the X toolkits do as well.
BTW: It should be known that malloc is NOT part of the Axis of evil.
That's based in Redmond.....
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!