The original check intends to be still valid if the type of 'dupacks' is
changed in the future, therefore, I think it is better than explicitly
checking for a constant (0xFF). This kind of check is used in multiple places
throughout the stack and should have a comment stating that this is an
On line 883 of core/tcp_in.c is the somewhat strange construct...
883 : if (pcb-dupacks + 1 pcb-dupacks)
That would be always true, indeed
Perhaps what was meant was...
if( (u8_t)(pcb-dupacks+1)
Even that is dubious since 1 is an int
I don't catch the sense of
Lou Cypher wrote:
The case above isn't always true, in fact it yields false when
pcb-dupacks == 0xFF.
May be that was the intended behavior? Then could have been shorter (and
more
intuitive) checking for
if( pcb-dupacks != 0xFF )
The original check intends to be still valid if the type
On Mon, 2010-03-01 at 10:05 +0100, Simon Goldschmidt wrote:
I didn't check yet if the bug report here is valid, but at least under
VS2005/2008 and cygwin-gcc, there is no such warning...
I would be interested in a reference to the C standard that explains why
this would be cast to an int. I
On 1 March 2010 12:31, Kieran Mansley kie...@recoil.org wrote:
I would be interested in a reference to the C standard that explains why
this would be cast to an int.
Here is the relevant portion of C99:
-quote-
If both operands have the same type, then no further conversion is needed.
-users-bounces+bauerbach=arrayonline@nongnu.org] On
Behalf Of Mike Kleshov
Sent: Monday, March 01, 2010 4:53 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Strange always true conditional in tcp_in.c
On 1 March 2010 12:31, Kieran Mansley kie...@recoil.org wrote:
I would
I forgot the cast and so now it's char specific! I guess storing the max
value is the only portable way, but that still involves knowing the type.
This isn't much different than what we have now but it's more efficient -
and you must use the cast. Oh well...
if ((u8_t) (pcb-dupacks + 1) != 0)
#define max_dup_acks(size) (size == 1 ? 0xffu : size == 2 ? 0xu :
0xul)
if (pcb-dupacks != max_dup_acks(sizeof pcb-dupacks))
++pcb-dupacks;
___
lwip-users mailing list
lwip-users@nongnu.org
On Mon, 2010-03-01 at 08:49 -0500, Bill Auerbach wrote:
You could assign a variable max_dupacks of the same type as dupacks to -1UL
which would store the maximum unsigned value and then do:
if (pcb-dupacks != max_dupacks)
++pcb-dupacks;
This sounds like the best solution as max_dupacks
The macro below would be computed at compile time - there is no overhead in
this implementation which is why I thought it to be better than the previous
suggestion which used a variable.
It could be more generic: #define max_unsigned since it can be used in all
unsigned overflow checks.
Bill
] On Behalf Of Simon
Goldschmidt
Sent: Monday, March 01, 2010 2:06 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Strange always true conditional in tcp_in.c
Lou Cypher wrote:
The case above isn't always true, in fact it yields false when
pcb-dupacks == 0xFF.
May
I wonder if there are other similar cases lurking in the code that we
also need to fix. Perhaps the original poster (John Carter) whose
compiler was warning about this could make a list and file a bug report?
I think mixing chars with ints or longs should be reviewed although
truncation warnings
On line 883 of core/tcp_in.c is the somewhat strange construct...
883 :if (pcb-dupacks + 1 pcb-dupacks)
884 : ++pcb-dupacks;
Where I believe pcb-dupacks is a u8_t.
http://cvs.savannah.gnu.org/viewvc/lwip/src/core/tcp_in.c?view=annotateroot=lwip#l883
If I
13 matches
Mail list logo
