[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 11 Dec 2014 21:33:45 -0500
From: Morten Welinder <mwelinder@...il.com>
To: musl@...ts.openwall.com
Subject: Re: stdio [de]merits discussion [Re: possible getopt
stderr output changes]
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
<ska-dietlibc@...rnet.org> 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 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
>
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.
