[csmith-dev] testing C++11 struct rules

[Xuejun Yang]

Derek, 

I think your padding code wouldn't be able to detect the race-introducing
transformation John is going after, provided the compiler masks other fields
properly when reading/writing a struct field.

-Xuejun 

-----Original Message-----
From: csmith-dev-bounces at flux.utah.edu
[mailto:csmith-dev-bounces at flux.utah.edu] On Behalf Of Derek M Jones
Sent: Friday, May 11, 2012 6:15 PM
To: csmith-dev at flux.utah.edu
Subject: Re: [csmith-dev] testing C++11 struct rules

John,

> In effect the standard is mandating byte addressing. Writing a C++11 
> compiler for a machine that cannot address bytes would be quite tricky.

The C Standard defines a byte as the smallest unit of addressable storage.
So all machines can address C bytes :-)

On one of the first 64-bit Cray machines the addressable byte was
64 bits and they did some weird stuff to subdivide this into
8 bit chunks (whose technically correct name is octet).

> The question is: how to find these bugs most effectively?

The definition:

 > struct { char a,b,c,d; } s;

needs to become:

#if BLAH
#define PADDING(p)
#else
#define PADDING(p) p[10]
#endif

struct {
        char a,PADDING(x),b,PADDING(y),c,PADDING(z),d;
        } s;

and then you compile and run the program with BLAH being true/false.  The
results should be the same.

You will probably have to do extra stuff to try and stop the optimizer
reordering fields around the padding.
Taking the address of one or more fields and using it in some weird and hard
for the compiler to figure out way ought to do it.

-- 
Derek M. Jones                  tel: +44 (0) 1252 520 667
Knowledge Software Ltd          blog:shape-of-code.coding-guidelines.com
Source code analysis            http://www.knosof.co.uk