Re: [PATCH v2 12/16] parse-options: replace opterror() with optname()

From: Ramsay Jones <ramsay@ramsayjones.plus.com>
Date: Nov 10, 2018, 14:59 UTC
Message-ID: <2bbd6010-c4c5-df68-3583-51a354e3ab5a@ramsayjones.plus.com>
In-Reply-To: <CACsJy8CM=0Cw1WCamJJe8aapA4-mdr+rMmbjVpYYQCj2++NQbA@mail.gmail.com>

On 10/11/2018 04:55, Duy Nguyen wrote:

Show 18 quoted lines

> On Tue, Nov 6, 2018 at 3:07 PM Ramsay Jones <ramsay@ramsayjones.plus.com> wrote:
>> Also, this patch does not replace opterror() calls outside of
>> the 'parse-options.c' file with optname(). This tickles my
>> static-check.pl script, since optname() is an external function
>> which is only called from 'parse-options.c'.
>>
>> So, at present, optname() could be marked as a local 'static'
>> symbol. However, I could also imagine it being used by new callers
>> outside of 'parse-options.c' in the future. (maybe) Your call. ;-)
> 
> I was making it static, but the compiler complained about undefined
> function and I would need to either move optname() up in
> parse-options.c or add a forward declaration (but I was going to
> _remove_ the declaration!)
> 
> Since it could be potentially used by Jeff's series (and I think it
> does have potential in parse-options-cb.c), I'll just leave it
> exported and caress your static-check.pl script

Fair enough.

>                                                (how did it not catch
> optbug() not being used outside parse-options.c either)?

It did, some time ago (presumably, I haven't checked). Which is to say: the output from the master branch notes it:

    $ grep parse-options sc
    parse-options.o	- optbug
    $

... but if it gets to the master branch I tend to forget it. (I have been meaning to go through the 'sc' file and clean out some of the 'easy' cases).

So, if optname() doesn't get any new callers, I will watch it go from 'pu' to 'next' and then to 'master' and ... ;-)

ATB, Ramsay Jones