From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6715 Path: news.gmane.org!not-for-mail From: Morten Welinder Newsgroups: gmane.linux.lib.musl.general Subject: Re: stdio [de]merits discussion [Re: [musl] possible getopt stderr output changes] Date: Thu, 11 Dec 2014 21:33:45 -0500 Message-ID: References: <20141211001032.GA5421@brightrain.aerifal.cx> <54891550.901@skarnet.org> <20141211064427.GT4574@brightrain.aerifal.cx> <5489BADF.8040604@skarnet.org> <20141211175156.GY4574@brightrain.aerifal.cx> <548A2338.7000701@skarnet.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1418351645 4451 80.91.229.3 (12 Dec 2014 02:34:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 12 Dec 2014 02:34:05 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6728-gllmg-musl=m.gmane.org@lists.openwall.com Fri Dec 12 03:33:58 2014 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XzG3K-00054d-DY for gllmg-musl@m.gmane.org; Fri, 12 Dec 2014 03:33:58 +0100 Original-Received: (qmail 11311 invoked by uid 550); 12 Dec 2014 02:33:56 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 11300 invoked from network); 12 Dec 2014 02:33:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=xrvdD12f/jLq1fgM458Wd6GE4ttqrjvnM7BwqGC+PAM=; b=W11m0XRy1h2SewZNVM1UNSUSaVfdGCJTRTsuMXdHI1lFUHe2LL3lFOrx7020XmvBOv R09vFdS/nh4zgHlEKs7oLFKSnASwsRKF3oU5aoFa7AHKybSJ/5y9yxLniRYA5fMaaILs lTKKCLksLvxlPns+pqBr6YvkVM/HUTIP04JM+3zdx7BIjdfRlRPBFT+EFqmqVHb2d44l 3xTFwKbWXFmKI3+wkCRM/Gyn+X9+7PbytO4m9cGgDv566H1yTvbaQgNtZ+KP//vOtrFp a28RfXYQVefN51L/genP/341b/GJ5tcs+d5ePHGx3eNusze7MlkF8sAM0E0p6aZyMM7W VMGQ== X-Received: by 10.194.108.98 with SMTP id hj2mr22849282wjb.102.1418351625083; Thu, 11 Dec 2014 18:33:45 -0800 (PST) In-Reply-To: <548A2338.7000701@skarnet.org> Xref: news.gmane.org gmane.linux.lib.musl.general:6715 Archived-At: It sounds a bit like the main beef you have with printf is that it pulls in floating point stuff. Absent that, it really isn't a lot of code and it really doesn't eat much stack space. So maybe what you are looking for is a way to compile away all floating point support. M. On Thu, Dec 11, 2014 at 6:05 PM, Laurent Bercot wrote: > 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 poki= ng >> 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." :-=C3=9E > 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 >