From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4917 Path: news.gmane.org!not-for-mail From: u-igbb@aetey.se Newsgroups: gmane.linux.lib.musl.general Subject: Re: --library-path and friends (was: [musl] musl 1.1.0 released) Date: Sat, 19 Apr 2014 14:14:26 +0200 Message-ID: <20140419121426.GP18458@example.net> References: <20140416084102.GA11943@brightrain.aerifal.cx> <20140416104759.GJ18458@example.net> <20140416165352.GH26358@brightrain.aerifal.cx> <20140417081547.GK18458@example.net> <20140418204621.GM26358@brightrain.aerifal.cx> 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 1397910106 15040 80.91.229.3 (19 Apr 2014 12:21:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 19 Apr 2014 12:21:46 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4921-gllmg-musl=m.gmane.org@lists.openwall.com Sat Apr 19 14:21:39 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WbUH4-0002Yf-Hb for gllmg-musl@plane.gmane.org; Sat, 19 Apr 2014 14:21:38 +0200 Original-Received: (qmail 21655 invoked by uid 550); 19 Apr 2014 12:21:37 -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 21647 invoked from network); 19 Apr 2014 12:21:36 -0000 X-T2-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_50 Received-SPF: none receiver=mailfe02.swip.net; client-ip=18.187.1.68; envelope-from=u-igbb@aetey.se Content-Disposition: inline In-Reply-To: <20140418204621.GM26358@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:4917 Archived-At: On Fri, Apr 18, 2014 at 04:46:22PM -0400, Rich Felker wrote: > > Frankly I do not see any need for the '=' syntax extention, it probably > > costs some extra byte[s] but more importantly once introduced you will > > have to keep the extra possibility. I do not think (didn't check for a > > I'm not sure whether glibc's dynamic linker supports it, but the > processing of the form with --option=arg is part of the "standard" > getopt_long processing for long options, and I felt like it should be As you correctly say getopt_long is a "standard" not a standard. (AFAIK none of the other dynamic linkers support it, nor would the getopt_long syntax convention give any real advantage in the expected usage pattern) > supported here too for the sake of consistency if we're accepting long > options that look like getopt_long options. It's just one extra > (trivial) line of source anyway. Given that this costs a line which you will not be able to ever remove, I'd wait with adding this at least until somebody asks for it. I do not either like the extra resulting bytes inside the loader which I have to deliver everywhere the software will be run. These bytes will take the disk space, the network capacity and the RAM at many places, with the sole reason being to allow an additional (and unused) way to spell the same thing. This feature would also force everyone possibly reinterpreting the loader command line in scripts to add the code for parsing '=' just to cope with somebody else possibly having been used the extra "freedom of expression" (without having said anything different :) That's why in my eyes '=' looks like an unnecessary and actually harmful "feature pollution" (even though the harm is small, it is there). Of course I am extremely happy with the _functionality_ being there now. The syntax details are just details :) and the choice is yours. Thanks Rich! Rune