[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wj5FC6e3TnkDV2anfRWjj+a5gtx__3v0BfX+OrT2YXTTg@mail.gmail.com>
Date: Mon, 28 Nov 2022 11:42:53 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: David Laight <David.Laight@...lab.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Steven Rostedt <rostedt@...dmis.org>,
Joe Perches <joe@...ches.com>
Subject: Re: [PATCH 1/1] minmax.h: Slightly relax the type checking done by
min() and max().
On Mon, Nov 28, 2022 at 1:10 AM David Laight <David.Laight@...lab.com> wrote:
>
> So you start with:
> unsigned int a;
> min(a, 5u)
That's not the case I worry about.
Look at something like this instead:
min(4u, -5l)
which we currently warn about, because the types are very different.
It's simply a dangerous thing to do, since the signedness is
ambiguous. We *need* to warn about it.
But with your patch, that warning goes away, and the '4u' is a
positive integer, so it gets turned into 'int', and now that
comparison gets done as a signed type and returns -5.
No?
Now, the above is obviously crazy code, and I would certainly hope
that we don't have anything quite that odd in the kernel. That example
is designed to be silly, but minimally show the issue.
You can't just say "because it has a positive _value_, we can now use
it as a signed type".
See what I'm saying?
Linus
Powered by blists - more mailing lists