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.