[<prev] [next>] [day] [month] [year] [list]
Date: Mon, 18 Jun 2012 19:03:13 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: stdio "ext2" functions
Hi all,
Here's a proposed "ext2.c" (no relation to the filesystem) containing
the 4 functions to make gnulib work without having to poke at
internals. It's pretty close to the version Bruno sent, even though I
just wrote it off the top of my head, since there's pretty much only
one way to write these functions. My versions might be a few bytes
smaller.
I know a few ppl have been pretty opposed to adding these functions,
but here's my logic:
1. We already discussed and decided to add __freadahead.
2. Each of the remaining 3 functions should be possible to implement
on any stdio implementation that actually uses userspace buffers, and
in a worst-case, __freadptr (and __freadptrinc) could be dummied
(always return NULL and force the caller to use standard functions)
without breaking anything. Therefore, committing to provide these
functions permanently as part of musl does not lock us into the
current implementation or prevent making internal changes.
3. Unless somebody wants to wage a publicity war against the gnulib
folks, not-implementing these functions is not going to keep things
clean on the gnulib side. It's just going to result in gnulib adding
musl-specific hacks that will be fragile and cause musl users no end
of grief.
4. Adding 54 bytes of code with minimal maintenance cost, even if it's
ideologically ugly code, puts us on the high ground in terms of being
reasonable and compromising. I don't believe this puts us in a
position of being subject to more and more irrational demands from the
gnulib ppl. I think it puts us in the opposite position: we've already
proven our willingness to work with projects, even distasteful ones,
when it's in the best interest of users. If/when they go trying to
hard-code soon-to-be-outdated knowledge about musl into gnulib and
breaking things, users/history will will them as the ones who screwed
up.
Comments are welcome, but I'd like to avoid a bikeshed discussion of
whether or not to do this unless you have real viable alternatives.
Rich
View attachment "ext2.c" of type "text/plain" (338 bytes)
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.
