From: Daniel Latypov <dlatypov@google.com>
To: Rae Moar <rmoar@google.com>
Cc: brendanhiggins@google.com, davidgow@google.com,
skhan@linuxfoundation.org, kunit-dev@googlegroups.com,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v1] lib/hashtable_test.c: add test for the hashtable structure
Date: Fri, 13 Jan 2023 14:45:29 -0800 [thread overview]
Message-ID: <CAGS_qxqz31x_ya1BhoL=3xXLWnuwcJErdUweGK_tKx2KP_tLYQ@mail.gmail.com> (raw)
In-Reply-To: <CA+GJov4cyXhLnVtSMB8vBzscN0_y4fmSegEJjCr1aY51aCs5Bg@mail.gmail.com>
On Fri, Jan 13, 2023 at 2:23 PM Rae Moar <rmoar@google.com> wrote:
<snip>
> > Note: given x is supposed to point to a or b, I don't know if checking
> > against a.data does us much good.
> > If we're trying to check that hash_add() doesn't mutate the keys and
> > data, this code won't catch it.
> > We'd have to instead do something like
> > if(x->key != 1 && x->key != 2) KUNIT_FAIL(test, ...);
> >
>
> This seems like a good change to me in combination with changing it to
> x->visited++;.
> Although David's suggestion might be slightly more exhaustive.
> Why wouldn't it be important to check that the key matches the data?
Checks like
KUNIT_EXPECT_EQ(test, x->data, a.data);
won't do anything, given that x == &a.
We're just comparing x->data to itself.
So we would have to write something instead like
hash_for_each(hash, bkt, x, node) {
x->visited++;
if (x->key == a.key) {
KUNIT_EXPECT_EQ(test, x->data, 13);
} else if (x->key == b.key) {
KUNIT_EXPECT_EQ(test, x->data, 10);
} else { /* some call to KUNIT_FAIL about a bad key */ }
}
Maybe that's worth it in one of the test cases, but I don't know if
it's necessary to replicate this in the other places where we're
incrementing `visited` by checking keys.
Daniel
next prev parent reply other threads:[~2023-01-13 22:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-20 3:10 [PATCH v1] lib/hashtable_test.c: add test for the hashtable structure Rae Moar
2022-12-28 2:00 ` Daniel Latypov
2023-01-13 22:23 ` Rae Moar
2023-01-13 22:45 ` Daniel Latypov [this message]
2023-01-10 4:23 ` David Gow
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGS_qxqz31x_ya1BhoL=3xXLWnuwcJErdUweGK_tKx2KP_tLYQ@mail.gmail.com' \
--to=dlatypov@google.com \
--cc=brendanhiggins@google.com \
--cc=davidgow@google.com \
--cc=kunit-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=rmoar@google.com \
--cc=skhan@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.