Re: [PATCH] builtin/config: work around an unsized array forward declaration

[Kim Gybels <kgybels@infogroep.be>]

On (06/07/18 12:24), Junio C Hamano wrote:
> 
> Jeff King <peff@peff.net> writes:
> 
> > On Thu, Jul 05, 2018 at 09:50:53PM +0200, Beat Bolli wrote:
> >
> >> > Your patch is obviously correct, but I think here there might be an even
> >> > simpler solution: just bump option_parse_type() below the declaration,
> >> > since it's the only one that needs it. That hunk is bigger, but the
> >> > overall diff is simpler, and we don't need to carry that extra wrapper
> >> > function.
> >> 
> >> That was dscho's first try in the GitHub issue. It doesn't compile
> >> because the OPT_CALLBACK* macros in the builtin_config_options
> >> declaration inserts a pointer to option_parse_type into the array items.
> >> We need at least one forward declaration, and my patch seemed the least
> >> intrusive.
> >
> > Ah, right, so it actually is mutually recursive.  Forward-declaring
> > option_parse_type() would fix it, along with the reordering. I'm
> > ambivalent between the available options, then; we might as well go with
> > what you posted, then, since it's already done. :)
> 
> Among three, forward declaration of the function with reordering
> that nobody has written except for in the brain smells the best, and
> turning an array to a pointer that points at a separate storage looked
> the worst.  I also am OK with what's already posted, too.

I posted the forward declaration of the function on the Git for
Windows issue:
https://github.com/git-for-windows/git/issues/1735#issuecomment-402825623

I would consider it the minimal fix. The already posted solution is
also OK for me.

It's also possible to use "extern" instead of "static" for the array.
It would, however, not be my preferred solution.

-Kim