Re: Making C function declaration parameter names consistent with corresponding definition names

On Fri, Sep 16, 2022 at 6:48 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> On Fri, Sep 16, 2022 at 6:20 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > I think they're easily Stroustrup's worst idea ever. You're basically
> > throwing away an opportunity for documentation, and that documentation
> > is often sorely needed.
>
> He could at least point to C++ pure virtual functions, where omitting
> a parameter name in the base class supposedly conveys useful
> information. I don't find that argument particularly convincing
> myself, even in a C++ context, but at least it's an argument. Doesn't
> apply here in any case.

Several files from src/timezone and from src/backend/regex make use of
unnamed parameters in function declarations. It wouldn't be difficult
to fix everything and call it a day, but I wonder if there are any
special considerations here. I don't think that Henry Spencer's regex
code is considered vendored code these days (if it ever was), so that
seems clear cut. I'm less sure about the timezone code.

Note that regcomp.c has a relatively large number of function
declarations that need to be fixed (regexec.c has some too), since the
regex code was written in a style that makes unnamed parameters in
declarations the standard -- we're talking about changing every static
function declaration. The timezone code is just inconsistent about its
use of unnamed parameters, kind of like reorderbuffer.h.

I don't see any reason to treat this quasi-vendored code as special,
but I don't really know anything about your workflow with the timezone
files.

--
Peter Geoghegan