Horton

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

Peter Geoghegan <pg@bowt.ie>

View thread View on postgr.es
From: Peter Geoghegan <pg@bowt.ie>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-09-17T18:05:09Z
Lists: pgsql-hackers 
On Fri, Sep 16, 2022 at 6:48 PM Peter Geoghegan <pg@bowt.ie> wrote:
> On Fri, Sep 16, 2022 at 6:20 PM Tom Lane <tgl@sss.pgh.pa.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

Commits

  1. Harmonize parameter names in pg_dump/pg_dumpall.

  2. Harmonize parameter names in contrib code.

  3. Harmonize more lexer function parameter names.

  4. Harmonize parameter names in ecpg code.

  5. Harmonize lexer adjacent function parameter names.

  6. Harmonize more parameter names in bulk.

  7. Harmonize parameter names in storage and AM code.

  8. Harmonize heapam and tableam parameter names.

  9. Consistently use named parameters in timezone code.

  10. Consistently use named parameters in regex code.

  11. Harmonize reorderbuffer parameter names.

  12. Make check_usermap() parameter names consistent.