diff options
author | Xavier Leroy <xavierleroy@users.noreply.github.com> | 2018-03-30 19:07:54 +0200 |
---|---|---|
committer | GitHub <noreply@github.com> | 2018-03-30 19:07:54 +0200 |
commit | 1ee8c15657cddca0d0727865327ba154b9df45d5 (patch) | |
tree | b823c553f511253e7af83b639820c284098a5f97 /test/spass/order.h | |
parent | 6b1463c4de3ae182fac6b5f2d15248d87c2f9613 (diff) | |
download | compcert-1ee8c15657cddca0d0727865327ba154b9df45d5.tar.gz compcert-1ee8c15657cddca0d0727865327ba154b9df45d5.zip |
Turn delicate case of designated re-initialization into error (#70)
Consider:
struct P { int x, y; }
struct S { struct P p; }
struct P p0 = { 1,2 };
struct S s1 = { .p = p0; .p.x = 3 };
ISO C99 and recent versions of Clang initialize s1.p.y to 2, i.e.
the initialization of s1.p.y to p0.y implied by ".p = p0" is kept,
even though the initialization of s1.p.x to p0.x is overwritten
by ".p.x = 3".
GCC, old versions of Clang, and previous versions of CompCert
initialize s1.p.y to the default value 0. I.e. the initialization
".p = p0" is forgotten, leaving default values for the fields of .p
before ".p.x = 3" takes effect.
Implementing the proper ISO C99 semantics in CompCert is difficult,
owing to a mismatch between the intended semantics and the C.init
representation of initializers.
This commit turns the delicate case of reinitialization above
(re-initializing a member of a composite that has already been
initialized as a whole) into a compile-time error.
We will then see if the delicate case occurs in practice and needs
further attention.
Diffstat (limited to 'test/spass/order.h')
0 files changed, 0 insertions, 0 deletions