From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2485 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: SoX & pipe rewinding Date: Fri, 14 Dec 2012 16:21:22 -0500 Message-ID: <20121214212121.GO20323@brightrain.aerifal.cx> References: <50CB2B38.8070703@ojab.ru> <20121214134009.GJ20323@brightrain.aerifal.cx> <50CB2EEC.2040909@ojab.ru> <20121214190924.GM20323@brightrain.aerifal.cx> <50CB95FA.8030109@ojab.ru> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1355520097 17357 80.91.229.3 (14 Dec 2012 21:21:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Dec 2012 21:21:37 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2486-gllmg-musl=m.gmane.org@lists.openwall.com Fri Dec 14 22:21:47 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1TjchX-0008C8-7Z for gllmg-musl@plane.gmane.org; Fri, 14 Dec 2012 22:21:47 +0100 Original-Received: (qmail 25727 invoked by uid 550); 14 Dec 2012 21:21:34 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 25719 invoked from network); 14 Dec 2012 21:21:34 -0000 Content-Disposition: inline In-Reply-To: <50CB95FA.8030109@ojab.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2485 Archived-At: 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