Re: [lwip-devel] Possibly falsely triggered LWIP_ASSERT?

[Grubb, Jared]

Given that grow can be negative, the assert above that line is not  
correct:

     LWIP_ASSERT("grow < max_u16_t", grow < 0xffff);
     q->tot_len += (u16_t)grow;

Very large negative numbers will pass this test.

My first thought was that the test should be abs(grow)<0xffff, but  
that seems a bit odd. So, maybe you really want to verify that grow is  
a valid s16_t, that is (s32_t)((s16_t)grow)==grow.

Jared

On 30 Sep 2009, at 01:17, Kieran Mansley wrote:

> On Tue, 2009-09-29 at 11:02 -0400, Bill Auerbach wrote:
>> Because tot_len and grow (via casting) are u16_t, there is no  
>> problem here -
>> no sign extension can occur.  If tot_len were larger, this would be  
>> a bug.
>> In order to be "righter" this should be a cast to s_16t.  The  
>> compiler
>> output will be unchanged by this change.
>
> I think I follow - a small negative value will be changed to a large
> positive value when doing the cast, which when added to tot_len in
> unsigned arithmetic will wrap the value and you'll end up with  
> something
> that is slightly smaller than you started with - i.e. the correct
> result.  I might change this line anyway just to make it clearer what
> it's actually doing.
>
> Kieran
>
>
>
> _______________________________________________
> lwip-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-devel