[csmith-dev] Alignment of struct members cause target dependent checksum

[Arthur O'Dwyer]

On Wed, Jun 5, 2013 at 11:14 AM, John Regehr <regehr at cs.utah.edu> wrote:
>> described the problem correctly, the test program was definitely UB.)
>
> Actually I'm not sure this is true.  Can you justify this claim, Arthur?  My
> read of 6.2.6.1.7 in C99 and C11 is that it's unspecified.

Hm. My kneejerk "definitely UB" was based on the situation before DR
283. (Yikes, I'm turning into one of those language pedants whose
pedantry ossified ten years ago!)  The C11 standard incorporates the
footnote issued in response to DR 283:

6.5.2.3#3, footnote 95:
> If the member used to read the contents of a union object is not
> the same as the member last used to store a value in the object,
> the appropriate part of the object representation of the value is
> reinterpreted as an object representation in the new type as
> described in 6.2.6 (a process sometimes called ‘‘type punning’’).
> This might be a trap representation.

So I retract my "definitely UB" claim. I think the actual situation is:
- the byte-sequence at that location is unspecified;
- for any given byte-sequence, its interpretation is implementation-defined;
- certain implementation-defined byte-sequences ("trap
representations") will give you undefined behavior;
- but there are no trap representations on sane platforms such as x86.

The fact that the stored byte-sequence is "unspecified" (6.2.6.1#6)
means that the implementation doesn't have to make a consistent
choice; it's totally okay for the behavior of Kees' test case at -O1
to differ from its behavior at -O2. However, it's also true that the
GCC or Clang developers might consider any such differences to be
fix-worthy bugs.

Derek sent his reply as I was composing this one... Derek, unless
you're referring to trap representations (which we can agree don't
apply in this case) or using "bite" as a synonym for something less
severe than UB, I actually agree more with John than with you.

–Arthur