I believe this directly breaks the aliasing rules for C.

In D59455#1363642, @kib wrote:

I believe this directly breaks the aliasing rules for C.

My reading of the documentation says it is not.

https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Common-Type-Attributes.html#index-transparent_005funion-type-attribute

It will allow to pass pointer to any structure that starts with struct lock_object with calling conventions of struct lock_object.

In D59455#1363643, @glebius wrote:

In D59455#1363642, @kib wrote:

I believe this directly breaks the aliasing rules for C.

My reading of the documentation says it is not.

https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Common-Type-Attributes.html#index-transparent_005funion-type-attribute

It will allow to pass pointer to any structure that starts with struct lock_object with calling conventions of struct lock_object.

But then you access it through the first member which is the pointer to lock_object. I believe that this still breaks the C aliasing rules.
More, I do not see why trying to use this ugly gcc extension. There is C-standard _Generic() facility, which allows to enumerate allowed types for an expression and do something specific to deduced type.
I suspect that uglyness predated C11.

And, I do not understand why you don't do simply

#define callout_init_mtx(c, mtx, flags) callout_init_lock((c), &(mtx)->lock_object, (flags))

and same for all other blocking locks.

I can't see how _Generic() can do the same. AFAIK, _Generic() implies multiple different functions. My goal is the opposite - have single function that accepts arguments of different (but compatible) types.

In D59455#1363824, @glebius wrote:

I can't see how _Generic() can do the same. AFAIK, _Generic() implies multiple different functions. My goal is the opposite - have single function that accepts arguments of different (but compatible) types.

It can, and it can do even more.
But again, I do not see why do you need either the gcc union hack, or even _Generic, for the first-order implementation.

#define	callout_init_lock(c, lk, flags) _callout_init_lock((c), &(lk)->lock_object, (flags))

does it already. It works for any structure that has the lock_object member.
With _Generic(), you can typecheck:

#define	callout_init_lock1(c, lk, flags) _callout_init_lock((c), &(lk)->lock_object, (flags))
#define 		callout_init_lock(c, lk, flags) 		\
	_Generic((lk),				\
	    struct mtx: callout_init_lock1((c), (lk), (flags)),			\
	    struct rmlock: callout_init_lock1((c), (lk), (flags)),			\
	    struct rwlock: callout_init_lock1((c), (lk), (flags)))
#undef callout_init_lock1

@glebius : I appreciate what you're trying to solve, but @kib brings up a very good point.
My concern with the change is that code (especially third-party/ports code) may naïvely assume a lock type is X, when in fact it's Y after the change. Anti-patterns like this seem ripe for improper memory accesses/potential scribblers..

Any opinion if NOLOCK would be a better name than NULLLOCK?