svn commit: r317061 - in head: libexec/rpc.rstatd sys/amd64/amd64 sys/amd64/include sys/arm/arm sys/arm/include sys/arm64/include sys/cddl/contrib/opensolaris/uts/common/fs/zfs sys/compat/linprocfs...

[Bruce Evans]

On Tue, 2 May 2017, Konstantin Belousov wrote:

> On Tue, May 02, 2017 at 12:02:32PM +0200, Hans Petter Selasky wrote:
>> On 05/02/17 11:55, Konstantin Belousov wrote:
>>> +		out1 = 0xffffffff;
>>
>> Nitpicking:
>>
>> Should this be written: 0xffffffffU ??

No, 0xffffffffU should be written 0xffffffff except in very delicate code
which needs it to have type precisely u_int (and u_int has at least 32
bits, else the constant would still not be u_int).

> Compiler must do it on its own.  The constant is not representable as
> int so it is auto-promoted to unsigned int, if fitting.

It doesn't really matter here, but we must make too many assumptions and
do too many type analyses to see that it doesn't matter (or too see that
either 0xffffffff or 0xffffffffU is correct or needed, but plain
0xffffffff usually works better since it lets the compiler decide).

Here you assume <= 32-bit ints for simplicity (otherwise, 0xffffffff would
be int).  POSIX and practice also requires >= 32-bit ints.  So ints are
assumed to be precisely 32 bits, and then 0xffffffff is just a better
spelling of 0xffffffffU.

Here we only need that the constant is non-negative.  Its type is
irrelevant, so it would be a style bug to force the type to unsigned or
larger (with < 32-bit ints) using a U suffix.  All integer constants
are non-negative.  We could even spell the constant in decimal here.
It would then have type int64_t.  Spelling it in hex makes its value
clearer and allows its type to be unsigned.

Bruce