[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bf313102-e949-41d9-89f3-bff06a43d647@kernel.org>
Date: Tue, 30 Apr 2024 07:24:52 +0200
From: Jiri Slaby <jirislaby@...nel.org>
To: David Laight <David.Laight@...LAB.COM>, Hugo Villeneuve
<hugo@...ovil.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jon Ringle <jringle@...dpoint.com>
Cc: "ria.freelander@...il.com" <ria.freelander@...il.com>,
Hugo Villeneuve <hvilleneuve@...onoff.com>,
"stable@...r.kernel.org" <stable@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>
Subject: Re: [PATCH] serial: sc16is7xx: fix bug in sc16is7xx_set_baud() when
using prescaler
On 29. 04. 24, 11:14, David Laight wrote:
> From: Jiri Slaby
>> Sent: 29 April 2024 07:39
> ...
>>> - u8 prescaler = 0;
>>> + int prescaler = 1;
>>
>> Ugh, why do you move to signed arithmetics?
>
> Any arithmetic would always have been signed.
> u8 is promoted to 'signed int' before being used for pretty much anything.
Sorry, what?
C99 ยง6.3.8.1 states:
If both operands have the same type, then no further conversion is needed.
Otherwise, if both operands have signed integer types or both have
unsigned integer types, the operand with the type of lesser integer
conversion rank is converted to the type of the operand with greater rank.
=====
I.e. u8 is converted according to that to ulong in this case. So
unsigned arithmetic happens.
> 'unsigned int prescaler' might have changed arithmetic to be unsigned.
The same as u8.
> OTOH you probably don't want a u8 - that might require the compiler
> mask an arithmetic result to 8 bits.
Pardon? Not at all.
Am I missing something?
thanks,
--
js
suse labs
Powered by blists - more mailing lists