[PATCH] idmap: use UL for bitshift literals

[PATCH] idmap: use UL for bitshift literals

[Tony Espy]

[-- Attachment #1: Type: text/plain, Size: 1697 bytes --]

The current bitshift logic in idmap incorrectly uses
the literal 1 for the value to shift in idmap_alloc(),
idmap_take(), and idmap_alloc_next().  This causes the
resulting value to be an int instead of a long, which
results in the wrong bit being set once the number of
bits to shift operand exceeds sizeof(int).  Also
on some platforms, the behavior of the left bitshift
operator is undefined when this overflow occurs.
---
 src/idmap.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/idmap.c b/src/idmap.c
index 63f5c7c..c097eb4 100644
--- a/src/idmap.c
+++ b/src/idmap.c
@@ -135,7 +135,7 @@ void idmap_put(struct idmap *idmap, unsigned int id)
 
 	id %= BITS_PER_LONG;
 
-	idmap->bits[offset] &= ~(1 << id);
+	idmap->bits[offset] &= ~(1UL << id);
 }
 
 unsigned int idmap_alloc(struct idmap *idmap)
@@ -149,7 +149,7 @@ unsigned int idmap_alloc(struct idmap *idmap)
 		return idmap->max + 1;
 
 	offset = bit / BITS_PER_LONG;
-	idmap->bits[offset] |= 1 << (bit % BITS_PER_LONG);
+	idmap->bits[offset] |= 1UL << (bit % BITS_PER_LONG);
 
 	return bit + idmap->min;
 }
@@ -163,7 +163,7 @@ void idmap_take(struct idmap *idmap, unsigned int id)
 		return;
 
 	offset = bit / BITS_PER_LONG;
-	idmap->bits[offset] |= 1 << (bit % BITS_PER_LONG);
+	idmap->bits[offset] |= 1UL << (bit % BITS_PER_LONG);
 }
 
 /*
@@ -186,7 +186,7 @@ unsigned int idmap_alloc_next(struct idmap *idmap, unsigned int last)
 		return idmap_alloc(idmap);
 
 	offset = bit / BITS_PER_LONG;
-	idmap->bits[offset] |= 1 << (bit % BITS_PER_LONG);
+	idmap->bits[offset] |= 1UL << (bit % BITS_PER_LONG);
 
 	return bit + idmap->min;
 }
-- 
1.9.0

Re: [PATCH] idmap: use UL for bitshift literals

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 663 bytes --]

Hi Tony,

On 03/04/2014 06:01 PM, Tony Espy wrote:
> The current bitshift logic in idmap incorrectly uses
> the literal 1 for the value to shift in idmap_alloc(),
> idmap_take(), and idmap_alloc_next().  This causes the
> resulting value to be an int instead of a long, which
> results in the wrong bit being set once the number of
> bits to shift operand exceeds sizeof(int).  Also
> on some platforms, the behavior of the left bitshift
> operator is undefined when this overflow occurs.
> ---
>   src/idmap.c | 8 ++++----
>   1 file changed, 4 insertions(+), 4 deletions(-)
>

Good catch.  Patch has been applied, thanks.

Regards,
-Denis

Re: [PATCH] idmap: use UL for bitshift literals

[Tony Espy]

[-- Attachment #1: Type: text/plain, Size: 1047 bytes --]

On 03/05/2014 09:52 AM, Denis Kenzior wrote:
> Hi Tony,
>
> On 03/04/2014 06:01 PM, Tony Espy wrote:
>> The current bitshift logic in idmap incorrectly uses
>> the literal 1 for the value to shift in idmap_alloc(),
>> idmap_take(), and idmap_alloc_next().  This causes the
>> resulting value to be an int instead of a long, which
>> results in the wrong bit being set once the number of
>> bits to shift operand exceeds sizeof(int).  Also
>> on some platforms, the behavior of the left bitshift
>> operator is undefined when this overflow occurs.
>> ---
>>   src/idmap.c | 8 ++++----
>>   1 file changed, 4 insertions(+), 4 deletions(-)
>>
>
> Good catch.  Patch has been applied, thanks.

Denis -

One of my co-workers recently sent a couple of patches that add Python3 
support to the ofono test scripts, however he's not currently subscribed 
to the mailing list so they emails appear to be in limbo...

Can someone clear these as a list moderator, or should I go ahead and 
re-send them myself?

Regards,
/tony

Re: [PATCH] idmap: use UL for bitshift literals

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 496 bytes --]

Hi Tony,

 >
> Denis -
>
> One of my co-workers recently sent a couple of patches that add Python3
> support to the ofono test scripts, however he's not currently subscribed
> to the mailing list so they emails appear to be in limbo...
>
> Can someone clear these as a list moderator, or should I go ahead and
> re-send them myself?
>

I'm too lazy to moderate the list as there's too much spam.  Easiest 
would be for someone subscribed to re-send the patches.

Thanks,
-Denis