Subject: bug#40832: alsa-lib cannot find its plugins

From: Danny Milosavljevic <[email-masked]>
Date: Tue, 28 Jul 2020 12:52:41 +0200

Hi Leo,

some comments on the lastest patch:

* The entire alsa-lib seems to use the idiom "malloc and then strcpy", or
"malloc and then sprintf", or, worse, "malloc, strcpy and multiple strcat".
These are a buffer overflow waiting to happen (when changing part of those
while doing ongoing maintenance;  also the places where they use "+" is not
checked for overflow).  That said, if they do it, we can do it that way, too.
* The environment variable GUIX_ALSA_PLUGIN_DIRS is only checked if the
respective file does not exist in alsa-lib.  That is not how environment
variables usually work--it should be possible to override built-in things
by setting this environment variable, too.
* Instead of alloca and strcpy, can just use strdupa.
* strtok_r man page states that the first argument should be NULL on the
non-first calls.  You do that already, but maybe add a comment why that
is done where it's set to NULL.
* strtok_r man page states that "On some implementations, *saveptr is required
to be NULL on  the first call to strtok_r() that is being used to parse str.".
So I'd use "char* saveptr = NULL;"
* Instead of malloc and sprintf, could just use asprintf.  But they don't,
so let's not either, for easier review.  Also, magical value 32... sigh.
Well, they do it, too.
* If GUIX_ALSA_PLUGIN_DIRS contained for example "a:" then it would search
"a" and "/", right?  OK as long as we want that.

Otherwise LGTM!