Date: Wed, 5 Jul 2023 19:47:06 -0400
On Wed, Jul 5, 2023 at 6:54 PM Bernhard Manfred Gruber via
Std-Discussion <std-discussion_at_[hidden]> wrote:
> Hi,
>
> I am trying to figure out where the standard, specifically the object model, defines alignment and its requirements on addresses.
>
> In [basic.align]#1 it says:
> Object types have alignment requirements ([basic.fundamental], [basic.compound]) which place restrictions on the addresses at which an object of that type may be allocated. An alignment is an implementation-defined integer value representing the number of bytes between successive addresses at which a given object can be allocated.
>
> I am surprised by the second sentence, that the alignment of a type is the difference between two addresses at which objects of this type can be placed. It says nothing on the value of the addresses themselves. For that matter, values of type double could be allocated at the addresses 0x1, 0x9, 0x11, 0x19, etc.
>
> Digging deeper, I started wondering if the definition of alignment is vague out of necessity, because it seems the standard also does not define whether an address is an integer. It is described in various places that an address (represented by a pointer) can be value-preservingly converted to an integer and back, but that does not describe the nature of an address.
>
> In any way, I would be glad if someone could point me to the right place that establishes that alignment, which is defined as an integer, requires a divisibility of an address by that number.
>
> Thanks a lot!
> Bernhard
It is similarly my understanding that an 'address' is not necessarily
an integer; only differences between addresses are integers. Since
nothing specifies what exactly an address is, it's implicitly
unspecified and left to the implementation. As far as the standard is
concerned, an address is just a "thing that is associated with a byte
of memory and can be represented by a pointer", whatever that thing
may be. Compare with a 'value' of a type, which is circularly defined
as "one discrete element of an implementation-defined set of values"
([basic.types.general]/4).
Given that an address is not necessarily an integer, the
correspondence between addresses and integer values is totally
implementation-defined and does not even have to reflect the
differences between addresses. So there is no such requirement that an
integer value created from a pointer to a complete object must be a
multiple of its type's alignment requirement.
Std-Discussion <std-discussion_at_[hidden]> wrote:
> Hi,
>
> I am trying to figure out where the standard, specifically the object model, defines alignment and its requirements on addresses.
>
> In [basic.align]#1 it says:
> Object types have alignment requirements ([basic.fundamental], [basic.compound]) which place restrictions on the addresses at which an object of that type may be allocated. An alignment is an implementation-defined integer value representing the number of bytes between successive addresses at which a given object can be allocated.
>
> I am surprised by the second sentence, that the alignment of a type is the difference between two addresses at which objects of this type can be placed. It says nothing on the value of the addresses themselves. For that matter, values of type double could be allocated at the addresses 0x1, 0x9, 0x11, 0x19, etc.
>
> Digging deeper, I started wondering if the definition of alignment is vague out of necessity, because it seems the standard also does not define whether an address is an integer. It is described in various places that an address (represented by a pointer) can be value-preservingly converted to an integer and back, but that does not describe the nature of an address.
>
> In any way, I would be glad if someone could point me to the right place that establishes that alignment, which is defined as an integer, requires a divisibility of an address by that number.
>
> Thanks a lot!
> Bernhard
It is similarly my understanding that an 'address' is not necessarily
an integer; only differences between addresses are integers. Since
nothing specifies what exactly an address is, it's implicitly
unspecified and left to the implementation. As far as the standard is
concerned, an address is just a "thing that is associated with a byte
of memory and can be represented by a pointer", whatever that thing
may be. Compare with a 'value' of a type, which is circularly defined
as "one discrete element of an implementation-defined set of values"
([basic.types.general]/4).
Given that an address is not necessarily an integer, the
correspondence between addresses and integer values is totally
implementation-defined and does not even have to reflect the
differences between addresses. So there is no such requirement that an
integer value created from a pointer to a complete object must be a
multiple of its type's alignment requirement.
Received on 2023-07-05 23:47:18