Re: CVS commit: src/external/bsd/dhcpcd/dist/src

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 13 Feb 2020 02:45:44 +0000
    From:        Roy Marples <roy%marples.name@localhost>
    Message-ID:  <adc4f3fd-ebcf-ccd7-9584-11df84723b65%marples.name@localhost>

  | My understanding was if it could be promoted to an int it would be.
  | So it size_t is bigger in bits than uint16_t and int is also bigger then 
  | promotion occurs and we then have signed vs unsigned.

You're right, but I think Joerg is even more right - or I certainly hope so.

The reasoning is that when the uint16_t gets promoted to int, since int
has more bits than the uint16_t the conversion is done by filling the
low 16 bits of the int with the uint16_t value, and zero filling the rest
(that is, value preserving).   You then have a signed int.  But it is
known to be >= 0.   When that is converted to a size_t (unsigned, and
here assumed to be at least as many bits as an int .. similar reasoning
applies if not) the signed int is sign extended to fit the size_t, and then
made unsigned.   "Sign exiended" here means zero fill, as we know the
value must be >= 0 (so the sign bit must be 0).

The only slightly weird case would be if int were 16 bits, but in that case,
a uint16_t would be an unsigned int, and no promotion to int ever happens,
it simply gets promoted directly to size_t.

If I had to guess, I'd say that gcc is losing the "must be >= 0" part of
the conversion from uint16_t to int, and assuming that the int might be
negative, which would be bad for converting to a size_t.

kre