GNU bug report logs - #40832
alsa-lib cannot find its plugins

Previous Next

Full log

Message #43 received at 40832 <at> debbugs.gnu.org (full text, mbox):

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: 40832 <at> debbugs.gnu.org
Subject: alsa-lib cannot find its plugins
Date: Tue, 28 Jul 2020 12:52:41 +0200

[Message part 1 (text/plain, inline)]

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!

[Message part 2 (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.