[lwip-devel] [bug #51447] Sequence number comparisons invoke undefined behavior

[Ambroz Bizjak]

Follow-up Comment #4, bug #51447 (project lwip):

C99 standard says this:

------
6.3.1.3 Signed and unsigned integers

1 When a value with integer type is converted to another integer type other
than _Bool, if
the value can be represented by the new type, it is unchanged.

2 Otherwise, if the new type is unsigned, the value is converted by repeatedly
adding or
subtracting one more than the maximum value that can be represented in the new
type
until the value is in the range of the new type.49)

3 Otherwise, the new type is signed and the value cannot be represented in it;
either the
result is implementation-defined or an implementation-defined signal is
raised.
------

In other words, converting any integer type to some unsigned integer type is
always safe (modulo reduction), but converting to a signed integer type is
not. It is not literally undefined behavior but still not something one should
rely on.

I'm not saying the current macro gives incorrect results just that it invokes
implementation-defined behavior according to the C standard. I think its
behavior is perfectly sane otherwise (and equivalent to the solutions I
gave).

Consider the case where a is 0xFFFFFFFF and b is 0. Then
((u32_t)(a)-(u32_t)(b)) has value 0xFFFFFFFF (and type u32_t or something
wider that can represent any u32_t in case of promotions). Then,
(s32_t)((u32_t)(a)-(u32_t)(b)) invokes implementation-defined behavior because
0xFFFFFFFF cannot be represented in s32_t.


    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?51447>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/