[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 14 Dec 2012 16:21:22 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: SoX & pipe rewinding
On Sat, Dec 15, 2012 at 01:11:22AM +0400, ojab wrote:
> On 14.12.2012 23:09, Rich Felker wrote:
> >On Fri, Dec 14, 2012 at 05:51:40PM +0400, ojab wrote:
> >
> >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.
>
> Filled https://sourceforge.net/tracker/?func=detail&aid=3596097&group_id=10706&atid=110706
Thanks. It might be nice to also add a link to this thread, which
makes it clear that our position is that the layout of the FILE
structure and the buffering behavior of musl's stdio are both
considered opaque to applications; hacks to detect musl and poke at
the current version of the internals, which possible, would not
necessarily be compatible with future versions of musl, i.e. it would
result in a binary that might break/crash horribly when libc.so is
upgraded.
BTW, there is one 100% safe way to _attempt_ rewinding a pipe:
repeatedly call ungetc() for each character you read. The C standard
does not guarantee more than 1 byte of pushback, but most
implementations allow more under most circumstances, and the C
standard does require that the implementation report the success or
failure of ungetc() to push back a byte. This approach would always
work with the current stdio implementation in musl, and if any
internal changes prevented it from working in the future, the
application would at least see the failure (in the form of a failure
return from ungetc()) and would be able to react appropriately rather
than crashing due to corrupted internal stdio state. However, to use
this approach, I think the sox rewind-pipe function would have to be
improved to take a pointer to the header block that was read for
probing purposes, so that it could push-back these bytes one at a
time.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
