From: Laurent Bercot <ska-dietlibc@skarnet.org>
To: musl@lists.openwall.com
Subject: Re: stdio [de]merits discussion [Re: [musl] possible getopt stderr output changes]
Date: Fri, 12 Dec 2014 00:05:28 +0100 [thread overview]
Message-ID: <548A2338.7000701@skarnet.org> (raw)
In-Reply-To: <20141211175156.GY4574@brightrain.aerifal.cx>
On 11/12/2014 18:51, Rich Felker wrote:
> I like it because in all but the tiniest programs, you end up needing
> this kind of functionality, and whenever somebody rolls their own,
> it's inevitably 10x to 100x larger and uglier than musl's printf core.
You haven't tried skalibs. ;)
(Sure, calling format functions individually is far from being as
convenient, but the resulting code path is much shorter and there's
no bloat.)
I agree we need standards. I just wish the existing standards were
better, and I don't want to be forced to use them.
> Of all that, the only thing contributing non-trivial size is floating
> point support.
Yes, that's the main thing, but it's an important one: in system
programming, floating point operations are uncommon - someone who
cares about code size is probably not using floating points.
> For seekable files, ftello can tell you.
Same thing: system programming is more about pipes and sockets than
seekable files. In applications that write files, the interesting
logic is probably not in the I/O, and they don't care.
> But it's perfectly usable for producing new output in
> cases where all write errors will simply result in failing the whole
> "make a file" operation.
I agree.
> This is solved by fflush before fclose.
I'm surprised that you of all people say this. What if another thread
writes to the FILE between the fflush and the fclose ? Granted, if the
situation arises, it's probably a programming error, but still, since
atomicity is a big thing for FILE, needing 2 operations instead of 1
doesn't scream good design.
> GNU software (gnulib in particular) likes to ignore this problem by poking
> at internals; we gave them an alternate solution with musl a couple
> years back just to avoid this. :(
Jesus. And you still argue that it's a usable interface, if people have
to hack internal implementation details to get a simple readability
notification working ?
> For event-driven models, yes. For threaded models, it's quite usable
> and IMO it simplifies code by a a larger factor than the size it adds,
> in cases where it's sufficient.
"If you can't write asynchronous code, use threads and write synchronous
code." :-Þ
I agree that threads are a good paradigm to have, but the choice of
which model to use should not be dictated by the indigence of available
interfaces.
> The big thing it provides here is a standard point of synchronization
> for error messages in multithreaded programs. Otherwise there would be
> no lock for different library components to agree on to prevent
> interleaved error output.
write() guarantees atomicity up to PIPE_BUF bytes. I have never seen
an stderr error message that was bigger than that.
> Yes and no. There are some things that could have been done better,
> and some backwards-compatible additions that could be made to make it
> a lot more useful, but I think stdio still largely succeeds in freeing
> the programmer from having to spend lots of effort on IO code, for a
> large class of useful programs (certainly not all, though!).
I agree it's good enough for Hello World and applications that just
need very basic I/O. What irks me is that stdio sets a potential barrier
to designing better I/O interfaces, and people who need reliable I/O
management often still contort themselves to use stdio, and the results
are ugly. See the aforementioned gnulib case.
--
Laurent
next prev parent reply other threads:[~2014-12-11 23:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-11 0:10 possible getopt stderr output changes Rich Felker
2014-12-11 3:53 ` Laurent Bercot
2014-12-11 6:44 ` Rich Felker
2014-12-11 15:40 ` Laurent Bercot
2014-12-11 17:51 ` stdio [de]merits discussion [Re: [musl] possible getopt stderr output changes] Rich Felker
2014-12-11 23:05 ` Laurent Bercot [this message]
2014-12-11 23:35 ` Rich Felker
2014-12-12 2:33 ` Morten Welinder
2014-12-11 22:07 ` possible getopt stderr output changes Rich Felker
2014-12-13 0:02 ` Isaac Dunham
2014-12-13 3:11 ` Rich Felker
2014-12-19 21:49 ` 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=548A2338.7000701@skarnet.org \
--to=ska-dietlibc@skarnet.org \
--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).