Another related suggestion : The current package doesn't have "BuildRequires:
alsa-lib-devel", thus the ALSA driver isn't enabled when rebuilding in a minimal
root (the OSS driver is) :

Old Rate enabled..................   no
Fast ulaw enabled.................   yes
Fast alaw enabled.................   yes
GSM Support.......................   yes
ALSA Driver.......................   no
OSS Driver........................   yes
SUN /dev/audio....................   no
Ogg Vorbis support................   yes
MAD MP3 Decoder...................   no
LAME MP3 Encoder..................   no

It should probably be added.

thanks dude

REOPENING due to gcc detecting a buffer overflow.  Matthias, could you please
fix this, test it in runtime and submit a patch?

/mnt/redhat/beehive/logs/sox-555945-i386-decompose.build.redhat.com.log:smp.c:133:
warning: call to __builtin___strcpy_chk will always overflow destination buffer

<arjan>         char name[10];          /* Ascii Marker name */
<arjan>         uint32_t position;      /* Sample Number, not byte number */
<arjan> };
<arjan>         for(i = 0; i < 8; i++) {        /* write the 8 markers */
<arjan>                 strcpy(trailer->markers[i].name, "          ");
<arjan>                 trailer->markers[i].position = ~0;
<arjan>         }
<arjan> so the strcpy writes 11 bytes in a 10 byte array
<warren> arjan, will that struct automatically add padding for alignment or
it'll overwrite the uint32_t?
<arjan> hmm not sure; probably pads
<arjan> still it's broken code
<warren> yup
<warren> arjan, old version had the same problem
<arjan> still this code shouldn't be allowed to live.
<arjan> (and fwiw gcc has turned the strcpy() into an abort() )

I've sent an email to the current sox maintainer to ask for a quick patch to
solve this problem.

About the other changes : The ALSA detection seems to use the kernel headers,
and not alsa-lib-devel... so I'm not sure what should be done here. Is this a
bug, and applications should only use alsa-lib? Should kernel-devel be added to
the build requirements? I don't even think this last solution would be correct,
as the build seems to look for the kernel headers for the running kernel (which
may fail in a build root with a different kernel package installed).

Created attachment 113660 [details]
SMP overrun fix

I'm upstream developer of SoX.	I'm out of the country for a couple of weeks
but here is how I will fix it when I have time.  Feel free to apply the patch
if your in hurry (ie. core 4).

I'm interested in feedback on ALSA drivers in Fedora/Redhat.  The original
author of the ALSA driver in SoX doesn't like the alsa-lib's since for most
usages they are no more then thin wrapper around kernel headers.

I'm pretty neutral on how to access ALSA drivers.  Up until Fedora starting
including ALSA, it wasn't important to me. :-)

Now that I use ALSA drivers, I've been adding patches to improve its quality in
SoX (see SoX 12.17.7 Changelog).  

The whole topic of using ALSA kernel headers seems to be murky... Plus there is
the major issue with ALSA's kernel headers using __user and __kernel macro's but
the standard "linux/compiler.h" header doesn't yet include those #defines (or
will it ever?).

Fedora may wish to make a policy that ALSA drivers are only turned on in
applications if they use alsa-lib.

The patch in Comment #5 is applied to FC4.  So closing this bug.

Great, thanks Warren.
Chris : You're right, as I really think the proper way to detect and use ALSA
would be by using alsa-lib. With the current detection, when I rebuilt sox in a
chroot where only a Fedora Core Development kernel is present, the sox configure
script can't find the kernel headers for the `uname -r` kernel, since it's the
older one from the main host machine. So I'd say go ahead and try to switch to
something cleaner for the next sox release ;-)

Now that I think about it, I agree that alsa-lib should be used whenever
possible.  Userspace apps should avoid kernel interfaces whenever possible, and
alsa-lib is the designated abstraction.