[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sort --compare-version

From: Bob Proulx
Subject: Re: sort --compare-version
Date: Wed, 6 Feb 2008 14:26:16 -0700
User-agent: Mutt/1.5.13 (2006-08-11)

Bruce Korb wrote:
> Bob Proulx wrote:
> > I don't like the magic number 7 there (and I think it should have been
> > 8 anyway meaning that you have also fixed a bug to be noted in the log
> > entry) but using sizeof short_options I think is not correct either.
> It is guaranteed to be sufficient and certain to be inconsequential.
> Yes, it uses a half dozen extra bytes of memory.  That can't be
> a problem.

In my mind it wasn't about the extra memory.  As you noted it was an
insignificant amount.  My concern was that it tied the size of that
string to something that strictly speaking was something different.
It would always have been larger and would have been functional.  But
it isn't really the size of the thing that we needed.  Reading the
code later there wasn't the mental tie between the two things that I
felt needed to be tied together.

> > I think I like this following technique better.  In my mind it makes
> > it much more self-documenting without using extra space.
> > 
> >       {
> >     char opts[sizeof "dfgiMnVR"];
> >     char *p = opts;
> >     if (key->ignore == nondictionary)
> >       *p++ = 'd';
> I think this is an improvement that requires more maintenance than
> simply making the buffer big enough for any conceivable list of
> options.  So, marginally more intelligible and marginally more
> maintenance.  Looks good to me. :)

Anyone looking to add option letters would definitely be drawn to that
spot because it looks very similar to the getopts string of options
and would naturally keep it up to date.  I like it better than the
bare number approach but even that wasn't bad, just something that
could be slightly better.  Obviously I like it better than using a
bounded sizeof something else that's bigger.  So I will simply
disagree that it is more maintenance because I think it would be less
maintenance.  But either way if we are agreed that it may appear more
intelligible then it is a win.

> I'm glad you're willing to help 'cuz this isn't my day job.  :)

Do you work the midnight shift?  ;-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]