[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