[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ed008264-e72e-7548-d93e-f7f4130ef2c2@189.cn>
Date: Tue, 23 May 2023 17:55:39 +0800
From: Sui Jingfeng <15330273260@....cn>
To: David Laight <David.Laight@...LAB.COM>,
Jani Nikula <jani.nikula@...ux.intel.com>,
Sui Jingfeng <suijingfeng@...ngson.cn>,
Li Yi <liyi@...ngson.cn>
Cc: Thomas Zimmermann <tzimmermann@...e.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"loongson-kernel@...ts.loongnix.cn"
<loongson-kernel@...ts.loongnix.cn>
Subject: Re: [PATCH] drm/drm_vblank.c: avoid unsigned int to signed int cast
Hi,
On 2023/5/23 16:50, David Laight wrote:
> From: 15330273260@....cn <15330273260@....cn>
>> Sent: 23 May 2023 05:27
>>
>> On 2023/5/22 19:29, Jani Nikula wrote:
>>> In general, do not use unsigned types in arithmethic to avoid negative
>>> values, because most people will be tripped over by integer promotion
>>> rules, and you'll get negative values anyway.
>>
>> Here I'm not sure about this,
>>
>> but there are plenty unsigned types arithmetic in the kernel.
> The real problem is (attempted) arithmetic on types smaller than int.
> Regardless of whether they are signed or unsigned.
It is about sign extend.
Yes, you may be right. I might create a wrong patch.
But this will not happen in practice, because in general case:
mode->crtc_htotal < 0x8fff;
mode->crtc_vtotal < 0x8fff;
u16 gets promoted to 'signed int' not 'unsigned int'.
Sorry :/
> David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
Powered by blists - more mailing lists