[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 14 Dec 2012 19:05:02 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: SoX & pipe rewinding
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
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.
