Writing into the last byte of a class - c++

Question

Given a standard layout class with standard layout members such as:
struct foo {
int n;
int m;
unsigned char garbage;
};
will it always be safe, according to the standard, to write in the last byte of the struct without writing into the memory areas of n and m (but possibly writing into garbage)? E.g.,
foo f;
*(static_cast<unsigned char *>(static_cast<void *>(&f)) + (sizeof(foo) - 1u)) = 0u;
After spending some time reading the C++11 standard, it seems to me like the answer might be yes.
From 9.2/15:
Nonstatic data members of a (non-union) class with the same access control (Clause 11) are allocated so
that later members have higher addresses within a class object. The order of allocation of non-static data
members with different access control is unspecified (11). Implementation alignment requirements might
cause two adjacent members not to be allocated immediately after each other; so might requirements for
space for managing virtual functions (10.3) and virtual base classes (10.1).
Hence, the garbage member has a higher address than the other two members (which are stored contiguously themselves as they have standard layout), and the last byte of the struct must hence either belong to garbage or be part of the final padding.
Is this reasoning correct? Am I meddling with the f object lifetime here? Is writing into padding bytes a problem?
EDIT
In reply to the comments, what I am trying to achieve here has to do with a variant-like class I am writing.
If proceed in a straightforward way (i.e., place an int member in the variant class to record which type is being stored), the padding will make the class almost 50% bigger than it needs to be.
What I am trying to do is to make sure that every last byte of each class type I am going to store in the variant is writable, so I can incorporate the storage flag into the raw storage (aligned raw char array) I am using in the variant. In my specific case, this eliminates most of the wasted space.
EDIT 2
As an actual example, consider these two classes to be stored in a variant on a typical 64-bit machine:
// Small dynamic vector class storing 8-bit integers.
class first {
std::int8_t *m_ptr;
unsigned short m_size_capacity; // Size and capacity packed into a single ushort.
};
// Vector class with static storage.
class second {
std::int8_t m_data[15];
std::uint8_t m_size;
};
class variant
{
char m_data[...] // Properly sized and aligned for first and second.
bool m_flag; // Flag to signal which class is being stored.
};
The size of these two classes is 16 on my machine, the extra member needed in the variant class makes the size go to 24. If I now add the garbage byte in the end:
// Small dynamic vector class storing 8-bit integers.
class first {
std::int8_t *m_ptr;
unsigned short m_size_capacity; // Size and capacity packed into a single ushort.
unsigned char m_garbage;
};
// Vector class with static storage.
class second {
std::int8_t m_data[14]; // Note I lost a vector element here.
std::uint8_t m_size;
unsigned char m_garbage;
};
The size of both classes will still be 16, but if now I can use the last byte of each class freely I can do away with the flag member in the variant, and the final size will still be 16.

Answer 1

Instead, you should put the tag first, followed by the other small members.
// Small dynamic vector class storing 8-bit integers.
struct first
{
unsigned char m_tag;
std::uint8_t m_size;
std::uint8_t m_capacity;
std::int8_t *m_ptr;
};
// Vector class with static storage.
struct second
{
unsigned char m_tag;
std::uint8_t m_size;
std::int8_t m_data[14];
};
Then, the language rules allow you to put these into a union and use either one to access m_tag, even if that wasn't the "active" member of the union, because the initial layout is the same (special rule for common initial sequence of members).
union tight_vector
{
first dynamic;
second small_opt;
};
tight_vector v;
if (v.dynamic.m_size < 4) throw std::exception("Not enough data");
if (v.dynamic.m_tag == DYNAMIC) { /* use v.dynamic */ }
else { /* use v.small_opt */ }
The rule in question is 9.2/18:
If a standard-layout union contains two or more standard-layout structs that share a common initial sequence, and if the standard-layout union object currently contains one of these standard-layout structs, it is permitted to inspect the common initial part of any of them. Two standard-layout structs share a common initial sequence if corresponding members have layout-compatible types and either neither member is a bit-field or both are bit-fields with the same width for a sequence of one or more initial members.

Answer 2

Yes, in C++ any object, including a class, is represented as a series of addressable char objects ("bytes"), and objects declared in sequence in a class without intervening access specifiers have sequentially ascending addresses. Therefore storage for garbage must have a higher address (when addressed as char *) than n or m.
In theory the compiler could store a base class at the end of the object, or something like a vtable pointer, but in practice such things always go into the beginning for the sake of simplicity. I'm not sure what the standard guarantees about the size of a standard-layout class, which would pertain to whether padding may be added, which would have implications for whether an implementation could rely on presence of padding for some purpose, but it probably comes down to the implementation being allowed to use padding which happens to be there, but it can't add any (and access would perhaps not be simple or efficient anyway).
What I am trying to do is to make sure that every last byte of each class type I am going to store in the variant is writable
How is this different from using the garbage member itself? If you know it's there, presumably you can simply access it.

Answer 3

The last byte of the struct will not be part of n and m, but how do you know the compiler hasn't stored something else in the last byte, such as type information?
I don't recall the standard guaranteeing any such thing. Only that a memcpy of sizeof(T) into and out will result in the same value, which doesn't mean that the final byte doesn't hold information.