From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6709 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: possible getopt stderr output changes Date: Thu, 11 Dec 2014 01:44:27 -0500 Message-ID: <20141211064427.GT4574@brightrain.aerifal.cx> References: <20141211001032.GA5421@brightrain.aerifal.cx> <54891550.901@skarnet.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1418280288 12314 80.91.229.3 (11 Dec 2014 06:44:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Dec 2014 06:44:48 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6722-gllmg-musl=m.gmane.org@lists.openwall.com Thu Dec 11 07:44:41 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 1XyxUP-0004lL-BZ for gllmg-musl@m.gmane.org; Thu, 11 Dec 2014 07:44:41 +0100 Original-Received: (qmail 30541 invoked by uid 550); 11 Dec 2014 06:44:40 -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 30530 invoked from network); 11 Dec 2014 06:44:39 -0000 Content-Disposition: inline In-Reply-To: <54891550.901@skarnet.org> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6709 Archived-At: 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