[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 29 Jun 2014 15:30:15 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Is there a "right" way to deal with error.h inclusions?
On Sun, Jun 29, 2014 at 07:21:58PM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@...c.org> [2014-06-29 11:43:57 -0400]:
> > Yes, I know that's a pain. Again, I'm open to considering adding
> > compatible functions to musl, but first I need someone with an
> > interest in it to do the research on what's involved.
>
> i attached the thing i got last time i looked into this
> (there is global state accessed without sync and other ugliness)
Yes, there's also the fact that the error count could wrap and wrongly
indicate "no errors" to the program (presumably it should saturate),
and lack of atomicity of writes.
I'd kinda lean towards not supporting error_print_progname and
error_one_per_line at all. Then the whole output can be accomplished
with a single dprintf, which is much safer (if someone does stupidly
use this interface in program-in-corrupted-state situations) than
using stdio.
Of course it might be better to just put all this ugliness in a
third-party liberror.a.
Rich
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.
