Jan Beulich writes ("Re: [PATCH v9 1/5] xen: introduce ptrdiff_t, fix
uintptr_t"):
> On 12.02.19 at 02:13, <sstabell...@kernel.org> wrote:
> > -typedef unsigned int __attribute__((__mode__(__pointer__))) uintptr_t;
> > +typedef unsigned long __attribute__((__mode__(__pointer__))) uintptr_t;
>
> I don't understand this change: The mode attribute discards any width
> association derived from the specified base type.
I looked for the reference documentation for the semantics of
__attribute__((__mode__(__pointer__))). I found this in my GCC 6
manual:
'mode (MODE)'
This attribute specifies the data type for the
declaration--whichever type corresponds to the mode MODE. This in
effect lets you request an integer or floating-point type according
to its width.
You may also specify a mode of 'byte' or '__byte__' to indicate the
mode corresponding to a one-byte integer, 'word' or '__word__' for
the mode of a one-word integer, and 'pointer' or '__pointer__' for
the mode used to represent pointers.
This wording is extremely obscure, especially when read in the context
of C's insane pointer provenance rules and compiler authors' insane
interpretations of those rules.
If our goal is to avoid malicious compiler optimisation nonsense we
should not use a feature like this whose semantics might be taken to
imply that the things are really pointers.
> > +typedef long ptrdiff_t;
>
> FTR I'm unconvinced of this, or the need to use uintptr_t in the first
> place in the macros you introduce: The entire UNIX world implies
> sizeof(long) == sizeof(void*) afaik.
Please provide a reference for this assertion about sizeof(long).
Looking at http://www.unix.org/whitepapers/64bit.html LLP64 (32-bit
long, 64-bit long long, 64-bit void*) was at least contemplated in
some circles, although I haven't been able to find any Unix-like
examples besides Minix, which runs on machines with 16-bit pointers
(and its longs have to be >=32-bit).
> But if we really want to have ptrdiff_t, then I think we should either
> follow the uintptr_t model and use attribute((mode())), or we should
> leverage the compiler's __PTRDIFF_TYPE__ (and then also
> __UINTPTR_TYPE__ for uintptr_t, at least if available - not sure what
> its availability depends on, but it's conditional in gcc's
> c_stddef_cpp_builtins()).
It is not unusual for porting something like Xen to a new architecture
to involve writing a short header file with these kind of type
definitions. I don't know why we couldn't take that approach.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
