RE: [csmith-project/csmith] 717b1c: Fixed a bug related to --no-math64 and --no-longlo...

["Xuejun Yang" <jxyang@cs.utah.edu>]

I think Chris said all compilers support some sort the casting through unions although the standard says that is unspecified. We should support it to some extent. 

Reading padding bits from union variables is a separate issue and is undefined, therefore should be avoided. To illustrate the rules in my previous email that could be used to avoid them , here are some examples:

union X 
{ 
   int8_t a; 
   int32_t b; 
   struct S c; 
   int* d;
   char* e;
} x;
 
x.a = 3;
int i = x.b;   // disallowed because b is wider than a

x.b = 4;
int j = x.a;   // allowed because b is wider than a

x.b = 4;
struct S s = x.c;   // disallowed. struct field reading can only occur after struct field writing

x.c = {stuct initializer} 
int k = x.a;     // disallowed. struct field reading can only occur after struct field writing

x.c = { stuct initializer }
struct S s = x.c;   // // allowed

x.b = 5;
int* p = x.d;     // this is interesting: for 64-bit platforms, this is undefined; for 32-bit, it is. The generator should disallow it anyway to be conservative

x.d = &i;
int m = x.b;     // we cannot make assumptions about the size of pointers, the same as structs, we just disable it anyway. Pointer field reading can only occur after pointer field writing
 
x.d = &i;
char* q = x.e;    // allowed, pointer are all of the same size

Note we are not making any assumptions about the platform.

-Xuejun 
 
> 
> Here's my problem with unions.  The standard says this:
> 
> "When a value is stored in a member of an object of union type, the
> bytes of the object representation that do not correspond to that member
> but do correspond to other members take unspecified values."
> 
> I think this means that if we have this union:
> 
> union {
>    int x;
>    float y;
> } u;
> 
> we can't use the union to do type casting like this:
> 
> u.x = 3;
> return u.y;
> 
> This creates a problem for us:
> 
> case 1: we follow the standard.  this is very boring.
> 
> case 2: We don't follow the standard and we do generate code that does
> type casts using unions.  I think compilers support this.  Now we have
> to know alignment and size information for the target platform.  This
> makes Csmith output non-portable in two ways.  First, it will be
> specific to that target.  Second, it won't conform to the standard.
> 
> John