Re: possible getopt stderr output changes

[Laurent Bercot <ska-dietlibc@skarnet.org>]

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.
  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.


> 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.

  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.


> Thoughts on what color the bikeshed should be?

  I don't mind the color, but let's keep it SUV-free.
  
-- 
  Laurent