Is it worth mentioning that an implementation may have other
mechanisms that create storage in the manner of malloc? For example,
it'd make sense for VirtualAlloc or mmap to create implicit objects
just like the standard malloc functions.

In terms of pointer arithmetic, what becomes defined as a result?
Does the following evil code work?

struct X { int a; int b; int c; };
int does_this_return_4() {
    alignas(X) std::byte s[sizeof(X)];
    X *x = reinterpret_cast<X *>(s);
    x->c = 4;
    return (&x->a)[2];
}


The below is a silly idea I had that is admittedly extreme, but would
preserve a lot of type-based alias analysis.

A simpler memory model that might work is defining memory as scattered
arrays of bytes: Each byte has metadata specifying either "none" or a
non-byte (non-char/unsigned char/std::byte) scalar type and an offset
into that scalar type. Writing to a non-byte scalar changes the
metadata for those bytes to the type that is written. Reading scalars
as a non-byte type requires that all bytes have either "none" or a
"compatible" type with incrementally-increasing offsets starting at 0.
Writing byte types sets the type of those bytes to "none". Any byte
may be read as a byte type. Pointer arithmetic would be valid so long
as the pointer does not cross the byte array that was allocated,
except that a pointer may point one past the end of such a byte array.

Classes in this model would not factor into the type system at all;
instead, for purposes of the memory model, members of a class would
just be offsets into the byte array representing the class instance.
This would preserve such semantics as reading sockaddr::sa_family from
what was written as sockaddr_in6::sin6_family. It would also allow a
lot of other shenanigans we probably don't want to encourage.

Melissa

On Fri, Feb 9, 2018 at 11:52 AM, Richard Smith <richardsmith_at_[hidden]> wrote:
> Hi all,
>
> Please find attached a revised version of P0593 based on the excellent
> discussion and feedback at the Albuquerque meeting. Please let me know if
> you have any comments; I believe our plan was to discuss this again at
> Jacksonville, and all being well, to forward it to EWG at that meeting.
>
> Best regards,
> Richard
>
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub
>