Date: Sat, 5 Aug 2017 10:42:43 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Bruce Evans <brde@optusnet.com.au> Cc: Hans Petter Selasky <hps@selasky.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r321920 - head/sys/sys Message-ID: <20170805074243.GX1700@kib.kiev.ua> In-Reply-To: <20170805112924.W1055@besplex.bde.org> References: <201708021014.v72AEHEk061037@repo.freebsd.org> <f7a4a90c-f1d8-b381-27fe-3cf76b574a29@selasky.org> <37abc595-c80e-a8da-04a8-815f42c634de@selasky.org> <20170802135455.GG1700@kib.kiev.ua> <20170803122015.Q1093@besplex.bde.org> <20170803075747.GJ1700@kib.kiev.ua> <20170803180419.R2314@besplex.bde.org> <20170803120729.GO1700@kib.kiev.ua> <20170805112924.W1055@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 ? 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. So are you fine with the posted patch to sys/types.h ?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170805074243.GX1700>