This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Question about ash and getopts

In message <>, Larry Hall writes:
>I see.  So how does this thread differ from previous ones on this subject?

Well, first off, I've done the obvious test, and verified that there is no
"13k space saving".  There might be 1/2k.

>As far as I can see, you simply want to state your case but not contribute 
>anything in return.  We've had threads like that.  If you *really* want
>to see a change here, you have to put some effort into it.  That means 
>looking at the issue objectively, running some tests, and if those tests
>bear out, sharing them with the list along with the patch to enable the 
>features you want and that your tests validate.

I can indeed run tests, but right now, no one has offered even a TINY SHRED
of actual evidence that the current broken behavior ever saved any space or

The one evidential claim made in the past was that getopts was 13k of
executable size.  It isn't.

The resistence here makes no sense.  The code is already written; it is in
ash, as it has been forever.  There is no evidence showing that removing half
a kilobyte of executable code makes any measurable difference at all.

This suggests to me that no amount of testing matters; the decision here is
an ego one, not an engineering one.  The decision Was Made; therefore it is
the Cygwin Way to break /bin/sh in the name of saving space, even if the space
savings are actually 1/26th of what was claimed.

Can anyone honestly tell me that, if it turns out that enabling getopts
imposes no significant performance penalty, that this will result in fixing
the shell?  I see no reason to believe it, simply because there's never been
any evidence that getopts was causing problems in the first place.


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]