[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 14 Dec 2012 16:17:34 -0600
From: Rob Landley <rob@...dley.net>
To: musl@...ts.openwall.com
Cc: musl@...ts.openwall.com
Subject: Re: SoX & pipe rewinding
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.
> > 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.
> 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.
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.
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.)
Rob
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.
