_ptr and _srcptr types
vincent at vinc17.net
Tue May 22 01:13:47 UTC 2018
On 2018-05-20 22:07:36 +0200, Niels Möller wrote:
> Vincent Lefevre <vincent at vinc17.net> writes:
> > No, pointers to different types may have different representations,
> > and in particular, different sizes.
> Hmm. I was aware that *function* pointers may use different
> representation and size than data pointers.
> But not that a data pointer can use different representation than void*.
Here's what the standard says:
28 A pointer to void shall have the same representation and
alignment requirements as a pointer to a character type.48)
Similarly, pointers to qualified or unqualified versions
of compatible types shall have the same representation and
alignment requirements. All pointers to structure types shall
have the same representation and alignment requirements as
each other. All pointers to union types shall have the same
representation and alignment requirements as each other.
Pointers to other types need not have the same representation
or alignment requirements.
48) The same representation and alignment requirements are meant
to imply interchangeability as arguments to functions, return
values from functions, and members of unions.
> If that really is the case, most occurences of NULL or (void*)0 in
> the argument list in the call of a varargs function would be
> undefined behavior, right?
Using NULL is never guaranteed to work as it can be defined as the
integer 0. If (void*)0 is used in place of (char*)0, I assume that
this is OK sue to the same representation and alignment requirements
(note 48 mentions that the goal is interchangeability, and as
I understand it, this necessary condition is also a sufficient
condition). But if same representation and alignment requirements
are not satisfied, I assume that this is undefined behavior.
Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
More information about the gmp-devel