https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #36 from David Brown <david at westcontrol dot com> ---
(In reply to Martin Sebor from comment #34)
> I think in the use case below:
>
> struct { int i; char buf[4]; } s, r;
> *(float *)s.buf = 1.;
> r = s;
>
> the aggregate copy has to be viewed as a recursive copy of each of its
> members and copying buf[4] must be viewed as a memcpy, Char is definitely
> special (it can accesses anything with impunity, even indeterminate values).
> That said, I don't think the rules allow char arrays to be treated as
> allocated storage so while the store to s.buf via float* may be valid it
> doesn't change the effective type of s.buf and so the only way to read the
> float value stored in it is to copy it byte-by-byte (i.e., copy the float
> representation) to an object whose effective type is float. Some of the
> papers that deal with the effective type rules might touch on this (e.g., DR
> 236, Clark's N1520
In bare metal embedded development, it is common to have to have a way to treat
static declared storage (like a char[] array) as a pool for dynamic storage.
Often you don't want to use standard library malloc() because of requirements
on deterministic timing, etc. What you are saying here is that this is not
possible - meaning there is no way to write such malloc replacement in normal C
code. (It is possible, I think, to use gcc extensions such as the "may_alias"
type attribute and the "malloc" function attribute. And -fno-strict-alias is
always a safe resort.) It would be /very/ nice if there were a way to declare
statically allocated pools of memory that could be doled out by user-made
functions and - like malloc'ed memory - take their effective type when used.
It would be even better if there were a standard way to say that the initial
value of such memory is "unspecified". The compiler and linker could give such
memory a static allocation (essential for small embedded systems with limited
memory, so that you can be sure of your memory usage) but there would be no
need for zeroing the memory at startup.
