[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141211064427.GT4574@brightrain.aerifal.cx>
Date: Thu, 11 Dec 2014 01:44:27 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: possible getopt stderr output changes
On Thu, Dec 11, 2014 at 04:53:52AM +0100, Laurent Bercot wrote:
> On 11/12/2014 01:10, Rich Felker wrote:
> >The current getopt code uses some ugly write() sequences to generate
> >its output to stderr, and fails to support message translation. The
> >latter was an oversight when locale/translation support was added and
> >should absolutely be fixed. I'm not sure whether we should leave the
> >code using write() though or switch to fprintf.
>
> For what is worth, I may use getopt() sometime, but I will never, ever
> use stdio, which should burn in the deepest pits of Hell, and I'm being
> nuanced here.
Is there a reason behind this? On my build, the printf core is ~6.5k
and the other parts of stdio you might be likely to pull in are under
2k. I'm happy to take your opinion into consideration but it would be
nice to have some rationale.
> Please don't tie a reasonable interface to the flying kitchen sink
> monster just because it's guilty of having to write stuff to stderr in
> one particular case. It doesn't deserve that much punishment.
Personally I find stdio a lot more reasonable than getopt. The latter
has ugly global state, including possibly hidden internal state with
no standard way to reset it. It works well enough for most things
(because you can pretend the global state is a sort of main-local
state), but it's a problem if you want to handle multiple virtual
command lines in the same process (things like busybox-type shell with
builtins, or a program handling input from network, GUI, etc. as
command lines to be parsed like options, etc.).
> >printf/stdio. However, the use of multiple write() calls splits the
> >messages up into multiple syscalls unnecessarily (increasing the
> >likelihood of getting output interleaved with other processes running
> >in parallel on the same stderr)
>
> It is rare for getopt to return a parsing error when the program is
> used without an interactive terminal: scripts are usually debugged
> before they're daemonized. Most use cases of getopt writing to stderr
> are interactive, so the likelihood of interleaving output is low.
This is certainly true.
> That said, I'm all for buffering, but is there anything more to do
> than print localized versions of "illegal option" and "option requires
> an argument", with some locale-independent data prepended and appended ?
> Isn't it possible to compute the size of the final string in advance,
> and build it in a temporary buffer on the stack, before writing ?
> It's simple buffering: neither stdio's formatting engine, nor its
> FILE plate of noodles, are needed.
For proper reporting of errors with long options (note: currently this
is not done right), at least one component of the message, the option
name, has unbounded size, so there's no simple way to generate the
whole message in a buffer. And even if we just did as much as we
could, the code for buffering would be ugly and increase code size by
at least a few hundred bytes I think. So this doesn't sound like much
of a win over just doing the current multiple-write() approach.
And yes you're right about the nature of the translatable portion and
locale-independent portion of the messages.
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.
