[csmith-dev] Alignment of struct members cause target dependent checksum
John Regehr
regehr at cs.utah.edu
Wed Jun 12 10:35:56 MDT 2013
Yang, can you explain this option?
Kees, it does not look to me like this option will be useful for you--
it seems to be a way to make more risky union code, as opposed to safer
union code.
How about just turning off unions when you use Csmith?
John
On 06/12/2013 05:21 AM, Kees Bakker wrote:
> On 05-06-13 19:16, John Regehr wrote:
>>> Incidentally, John, I was also surprised that Csmith would generate
>>> code that writes to a union member and then reads back from a
>>> different (and not even equivalent) member. On reflection I agree this
>>> might be useful, but shouldn't there at least be a command-line switch
>>> to prevent Csmith from generating undefined behavior? (If Kees
>>> described the problem correctly, the test program was definitely UB.)
>>
>> This is one of those things that is technically undefined but common
>> compilers (at least GCC and Clang, probably more) provide well-defined
>> behavior that we wanted to test. In other words, the GCC developers
>> guarantee that type punning via union works "as expected." In fact,
>> there are optimization passes that propagate values through these
>> sorts of type puns (I'm actually working on a blog post about this).
>>
>> There are a few random union-related command line options, I'm not
>> sure if the one you want is there, but if it's not I would imagine
>> that we could add it. We spent quite a bit of time on unions!
>>
>> John
>
> Can you perhaps explain what this option does?
>
> --union-read-type-sensitive | --no-union-read-type-sensitive: allow |
> disallow reading an union field when there is no risk of reading padding
> bits (enabled by default).
>
More information about the csmith-dev
mailing list