Re: [Boost-users] Memory mapped files

Subject: Re: [Boost-users] Memory mapped files
From: Richard Damon (Richard_at_[hidden])
Date: 2019-01-24 12:45:19

On 1/23/19 9:12 AM, Niall Douglas via Boost-users wrote:
>> C++ make NO guarantee that in-memory organization of data structures
>> will match between different architectures, and there is nothing Boost
>> can do to make those structures match between architectures.
> It's even stronger than that: the C++ standard makes no guarantee that
> in-memory representation of storage does not change between program
> executions, let alone between different compilers or architectures. To
> use mapped memory at all outside a single program execution is pure
> undefined behaviour. You are literally on your own wrt the standard.
>
> (I have a proposal in the works for WG21 SG12 which will propose how to
> add support for shared and paged memory to C and C++, but even it
> specifically excludes the ability to use storage by programs other than
> the program which constructed the objects. And even that, the standard
> requiring that the same program binary always uses the same in-memory
> representation, will be very, very controversial e.g. imagine JITed or
> translated C++ for example)
>
> Niall

While the standard doesn't explicitly define it, at least a POD which
doesn't contain pointers generally should maintain representation within
the same executable, even if run multiple times. The offsetof each of
the members is defined to be a compile time constant, so unless the
compiler uses some from of whole-program optimization to invoke the
as-if rule for structure layout, it can't be a run-time decision. The
representation of each of the fundamental members needs to be
documented, so unless the implementation documents a possible change of
representation at executable time, that will be consistent.

At a higher level, platform ABIs will generally define the
representation of structures, so that provides a stronger promise (and I
suspect all the implementations that Boost supports define themselves to
conforming to some platform ABI). This is needed for the linking
together of independently compiled modules.

Pointers will be an issue, as there is generally no assurance that the
program will run is the same memory space run to run (except on many
embedded platforms) so they would need to be fixed, and in general there
is no standard way to do this.

Non-PODs also have this issue, in part because they may include as part
of their representation pointers to related information (like the
v-table for virtual functions as an example).

-- 
Richard Damon