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 uns
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 'THRESHOL
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 a
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 progr
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
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
>> doin
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.
Fortunatel
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 SerialSignal_
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 */
> #
13 matches
Mail list logo
