svn commit: r321920 - head/sys/sys

[Bruce Evans]

On Sat, 5 Aug 2017, Konstantin Belousov wrote:

> On Sat, Aug 05, 2017 at 12:26:03PM +1000, Bruce Evans wrote:
>>> +#define	minor(x)	((int)(x))
>>
>> Another nice simplification.  Strictly, it should be (int)(dev_t)(x) since
>> the pseudo-prototype says that the arg is converted to dev_t, but yesterday
>> I couldn't see any differences even for exotic x and exotic arches.
>>
>> Today I can see some difference for exotic x and perverse implementations.
>> E.g., x with extra bits in a large signed integer type to invoke
>> implementation-defined behaviour, and a perverse implementation that
>> truncates to 0 for direct conversion to int but does the right thing
>> for indirect conversion).  But we depend on the implementation doing
>> the right thing for other casts to int.
>>
>> Also, if dev_t == uintptr_t, it is valid for the caller to keep dev_t's
>> in void *'s internally but not to pass void * to minor() or major()
>> according to the prototype.  However, casting in the macros breaks the
>> warning for this.  I think pure macros should not cast their args or
>> pretend to have prototypes, but require callers to pass args of supported
>> types.  The old dev_t macros were closer to this -- they have expressions
>> like ((x) << 8) which will fail if x is not an integral type or give
>> wrong results ix x has extra bits.
> So you are arguing to keep the & 0xffffffff operation ?

No, I don't want to go that deep.

> I think this is not needed, since your note about cast being equivalent
> holds for all supported architectures and I do not see anywhere a contract
> for the operations to work on non-dev_t.

The pseudo-prototypes look like they provide such a contract.  They must be
read sort of backwards as saying that it is the caller's responsibility
to pass args of the type in the pseudo-prototype, like for a K&R function
or a C90 function with prototype is in scope.

> So are you fine with the posted patch to sys/types.h ?

OK.

Bruce