Date: Sat, 6 Apr 2019 10:48:32 -0700
From: Jason Thorpe <thor...@me.com>
Message-ID: <eb1e5026-e192-47e2-ab12-b394fe1b4...@me.com>
| The only situation I know of where it's wacky is sparc64-built-as-ILP32
| and mips64-built-as-ILP32, where register_t is 64-bit and long is 32-bit.
But that is kind of the point - from qhat I can see from a (very) quick
scan, register_t is used almost exclusively for syscall args/results
(for which it makes sense) - and those are objects which are likely being
copied to/from user space.
Just like ufetch_ptr() exists, even though a pointer is almost always
the same as an int or a long in terms of number of bits, etc, register_t
will essentially always be one or the other - but we never really know
which.
Unlike most of the other contrived types (size_t, intmax_t, ptrdiff_t)
which aren't all that frequently shunted around, register_t is, which
is why (just like ptr_t) I believe it would be one which should have its
own access functions.
But I will leave it for you to decide what is really needed there.
kre
