Re: [PATCH 0/5] allow -1 and compares in bitwise types

From: Linus Torvalds <torvalds@linux-foundation.org>
To: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Cc: Sparse Mailing-list <linux-sparse@vger.kernel.org>,
	Bart Van Assche <bvanassche@acm.org>
Subject: Re: [PATCH 0/5] allow -1 and compares in bitwise types
Date: Mon, 27 Jun 2022 12:14:28 -0700	[thread overview]
Message-ID: <CAHk-=wiRzOgEXT95o+ZQUawKbwBaGHoy=TSzB1dN2Uh26CZfCQ@mail.gmail.com> (raw)
In-Reply-To: <20220627190540.13358-1-luc.vanoostenryck@gmail.com>

On Mon, Jun 27, 2022 at 12:05 PM Luc Van Oostenryck
<luc.vanoostenryck@gmail.com> wrote:
>
>         #define is_signed_type(type)  (((type)-1) <= 0)

Side note: the reason we *don't* use this form in the kernel is
because broken compilers will complain about compares with zero in
unsigned types.

Using "<=" like you do may be an acceptable way to avoid it (the most
obvious thing is to use "< 0"), but it makes me nervous.

Regardless, I think you need the cast of the zero. I think "type"
might be a pointer, and sparse should be complaining about the horrid
use of a bare 0 as NULL.

Similar issues might happen for enums, where various compilers will
complain about comparing an enum to a non-enum.

So I'm pretty sure you would want casts on both values, instead of
assuming "it's an integer type, I don't need to cast 0".

But yeah, maybe

  #define is_signed_type(type)  (((type)-1) <= (type)0)

works fine and avoids warnings in all the cases.

Famous last words. Warnings can happen for almost anything, and I
wonder if that use of "1" had some other reason.

           Linus