The following rule looks promising:
@r@
constant c;
identifier i;
expression e;
@@
(
e | c@i
|
e & c@i
|
e |= c@i
|
e &= c@i
)
@@
constant r.c,c1;
identifier i1;
expression e;
@@
*c1@i1 + c
That is, the sum of two constants where at least one of them has been used
with & or |.
julia
--
To
On Tue, 2013-01-29 at 18:49 +0100, Julia Lawall wrote:
> How about the following (from today's linux-next). They appear to be
> trying to do the same calculation, once with + and once with |.
(cc'ing the original developer and Russell King)
Likely the it8152_pci_platform_notify uses should use
How about the following (from today's linux-next). They appear to be
trying to do the same calculation, once with + and once with |.
arch/arm/common/it8152.c
int dma_set_coherent_mask(struct device *dev, u64 mask)
{
if (mask >= PHYS_OFFSET + SZ_64M - 1)
return 0;
Here are the warnings for yesterday's linux-next (next-20130128).
regards,
dan carpenter
arch/x86/crypto/crc32-pclmul_glue.c:66 crc32_pclmul_le() warn: bit mask
'SCALE_F_MASK' used for math 'p + (16 - 1)'
arch/x86/kernel/cpu/mcheck/mce_amd.c:155 threshold_restart_bank() warn: bit
mask
On Tue, 2013-01-29 at 17:19 +0100, Julia Lawall wrote:
> > On Tue, 2013-01-29 at 10:55 -0500, valdis.kletni...@vt.edu wrote:
[]
> > > I wonder if there's a way to write a coccinelle patch to find places
> > > where we do arithmetic operations on bitmasks
[]
> If the definition of a bitmask is
On Tue, 29 Jan 2013, Joe Perches wrote:
> On Tue, 2013-01-29 at 10:55 -0500, valdis.kletni...@vt.edu wrote:
> > On Sun, 27 Jan 2013 23:19:47 +0300, Dan Carpenter said:
> >
> > > Yeah. I think it would be, but adding bitflags together instead of
> > > doing bitwise ORs is very common as well.
>
On Tue, 2013-01-29 at 10:55 -0500, valdis.kletni...@vt.edu wrote:
> On Sun, 27 Jan 2013 23:19:47 +0300, Dan Carpenter said:
>
> > Yeah. I think it would be, but adding bitflags together instead of
> > doing bitwise ORs is very common as well.
>
> The fact it's common doesn't mean it's good
On Sun, 27 Jan 2013 23:19:47 +0300, Dan Carpenter said:
> Yeah. I think it would be, but adding bitflags together instead of
> doing bitwise ORs is very common as well.
The fact it's common doesn't mean it's good programming practice,
or even correct. Consider:
#define F_FOO 0x01
#define
On Sun, 27 Jan 2013 23:19:47 +0300, Dan Carpenter said:
Yeah. I think it would be, but adding bitflags together instead of
doing bitwise ORs is very common as well.
The fact it's common doesn't mean it's good programming practice,
or even correct. Consider:
#define F_FOO 0x01
#define F_BAR
On Tue, 2013-01-29 at 10:55 -0500, valdis.kletni...@vt.edu wrote:
On Sun, 27 Jan 2013 23:19:47 +0300, Dan Carpenter said:
Yeah. I think it would be, but adding bitflags together instead of
doing bitwise ORs is very common as well.
The fact it's common doesn't mean it's good programming
On Tue, 29 Jan 2013, Joe Perches wrote:
On Tue, 2013-01-29 at 10:55 -0500, valdis.kletni...@vt.edu wrote:
On Sun, 27 Jan 2013 23:19:47 +0300, Dan Carpenter said:
Yeah. I think it would be, but adding bitflags together instead of
doing bitwise ORs is very common as well.
The fact
On Tue, 2013-01-29 at 17:19 +0100, Julia Lawall wrote:
On Tue, 2013-01-29 at 10:55 -0500, valdis.kletni...@vt.edu wrote:
[]
I wonder if there's a way to write a coccinelle patch to find places
where we do arithmetic operations on bitmasks
[]
If the definition of a bitmask is an
Here are the warnings for yesterday's linux-next (next-20130128).
regards,
dan carpenter
arch/x86/crypto/crc32-pclmul_glue.c:66 crc32_pclmul_le() warn: bit mask
'SCALE_F_MASK' used for math 'p + (16 - 1)'
arch/x86/kernel/cpu/mcheck/mce_amd.c:155 threshold_restart_bank() warn: bit
mask
How about the following (from today's linux-next). They appear to be
trying to do the same calculation, once with + and once with |.
arch/arm/common/it8152.c
int dma_set_coherent_mask(struct device *dev, u64 mask)
{
if (mask = PHYS_OFFSET + SZ_64M - 1)
return 0;
On Tue, 2013-01-29 at 18:49 +0100, Julia Lawall wrote:
How about the following (from today's linux-next). They appear to be
trying to do the same calculation, once with + and once with |.
(cc'ing the original developer and Russell King)
Likely the it8152_pci_platform_notify uses should use +
The following rule looks promising:
@r@
constant c;
identifier i;
expression e;
@@
(
e | c@i
|
e c@i
|
e |= c@i
|
e = c@i
)
@@
constant r.c,c1;
identifier i1;
expression e;
@@
*c1@i1 + c
That is, the sum of two constants where at least one of them has been used
with or |.
julia
--
To
Am 27.01.2013 22:00, schrieb Joe Perches:
> On Sun, 2013-01-27 at 23:19 +0300, Dan Carpenter wrote:
>> On Sun, Jan 27, 2013 at 12:04:38PM -0800, Joe Perches wrote:
>>> Wouldn't it be clearer still to use | instead of +
>> Yeah. I think it would be, but adding bitflags together instead of
>>
Am 27.01.2013 22:00, schrieb Joe Perches:
On Sun, 2013-01-27 at 23:19 +0300, Dan Carpenter wrote:
On Sun, Jan 27, 2013 at 12:04:38PM -0800, Joe Perches wrote:
Wouldn't it be clearer still to use | instead of +
Yeah. I think it would be, but adding bitflags together instead of
doing bitwise
On Sun, 2013-01-27 at 23:19 +0300, Dan Carpenter wrote:
> On Sun, Jan 27, 2013 at 12:04:38PM -0800, Joe Perches wrote:
> > Wouldn't it be clearer still to use | instead of +
> Yeah. I think it would be, but adding bitflags together instead of
> doing bitwise ORs is very common as well.
On Sun, Jan 27, 2013 at 12:04:38PM -0800, Joe Perches wrote:
> On Sun, 2013-01-27 at 22:40 +0300, Dan Carpenter wrote:
> > There is a kind of precedence problem here, but it doesn't affect how
> > the code works because ->serial_signals is unsigned char. We want to
> > clear two flags here.
> >
On 01/27/2013 09:04 PM, Joe Perches wrote:
> On Sun, 2013-01-27 at 22:40 +0300, Dan Carpenter wrote:
>> There is a kind of precedence problem here, but it doesn't affect how
>> the code works because ->serial_signals is unsigned char. We want to
>> clear two flags here.
>>
>> #define
On Sun, 2013-01-27 at 22:40 +0300, Dan Carpenter wrote:
> There is a kind of precedence problem here, but it doesn't affect how
> the code works because ->serial_signals is unsigned char. We want to
> clear two flags here.
>
> #define SerialSignal_RTS0x20 /* Request to Send */
>
There is a kind of precedence problem here, but it doesn't affect how
the code works because ->serial_signals is unsigned char. We want to
clear two flags here.
#define SerialSignal_RTS0x20 /* Request to Send */
#define SerialSignal_DTR0x80 /* Data Terminal Ready
There is a kind of precedence problem here, but it doesn't affect how
the code works because -serial_signals is unsigned char. We want to
clear two flags here.
#define SerialSignal_RTS0x20 /* Request to Send */
#define SerialSignal_DTR0x80 /* Data Terminal Ready
On Sun, 2013-01-27 at 22:40 +0300, Dan Carpenter wrote:
There is a kind of precedence problem here, but it doesn't affect how
the code works because -serial_signals is unsigned char. We want to
clear two flags here.
#define SerialSignal_RTS0x20 /* Request to Send */
#define
On 01/27/2013 09:04 PM, Joe Perches wrote:
On Sun, 2013-01-27 at 22:40 +0300, Dan Carpenter wrote:
There is a kind of precedence problem here, but it doesn't affect how
the code works because -serial_signals is unsigned char. We want to
clear two flags here.
#define SerialSignal_RTS
On Sun, Jan 27, 2013 at 12:04:38PM -0800, Joe Perches wrote:
On Sun, 2013-01-27 at 22:40 +0300, Dan Carpenter wrote:
There is a kind of precedence problem here, but it doesn't affect how
the code works because -serial_signals is unsigned char. We want to
clear two flags here.
#define
On Sun, 2013-01-27 at 23:19 +0300, Dan Carpenter wrote:
On Sun, Jan 27, 2013 at 12:04:38PM -0800, Joe Perches wrote:
Wouldn't it be clearer still to use | instead of +
Yeah. I think it would be, but adding bitflags together instead of
doing bitwise ORs is very common as well.
Fortunately,
28 matches
Mail list logo
