Re: --library-path and friends (was: [musl] musl 1.1.0 released)

[u-igbb@aetey.se]

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