Re: SoX & pipe rewinding

[Rich Felker <dalias@aerifal.cx>]

On Fri, Dec 14, 2012 at 05:51:40PM +0400, ojab wrote:
> On 14.12.2012 17:40, Rich Felker wrote:
> >On Fri, Dec 14, 2012 at 05:35:52PM +0400, ojab wrote:
> >>>Hi list,
> >>>SoX use some kind of hackery for pipe rewinding (see the attached
> >>>file). So I have two questions:
> >>>1. If something like that possible using musl?
> >>>2. Is there any musl specific #define?
> >I don't believe so. Not only does this hack depend on knowing the
> >internals of FILE (which are intentionally opaque on musl); it also
> >depends on the assumption that the data is still present in the buffer
> >after it's consumed, which is invalid in general.
> >
> >No idea why programmers insist on doing stuff like this rather than
> >fixing their design issues...
> >
> >Rich
> >
> 
> It's completely optional (check the #else part), so question is (2):
> How we can check for musl and disable pipe rewinding in this case.
> If there is no musl-specific define, and there is intention not to
> add one — I'll file a bug in SoX tracker with request to remove an
> #error.

There's intentionally no musl-specific #define. Some people have
complained about that, but if there had been one, the state of musl
compatibility would be a ton worse right now, because lots of software
would be crippling itself by using #ifdef __musl__ or similar to
disable features that musl 0.6.x didn't have...

The right solution to using optional features is to test for their
existence, but in this case, sox is not using an extension feature but
poking at the internals of some known implementations and throwing
#error for everything else. This is just really bad behavior. The
default case should be portable, i.e. should just silently omit the
non-portable pipe rewinding code.

Rich