[0/2] clean up some MAYBE_UNUSED cases

Message

Jeff King Aug. 29, 2024, 8:08 p.m. UTC

The discussion about MAYBE_UNUSED over in[1] made me wonder how it was
used in practice. This series cleans up a few spots where I think it is
being misused.

[1] https://lore.kernel.org/git/xmqqseunxtks.fsf_-_@gitster.g/

The remaining grep hits are:

  - fsmonitor has a few functions with sometimes-unused parameters based
    on conditional compilation (try_to_run_foreground_daemon() and
    check_for_incompatible()). This is a good use of MAYBE_UNUSED.

  - builtin/gc.c's check_crontab_process(). The whole function is marked
    as MAYBE_UNUSED here, which is a little funny. It's because
    is_crontab_available() may or may not call us based on __APPLE__.
    Should we conditionally define the function, too, in that case? It
    would mean repeating the #ifdef. Alternatively, we could define it
    like this:

      #ifdef __APPLE__
      static int check_crontab_process(const char *cmd UNUSED)
      {
              return 0;
      }
      #else
      static int check_crontab_process(const char *cmd UNUSED)
      {
              [...the real function...]
      }
      #endif

    But I think we're getting into "well, this is how I would have
    written it" territory, and it doesn't matter much either way in
    practice. It's probably better to just leave it alone.

  - commit-slab marks auto-generated static functions with MAYBE_UNUSED,
    since it doesn't know which ones actually need to be instantiated.
    This was the original thing we added MAYBE_UNUSED for.

  - khash does something similar when auto-generating functions.

  - test_bitmap_commits() marks a local variable as MAYBE_UNUSED! In
    fact it's completely unused by the function itself, but the macro
    expansion of kh_foreach() assigns to it. So we need the variable to
    exist to pass into the macro, but the compiler warning is triggered
    on the expanded code. We have kh_foreach_value(), but not
    kh_foreach_key(), which is what we'd want here. It wouldn't be hard
    to add it, but the MAYBE_UNUSED here is doing a fine job of
    suppressing the warning (and presumably an optimizing compiler
    removes the useless assignment).

I prepared this on top of what's queued in jk/unused-parameters (which
helps with making sure the annotations are all correct), but it could be
applied separately.

  [1/2]: gc: drop MAYBE_UNUSED annotation from used parameter
  [2/2]: grep: prefer UNUSED to MAYBE_UNUSED for pcre allocators

 builtin/gc.c | 2 +-
 grep.c       | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

-Peff

Comments

Junio C Hamano Aug. 29, 2024, 8:46 p.m. UTC | #1

Jeff King <[e-mail]> writes:

>   - builtin/gc.c's check_crontab_process(). The whole function is marked
>     as MAYBE_UNUSED here, which is a little funny. It's because
>     is_crontab_available() may or may not call us based on __APPLE__.
>     Should we conditionally define the function, too, in that case? It
>     would mean repeating the #ifdef. Alternatively, we could define it
>     like this:
>
>       #ifdef __APPLE__
>       static int check_crontab_process(const char *cmd UNUSED)
>       {
>               return 0;
>       }
>       #else
>       static int check_crontab_process(const char *cmd UNUSED)
>       {
>               [...the real function...]
>       }
>       #endif

Or inline the body of check_crontab_process() at its sole callsite
(the other side of "#ifdef APPLE") in is_crontab_available() and get
rid of check_crontab_process().

>     But I think we're getting into "well, this is how I would have
>     written it" territory, and it doesn't matter much either way in
>     practice. It's probably better to just leave it alone.

OK.