From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: Re: Priorities for next release?
Date: Sat, 11 Aug 2012 16:51:28 -0400 [thread overview]
Message-ID: <20120811205128.GL27715@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAPLrYETZUKEN_0ej_H7c24V_xdGNqWQNoCRqg4s3BU8oMJ+F5g@mail.gmail.com>
On Sat, Aug 11, 2012 at 10:26:35PM +0200, Daniel Cegiełka wrote:
> > Did I miss anything? Other additions to the wishlist for next release?
>
> Support for the man pages? This can be simple dir in musl
> (man/man{1,2,...) and "--with-man" option in configure.
Hm? Adding man pages for every interface would be a huge task, well
outside of "finishing touches for the next release". :-) I'd actually
like to find someone interested in writing detailed documentation
(there was a thread about this a while back), but I'm not sure man
pages are the best format; the POSIX man pages suffice as programmers'
documentation for most of the interfaces in musl.
> I'm sending fgetln.c (+my diff), but please check it...
> btw. it based on /usr.bin/make/util.c from OpenBSD:
If we add fgetln, I'd like a much higher quality of implementation.
It's not clear from the past documentation I've read for this function
that it's allowed to use a shared static buffer for all FILEs, and
even if it were, I find that really ugly. Instead, simply returning a
pointer into the FILE's buffer when the whole line is already present
in the buffer, and otherwise allocating a FILE-local buffer for it,
would be a lot nicer. fclose could then check the FILE-local pointer
and free if it it was allocated.
I was under the impression that this was how legacy BSD fgetln worked
in the first place...
Rich
P.S. Just noticed another thing: K&R function arguments are not valid
C99 or C11 and are not okay in musl.
next prev parent reply other threads:[~2012-08-11 20:51 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-10 19:12 Rich Felker
2012-08-10 19:23 ` Nathan McSween
2012-08-10 19:39 ` Unit/regression testing (was Re: [musl] Priorities for next release?) Rich Felker
2012-08-10 22:03 ` Priorities for next release? Luca Barbato
2012-08-11 0:05 ` Rich Felker
2012-08-11 0:54 ` Luca Barbato
2012-08-11 1:07 ` Rich Felker
2012-08-11 2:21 ` idunham
2012-08-11 2:36 ` Rich Felker
2012-08-11 12:21 ` Daniel Cegiełka
2012-08-11 12:27 ` Rich Felker
2012-08-11 12:35 ` Daniel Cegiełka
2012-08-11 16:09 ` Rich Felker
2012-08-11 16:35 ` Daniel Cegiełka
2012-08-11 16:50 ` Rich Felker
2012-08-11 17:55 ` orc
2012-08-11 18:41 ` Daniel Cegiełka
2012-08-11 18:47 ` orc
2012-08-11 19:05 ` Daniel Cegiełka
2012-08-11 19:28 ` Rich Felker
2012-08-11 19:56 ` Rich Felker
2012-08-11 20:26 ` Daniel Cegiełka
2012-08-11 20:51 ` Rich Felker [this message]
2012-08-11 20:56 ` Rich Felker
2012-08-11 21:22 ` Rich Felker
2012-08-12 12:52 ` Daniel Cegiełka
2012-08-11 22:25 ` Rich Felker
2012-08-12 12:40 ` Szabolcs Nagy
2012-08-13 8:40 ` Luca Barbato
2012-08-13 13:41 ` Rich Felker
2012-08-13 15:49 ` Szabolcs Nagy
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=20120811205128.GL27715@brightrain.aerifal.cx \
--to=dalias@aerifal.cx \
--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).