Re: [lwip-devel] LWIP_U32_DIFF is unnecessarily complex

[Mason]

Mike Kleshov wrote:

> I missed the discussion about LWIP_U32_DIFF.

http://lists.gnu.org/archive/html/lwip-devel/2011-08/msg00041.html

cf. also
http://groups.google.com/group/comp.lang.c/browse_frm/thread/f9fe040cffd1ea6e

(A few experts hang out in comp.lang.c and comp.std.c)

> Mason, can you please provide a quote from the standard to support your 
> finding?

I think your question is equivalent to asking whether the
following statement is well-defined.

  unsigned n = -42; /*** -42 has type int ***/

3.2 CONVERSIONS
3.2.1.2 Signed and unsigned integers

   When an unsigned integer is converted to another integral type, if
the value can be represented by the new type, its value is unchanged.

   When a signed integer is converted to an unsigned integer with
equal or greater size, if the value of the signed integer is
non-negative, its value is unchanged.  Otherwise: if the unsigned
integer has greater size, the signed integer is first promoted to the
signed integer corresponding to the unsigned integer; the value is
converted to unsigned by adding to it one greater than the largest
number that can be represented in the unsigned integer type. /22/

   When an integer is demoted to an unsigned integer with smaller
size, the result is the non-negative remainder on division by the
number one greater than the largest unsigned number that can be
represented in the type with smaller size.  When an integer is demoted
to a signed integer with smaller size, or an unsigned integer is
converted to its corresponding signed integer, if the value cannot be
represented the result is implementation-defined.

> All I could find is this (from C99):
> 
> A computation involving unsigned operands can never overflow,
> because a result that cannot be represented by the resulting unsigned
> integer type is
> reduced modulo the number that is one greater than the largest value that can 
> be
> represented by the resulting type.
> 
> It mentions 'overflow' and 'reduced.' As far as I understand this, it
> does not apply to subtraction. I can see two possibilities:
> 1) The authors of the standard forgot to mention 'underflow' and
> 'increased' to handle the subtraction case.
> 2) The standard really does not specify the behaviour of unsigned
> integer underflow during subtraction, leaving it
> implementation-defined.
> Personally, I'm leaning towards 1), as it seems to make sense.
> 
> Any ideas?

-- 
Regards.