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
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Reply via email to