From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2487 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 19:05:02 -0500 Message-ID: <20121215000502.GP20323@brightrain.aerifal.cx> References: <20121214134009.GJ20323@brightrain.aerifal.cx> <1355523454.18402.8@driftwood> 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 1355529920 32170 80.91.229.3 (15 Dec 2012 00:05:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 15 Dec 2012 00:05:20 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2488-gllmg-musl=m.gmane.org@lists.openwall.com Sat Dec 15 01:05:35 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 1TjfFw-0007sh-B6 for gllmg-musl@plane.gmane.org; Sat, 15 Dec 2012 01:05:28 +0100 Original-Received: (qmail 3884 invoked by uid 550); 15 Dec 2012 00:05:15 -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 3873 invoked from network); 15 Dec 2012 00:05:15 -0000 Content-Disposition: inline In-Reply-To: <1355523454.18402.8@driftwood> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2487 Archived-At: On Fri, Dec 14, 2012 at 04:17:34PM -0600, Rob Landley wrote: > On 12/14/2012 07:40:09 AM, 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? > > Create a wrapper FILE object that passes through most operations but > copies incoming data to a ring buffer you can re-read previous data > out of. You can create your own IO buffering layer in place of stdio, yes. Or you can use 2 FILE objects stacked with a pipe and threads between them. Or you can use a temp FILE and swap back to the real one once the temp one runs out of data. > >> 2. Is there any musl specific #define? > > > >I don't believe so. > > Which is annoying. > > Imagine an OS kernel that refused to identify itself because its > author didn't want software knowing it was running on it. Because > it's PERFECT and knows it's perfect sight unseen, and thus nobody > out in the world should ever need to work around its perfection, and > anyone who uses it is _required_ not to. It's not because it's perfect. It's because the only valid way to know whether a particular extension or bug exists is to TEST for it. Note that applications and modules which tweaked their behavior based on kernel version numbers are also horribly broken because some distros have kernels with fixes and features backported. The idiom of: if (version == X) assume_feature_i_once_observed_on_version_X; is just fundamentally broken. Testing is the only valid approach to answering the question of whether a feature is present -- either testing compiling/linking to it, or testing for a macro that indicates the presence of a specific feature (like the _POSIX_THREADS macro does) rather than a whole library version. > >No idea why programmers insist on doing stuff like this rather than > >fixing their design issues... > > It's such a crazy thing to want to do that both posix and ISO C > standardize an ungetc() function. If you see my followup email, I explained how the effect could be achieved, on some systems under some conditions, via ungetc. > Other programmers don't write code the way you would write it. And > when you try to force them, you make the result even uglier. I don't try to force them. All I do is ensure that musl remains unconstrained to innovate by improving the underlying implementation of things, unlike glibc which is tied down to all the legacy implementation choices they made. > For example, if a program really wants to know whether or not it's > running against musl right now, a dynamically linked program can do > something like "strings /proc/self/exe | grep ld-musl", and just > refuse to work staticaly linked. (Yes, this is utterly horrible, but > if you refuse to have an #define people can check I just about > guarantee you somebody will do this sooner or later. Or worse.) Of course apps can do this. And their authors will be the ones who look like fools in the court of public opinion. I have explained thoroughly the reasoning behind these issues, and every time it's come up, my position has been demonstrated _empirically_ right as well (i.e. the thing somebody was trying to do using #ifdef __musl__ was obsolete within a month or two and would have _broken_ building with newer versions). Many times it's also just led to musl adopting extension interfaces that were not difficult to add and which served to avoid ugly hacks (e.g. stdio/ext2.c). Actually this functionality (rewinding buffer) is something I feel similar about. I would have no big objection to providing a "rewind in buffer, reporting success for failure, subject to the limitation that whether or not the data is still there is unspecified" function in musl, which applications could test for and use, if there were a big demand for this functionality. What is not acceptable is locking in the layout of the FILE structure any more than it's already constrained, or locking in the constraint that the implementation can't discard buffer contents that have already been read. Rich