mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rob Landley <rob@landley.net>
To: musl@lists.openwall.com
Cc: musl@lists.openwall.com
Subject: Re: SoX & pipe rewinding
Date: Fri, 14 Dec 2012 16:17:34 -0600	[thread overview]
Message-ID: <1355523454.18402.8@driftwood> (raw)
In-Reply-To: <20121214134009.GJ20323@brightrain.aerifal.cx> (from dalias@aerifal.cx on Fri Dec 14 07:40:09 2012)

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


  parent reply	other threads:[~2012-12-14 22:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-14 13:35 ojab
2012-12-14 13:40 ` Rich Felker
2012-12-14 13:51   ` ojab
2012-12-14 16:47     ` John Spencer
2012-12-14 17:57       ` ojab
2012-12-14 19:09     ` Rich Felker
2012-12-14 21:11       ` ojab
2012-12-14 21:21         ` Rich Felker
2012-12-14 22:17   ` Rob Landley [this message]
2012-12-15  0:05     ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1355523454.18402.8@driftwood \
    --to=rob@landley.net \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).