Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20221231064203.1623793-1-masahiroy@kernel.org> <20221231064203.1623793-5-masahiroy@kernel.org>
In-Reply-To: <20221231064203.1623793-5-masahiroy@kernel.org>
From:   Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date:   Tue, 3 Jan 2023 21:45:50 +0100
Message-ID: <CANiq72n6ZLcNRh=Ec1xCSNJtb=KZNMA-MMrtd8=DyUL4-2i_0w@mail.gmail.com>
Subject: Re: [PATCH 4/6] fixdep: refactor hash table lookup
To:     Masahiro Yamada <masahiroy@kernel.org>
Cc:     linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
        Miguel Ojeda <ojeda@kernel.org>,
        Nathan Chancellor <nathan@kernel.org>,
        Nick Desaulniers <ndesaulniers@google.com>,
        Nicolas Schier <nicolas@fjasle.eu>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sat, Dec 31, 2022 at 7:42 AM Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> +/*
> + * Lookup a string in the hash table. If found, just return true.
> + * If not, add it to the hashtable and return false.
> + */
> +static bool in_hashtable(const char *name, int len, struct item *hashtab[])

I think readers may find a bit surprising that a function named
`in_hashtable` mutates the table. Should we use a better name? Perhaps
`ensure_in_hashtable`?

In other words, the function is really "insert if not already there
and return the previous state". Similar methods in C++ and Rust are
called `insert`, though they return the opposite, i.e. whether the
insertion took place. If we did that, then `insert_into_hashtable` may
be a good name instead.

> +       unsigned int hash = strhash(name, len);

Nit: this could be `const`, but I see we are not using it in
`fixdep.c` (for non-pointees) and it was not done in the original. But
it could be nice to start...

Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
Tested-by: Miguel Ojeda <ojeda@kernel.org>

Cheers,
Miguel