Re: Re: Re: What is the best way to compare an unsigned and a constant?

[SeongJae Park <sjpark@amazon.com>]

On   Tue, 7 Jan 2020 05:35:21 -0800   Brendan Higgins <brendanhiggins@google.com> wrote:

> Sorry for the delay, I was on vacation. (I still am, but I was too ;-).)

Happy new year, Brendan :)

> 
> On Tue, Jan 7, 2020 at 3:52 AM SeongJae Park <sjpark@amazon.com> wrote:
> >
> > On   Fri, 27 Dec 2019 13:52:27 +0100   Bernd Petrovitsch <bernd@petrovits=
> ch.priv.at> wrote:
> >
> > > This is a multi-part message in MIME format.
> > > --------------D98A0A31D62B0BC2939BAEE9
> > > Content-Type: text/plain; charset=3Dutf-8
> > > Content-Transfer-Encoding: quoted-printable
> > >
> > > Hi all!
> > >
> > > On 27/12/2019 13:39, SeongJae Park wrote:
> > > [...]
> > > > I have a function returning 'unsigned long', and would like to write =
> a =3D
> > > kunit
> > > > test for the function, as below.
> > > >=3D20
> > > >     unsigned long foo(void)
> > > >     {
> > > >             return 42;
> > > >     }
> > > >=3D20
> > > >     static void foo_test(struct kunit *test)
> > > >     {
> > > >         KUNIT_EXPECT_EQ(test, 42, foo());
> > > >     }
> > >
> > > For this case: shouldn't=3D20
> > > ----  snip  ----
> > > static void foo_test(struct kunit *test)
> > > {
> > >      KUNIT_EXPECT_EQ(test, 42ul, foo());
> > > }
> > > ----  snip  ----
> > > do the trick?
> >
> > Unfortunately, it doesn't works.
> >
> >     [13:04:58] Building KUnit Kernel ...
> >     In file included from /.../linux/include/linux/list.h:9:0,
> >                      from /.../linux/include/linux/wait.h:7,
> >                      from /.../linux/include/linux/wait_bit.h:8,
> >                      from /.../linux/include/linux/fs.h:6,
> >                      from /.../linux/include/linux/debugfs.h:15,
> >                      from /.../linux/mm/damon.c:12:
> >     /.../linux/mm/damon-test.h: In function =E2=80=98damon_test_foo=E2=80=
> =99:
> >     /.../linux/include/linux/kernel.h:842:29: warning: comparison of dist=
> inct pointer types lacks a cast
> >        (!!(sizeof((typeof(x) *)1 =3D=3D (typeof(y) *)1)))
> >                                  ^
> >     /.../linux/include/kunit/test.h:493:9: note: in expansion of macro =
> =E2=80=98__typecheck=E2=80=99
> >       ((void)__typecheck(__left, __right));           \
> >              ^~~~~~~~~~~
> >     /.../linux/include/kunit/test.h:517:2: note: in expansion of macro =
> =E2=80=98KUNIT_BASE_BINARY_ASSERTION=E2=80=99
> >       KUNIT_BASE_BINARY_ASSERTION(test,           \
> >       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> >     /.../linux/include/kunit/test.h:606:2: note: in expansion of macro =
> =E2=80=98KUNIT_BASE_EQ_MSG_ASSERTION=E2=80=99
> >       KUNIT_BASE_EQ_MSG_ASSERTION(test,           \
> >       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> >     /.../linux/include/kunit/test.h:616:2: note: in expansion of macro =
> =E2=80=98KUNIT_BINARY_EQ_MSG_ASSERTION=E2=80=99
> >       KUNIT_BINARY_EQ_MSG_ASSERTION(test,           \
> >       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >     /.../linux/include/kunit/test.h:979:2: note: in expansion of macro =
> =E2=80=98KUNIT_BINARY_EQ_ASSERTION=E2=80=99
> >       KUNIT_BINARY_EQ_ASSERTION(test, KUNIT_EXPECTATION, left, right)
> >       ^~~~~~~~~~~~~~~~~~~~~~~~~
> >     /.../linux/mm/damon-test.h:565:2: note: in expansion of macro =E2=80=
> =98KUNIT_EXPECT_EQ=E2=80=99
> >       KUNIT_EXPECT_EQ(test, 42ul, (int)foo());
> >       ^~~~~~~~~~~~~~~
> 
> Isn't the issue here that you fixed the 42, but are now casting the
> result of foo() to an int?

Oh, right...  Removing the non-sense casting fixed the problem.  Thanks,
Brendan!


Thanks,
SeongJae Park

> 
> Or have you fixed that now too?
> 
> Worst case (gross) scenario, you could just cast 42 to whatever type
> foo() returns.
> 
> > Some other thoughts?
> >
> >
> > Thanks,
> > SeongJae Park
> >
> >
> > >
> > > MfG,
> > >       Bernd
> > > --=3D20
> > > "I dislike type abstraction if it has no real reason. And saving
> > > on typing is not a good reason - if your typing speed is the main
> > > issue when you're coding, you're doing something seriously wrong."
> > >     - Linus Torvalds
>