Thomas Klausner <wiz@danbala.ifoer.tuwien.ac.at> writes:
> Is it okay if getopt reacts to an environment variable like
> "GETOPT_SWAP_ARGS" (better names are appreciated) for the users who
> want to have the new functionality? (If not, please argue the point --
> I'd try to fix all in-tree programs to work with both behaviours, of
> course.)

If you're going to do something like this, you need to be very careful
of security-related concerns.

for instance, say a set-id program execs another program, with a
certain set of arguments.  Are those arguments going to behave
properly if, effectively, randomly reordered?  Note that a simple
is-set[ug]id check is _not_ sufficient in this case, because the
problem occurs not with the set-id program, but the non-set-id program
that it's execve()ing.

I think that if you try to support this, you've got a _lot_ of
investigation to do, and i'd bet that you'll encounter some
not-easily-fixed dangerous situations.

To be honest, I think this is more trouble, and much more potential
danger, than it is worth.


> Todd Vierling wrote:
> > A getopt(3) replacement MUST function IDENTICALLY to getopt(3) as it has
> > been in libc with option strings that already exist.  No exceptions; this is
> > ABI compatibility.
> 
> I don't really get this argument -- doesn't it sometimes happen that a
> libc change mandates that some userland programs have to be recompiled
> (perhaps with a libc minor bump)? There are only a handful programs
> that would have to be recompiled (see the patch, and perhaps some more
> I hadn't thought of).

It's a valid argument, whether you get it or not.  8-)

Minor bumps occur for changes that do not require any recompilation of
existing binaries.  Additions to APIs, etc., are OK for a minor bump.

Changing the behaviour of arguments to existing functions in a way
that is not backward compatible is, in fact, an ABI change and would
require a full major bump or a backward-compatibility stub so that
code linked against the existing functions get the old behaviour.
This is what the library rename stuff.

It doesn't matter if it's 0 (that you know about -- there are always
some that you don't 8-), 1, a handful, or dozens.  An ABI change is an
ABI change.


Fundamentally, it's also Really Bad Mojo as far as i'm concerned: the
function has worked a certain way for a long, long time, and works the
same way in many other (commercial UNIX) systems.  To change its
behaviour in a subtle and incompatible way is simply going to cause
headaches.

Yes, the headaches are easy to fix.  But the fact is, they shouldn't
occur at all when using an API that's existed in a stable form for
years.


cgd