RE: [lwip-users] Strange "always true" conditional in tcp_in.c

[Bill Auerbach]

This is where C can be non-portable.  And although this paragraph is pretty
clear, there are cases where a compiler will NOT promote to int/unsigned int
when it could have because it can still get the right answer by not
promoting.  But you must assume it might in all expressions which makes this
dupacks test invalid when the type of dupacks is smaller than an int.  8-bit
compilers work harder to avoid char to int promotions because they can be
very costly - doubling the code for an expression or even adding a runtime
call or 2 with the promotion.

The portable way to do this only on 2's complement systems and only for
unsigned types is:

if (pcb->dupacks + 1 != 0)
  ++pcb->dupacks;

But if the processor has a trap for integer overflow this fails as well.

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;

C lacks the much needed compile time access to type information to allow
programs to enforce certain types and/or the signedness of types.

Bill

>-----Original Message-----
>From: address@hidden
>[mailto:address@hidden 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 <address@hidden> 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.
>Otherwise, if both operands have signed integer types or both have
>unsigned
>integer types, the operand with the type of lesser integer conversion
>rank is
>converted to the type of the operand with greater rank.
>Otherwise, if the operand that has unsigned integer type has rank
>greater or
>equal to the rank of the type of the other operand, then the operand
>with
>signed integer type is converted to the type of the operand with
>unsigned
>integer type.
>Otherwise, if the type of the operand with signed integer type can
>represent
>all of the values of the type of the operand with unsigned integer type,
>then
>the operand with unsigned integer type is converted to the type of the
>operand with signed integer type.
>Otherwise, both operands are converted to the unsigned in
>corresponding to the type of the operand with signed integer type.
>-end of quote-
>So yes, operands will be converted to int since 1 is an int.
>
>
>_______________________________________________
>lwip-users mailing list
>address@hidden
>http://lists.nongnu.org/mailman/listinfo/lwip-users