Object alignment and byte boundaries

Must objects be located at a byte boundary determined by their alignment requirement? For example given this code

struct alignas(16) A { int x; }; // alignment requirement is 16

int main
{
    A a[2];
}

must a[0] and a[1] be located at a 16 byte boundary? In other words, are the lower four bits of each address guaranteed to be zero?

I would have thought so, but the C++ standard seems to say something different

> 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.

reference.

If I am reading that correctly it merely says that the difference between the addresses of a[0] and a[1] must be 16. The addresses themselves could be anything.

This is a far less useful definition (for me at least) so I thought I should check with the experts.

> In other words, are the lower four bits of each address guaranteed to be zero?

The problem is that the question isn't well-defined. What do you mean with bits of the address? There is no definition for that in the standard.

An address is not an integer value. It is just an abstract property attached uniquely to each byte of storage, without any additional mathematical structure besides identity, except that locally, but not necessarily globally, there may be a linear order inherited by successive bytes of storage. So there are no bits in the sense of a binary representation of the address' value. But the linear order allows one to, locally, talk about distance between bytes of storage or addresses which is what is used in your quoted definition of alignment.

Maybe you mean bits in the sense of the object representation of a pointer value that represents a given address, but besides being implementation-defined, the representation doesn't even need to be the same for different pointer types which can still represent the same address.

Maybe you mean the result of reinterpret_casting a pointer value to an integer value and then looking at its lowest bits in its binary representation, but the mapping of pointer values to addresses in such a cast is also completely implementation-defined, aside from a round-trip conversion giving back the original pointer value.

So the question cannot generally be answered and is a detail of the C++ implementation, although it should usually be determined by the target machine's architecture as the standard mentions in a note in [expr.reinterpret.cast]

> It is intended to be unsurprising to those who know the addressing structure of the underlying machine.

But that can look differently on different machines. For example there doesn't need to be a single flat address space.

Similarly

> must a[0] and a[1] be located at a 16 byte boundary?

isn't clear on what "boundary" means. However, what the standard does guarantee is that both a[0] and a[1]'s addresses will satisfy the alignment 16 and every weaker (i.e. smaller value) alignment supported by the implementation.

The alignment requirements described in the C++ standard are designed to accommodate hardware requirements (including efficiency) for objects to be located at addresses that are multiples of some alignment requirement. However, there is no way to express this in strict C++ because the pointer/address semantics specified by the standard do not provide any way to divide addresses or otherwise test whether an address is a multiple of a number.

Because C++ uses a memory model in which objects are composed of bytes, arrays of objects can be formed, and subtraction of pointers is defined, the distances between objects are visible. So the C++ standard describes alignment requirements in terms of these distances, that being the best available description in its model.

Recapping, there is no operation in C++ that is strictly defined in the C++ standard that would tell you whether an address were a multiple of some alignment requirement A. There are operations that will tell you whether the distance between two objects (notably two elements in an array) are separated by a multiple of A bytes. That distance-between-objects is what is visible in C++, so it is what the standard describes.

It is true a program can convert a pointer to an integer type and, in common C implementations, can observe the address that appears in the integer type. However, the details of pointer-to-integer conversion are implementation-defined. An address that is a multiple of an alignment requirement for machine purposes is not required by the C++ standard to convert to an integer that is a multiple of that alignment requirement.

Theoretically, one could make a C++ implementation in which all pointers with low bits 000 mapped to hardware addresses with bits 101, and so on for 001 mapping to 110, and so on. The hardware would see the aligned address, but any program running in the C++ implementation would, when it converted a pointer to an integer, see the pre-mapped address. An object with an alignment requirement of four bytes could have address 1003 in the C++ model but have actual hardware address 1008. So the standard allows addresses that are in some sense not multiples of their alignment requirements, but that is not the intent.