Make a new test to enforce the sizes of all structs and enums in the C API....

Make a new test to enforce the sizes of all structs and enums in the C API.

Originally, I was going to just run through and add the asserts manually after each definition, but I decided to experiment with Clang and try to automate it.  The Clang plugin I wrote and ran is here:
/home/dmichael/www/clang_plugins/PrintNamesAndSizes.cpp

I used that and some simple search/replace to make test_c_sizes.c.  The idea is that the sizes need to be consistent across platforms & compilers.  Also, if the size is consistent should (in all practical cases) imply that the alignment is also the same.  It's possible that if we added other architectures where e.g. floats are a different size, we'd need to make a 'test_c_sizes' for each platform family...  but for now, I think all our platforms have the same size for all the structs (which is nice).

I would love to add this tool somewhere, but I have no idea where (if anywhere) would make sense to put it.  If it was checked-in, we could run it periodically or as part of a gyp action to make sure we know if we change the size of something in the C ABI.

BUG=61004, 92983
TEST=test_c_sizes.c

Closing uncommitted;  I broke this up in to these 2:
http://codereview.chromium.org/5730003
http://codereview.chromium.org/5730004

[dmichael(do not use this one), 2010-11-24 20:18:03]

This may be an insane or brilliant approach;  I'm not sure which.  I understand
it may need some refinement, but let me know what you think about this path of
generating the static assertions to a test (instead of manually sprinkling them
in the API code).

[brettw, 2010-11-24 22:36:40]

I guess this is OK. It's nice that it doesn't miss anything, but it sucks not
having the size right next to the definition. I bet people will forget to update
this file when they make a change and this will be the source of some annoyance.

I would check in your clang script in ppapi/tests/clang or something, and put a
rather detailed readme in there.

http://codereview.chromium.org/5340003/diff/11001/ppapi/c/pp_macros.h
File ppapi/c/pp_macros.h (right):

http://codereview.chromium.org/5340003/diff/11001/ppapi/c/pp_macros.h#newcode64
ppapi/c/pp_macros.h:64: typedef enum { int a; } Foo;
What does declaring an int inside an enum mean? Why did you change this?

http://codereview.chromium.org/5340003/diff/11001/ppapi/tests/test_c_sizes.c
File ppapi/tests/test_c_sizes.c (right):

http://codereview.chromium.org/5340003/diff/11001/ppapi/tests/test_c_sizes.c#...
ppapi/tests/test_c_sizes.c:5: * This test simply includes all the C headers to
ensure they compile with a C
This comment is wrong.

[dmichael(do not use this one), 2010-11-24 23:23:15]

I saw a lot of failures on the Windows & Mac trybots due to the sizes of
pointers (maybe just function pointers) being different.  I updated my plugin to
ignore pointer types, function pointer types, and anything that didn't start
with "PP_", and I still get a handful of issues.  For example, PP_Var appears to
be 16 bytes when compiled for 64-bit linux and 12 bytes for 32-bit linux.  I can
'fix' that with some padding, but if it's always the same for a given
platform/architecture/compiler, it might not really be wrong.   Function
pointers appear to be different sizes on Linux vs Win/Mac.  That's not a
problem, and we couldn't really fix it.  So it kind of appears that we will need
to enforce the size in a way that's dependent on platform in some fashion.

I would actually be able to make my Clang plugin stick the macros in the right
places, if that's what you would prefer.  But...  given that in some cases I
think we will have multiple 'correct' sizes (e.g., function pointers or structs
that contain them), I think that might be ugly.

I can do some more investigation after the holiday.  Please feel free to hit me
up with any more suggestions...  there could be some other handy uses for Clang,
like Neb's fingerprinting idea or like enforcing naming conventions.  (e.g.:  "I
see you're defining a struct that contains only function pointers.  Maybe its
name should start with PPB_ or PPP_?").

http://codereview.chromium.org/5340003/diff/11001/ppapi/c/pp_macros.h
File ppapi/c/pp_macros.h (right):

http://codereview.chromium.org/5340003/diff/11001/ppapi/c/pp_macros.h#newcode64
ppapi/c/pp_macros.h:64: typedef enum { int a; } Foo;
On 2010/11/24 22:36:40, brettw wrote:
> What does declaring an int inside an enum mean? Why did you change this?
I changed it to enum just because enums are more likely to be typedefed and
therefore be passed to this macro.  I just didn't look carefully when I changed
it.  I just changed it back (and fixed up the example for the new ENUM macro
below).

http://codereview.chromium.org/5340003/diff/11001/ppapi/tests/test_c_sizes.c
File ppapi/tests/test_c_sizes.c (right):

http://codereview.chromium.org/5340003/diff/11001/ppapi/tests/test_c_sizes.c#...
ppapi/tests/test_c_sizes.c:5: * This test simply includes all the C headers to
ensure they compile with a C
On 2010/11/24 22:36:40, brettw wrote:
> This comment is wrong.
Thanks, I tried to improve it.

[neb at google, 2010-11-25 02:39:24]

It's strange to me that function pointers are different sizes. That can be
true for member-function pointers (and on Harvard architecture machines),
but on x86 & ARM regular function pointers should be one word.

[dmichael(do not use this one), 2010-11-29 21:04:53]

On 2010/11/25 02:39:24, neb at google wrote:
> It's strange to me that function pointers are different sizes. That can be
> true for member-function pointers (and on Harvard architecture machines),
> but on x86 & ARM regular function pointers should be one word.
I think (but am not certain) that the Linux trybot is building 64-bits while the
Mac and Windows trybots are building 32-bits.  That accounts for the difference.

I uploaded another refinement that expects different sizes in 32-bit vs 64-bit
for some structs.  See ppapi/tests/test_c_sizes.c if you're interested.  This
makes the Mac trybot pass, but not Windows :-(
http://build.chromium.org/p/tryserver.chromium/builders/linux/builds/4018
http://build.chromium.org/p/tryserver.chromium/builders/mac/builds/3975
http://build.chromium.org/p/tryserver.chromium/builders/win/builds/4689

I'm not totally clear on the implications of this yet.  I think that it is not a
problem for trusted PPAPI plugins.  But I think we're in a situation where the
current NaCl strategy for proxying (which is mostly memcpy) is not going to
cover some of these types (most of which are not proxied yet anyway) in their
current form.  Part of the problem here is that I think we load 64-bit nexes on
64-bit Windows, even though Chrome is only built in 32-bits for Windows.  I
think we're going to need to either (a) adjust types that have inconsistent size
or (b) start pickling ppapi data that is proxied for NaCl.

I'm still gathering info, but thought you might want an update.

Obviously not looking for LGTM yet on this CL.

[dmichael(do not use this one), 2010-11-30 20:20:27]

Okay, I've got clean try runs now, and I also made the size checks work on NaCl.
 But this requires some ugly conditional compilation.  There are basically 3
equivalent sets of platforms.  Most types are consistent across all of them, but
some types aren't.
-32-bit Linux/Mac
-32-bit Windows, NaCl 32/64
-64-bit Linux/Mac/Windows
See http://codereview.chromium.org/5340003/diff/77001/ppapi/tests/all_c_sizes.h
for the special cases.

A few of the differences are because of pointer types in the struct (e.g.,
PP_ClassProperty has a const char* 'name' and 3 function pointers).  I think we
can safely leave these be;  in terms of NaCl proxy code, they will have to be
handled more specially anyway.

Most of the differences are due to alignment of 8-byte types being different on
32-bit Linux/Mac vs Win32/NaCl.  The most worrisome is PP_Var, but it turns out
that the current NaCl proxy code already 'pickles' it to work around the
difference.

So I think the most important question is:  do we want to make the sizes of
these types consistent across platforms?  Or do we want to do platform-dependent
size checking for all of them?

Here's a proposal, let me know what you think:
* For structs that contain no pointers:
  * Pad them to make the size consistent across platforms.
  * Move the compile assertion to just after the struct definition for these
types. (do this for enums too)
* For structs that have pointers:
  * Do conditional compilation to ensure the sizes are:
    * Consistent on 32-bit platforms (+NaCl 64)
    * Consistent on 64-bit platforms (except NaCl 64)
  * Keep the compile assertion in a separate test as this CL currently has.
  * Add checking for all other structs (e.g. PPB_ and PPP_) to make sure if any
functions are added, we remember to change the version string.

The major downside with this is that PP_Var would change from 12 bytes to 16
bytes on Linux and Mac 32-bit, which will require updating a bunch of version
strings and will cause version headaches (e.g. older chrome won't work with
recent plugin builds and vice-versa).  The other structs that would change size
wouldn't have as widespread of an impact.  I think it's a question of how badly
we want the sizes to be consistent.  We on NaCl want them to be consistent, but
we can work around it if they're not (and I think we already are working around
the issue for PP_Var).

(Still TODO:  Clean up the Clang plug-in and check it in with a good README, per
Brett's suggestion.  I'm waiting until the other questions are resolved before
doing that).

[brettw, 2010-11-30 20:45:44]

On Tue, Nov 30, 2010 at 12:20 PM,  <dmichael@google.com> wrote:
> Okay, I've got clean try runs now, and I also made the size checks work on
> NaCl.
>  But this requires some ugly conditional compilation.  There are basically 3
> equivalent sets of platforms.  Most types are consistent across all of them,
> but
> some types aren't.
> -32-bit Linux/Mac
> -32-bit Windows, NaCl 32/64
> -64-bit Linux/Mac/Windows
> See
> http://codereview.chromium.org/5340003/diff/77001/ppapi/tests/all_c_sizes.h
> for the special cases.
>
> A few of the differences are because of pointer types in the struct (e.g.,
> PP_ClassProperty has a const char* 'name' and 3 function pointers).  I think
> we
> can safely leave these be;  in terms of NaCl proxy code, they will have to
> be
> handled more specially anyway.
>
> Most of the differences are due to alignment of 8-byte types being different
> on
> 32-bit Linux/Mac vs Win32/NaCl.  The most worrisome is PP_Var, but it turns
> out
> that the current NaCl proxy code already 'pickles' it to work around the
> difference.
>
> So I think the most important question is:  do we want to make the sizes of
> these types consistent across platforms?  Or do we want to do
> platform-dependent
> size checking for all of them?
>
> Here's a proposal, let me know what you think:
> * For structs that contain no pointers:
>  * Pad them to make the size consistent across platforms.
>  * Move the compile assertion to just after the struct definition for these
> types. (do this for enums too)
> * For structs that have pointers:
>  * Do conditional compilation to ensure the sizes are:
>    * Consistent on 32-bit platforms (+NaCl 64)
>    * Consistent on 64-bit platforms (except NaCl 64)
>  * Keep the compile assertion in a separate test as this CL currently has.
>  * Add checking for all other structs (e.g. PPB_ and PPP_) to make sure if
> any
> functions are added, we remember to change the version string.

I think this sounds like a good proposal.


> The major downside with this is that PP_Var would change from 12 bytes to 16
> bytes on Linux and Mac 32-bit, which will require updating a bunch of
> version
> strings and will cause version headaches (e.g. older chrome won't work with
> recent plugin builds and vice-versa).

I think this is OK, we've had to do this for some things in the past.

Brett

[neb, 2010-12-08 23:44:46]

I don't recall that we have pointers in structs on any performance-critical
places - can we make structs the same size on 32 and 64? Seems like it has a
potential to make our lives easier.

On 2010/11/30 20:45:44, brettw wrote:
> On Tue, Nov 30, 2010 at 12:20 PM,  <mailto:dmichael@google.com> wrote:
> > Okay, I've got clean try runs now, and I also made the size checks work on
> > NaCl.
> > &nbsp;But this requires some ugly conditional compilation. &nbsp;There are
basically 3
> > equivalent sets of platforms. &nbsp;Most types are consistent across all of
them,
> > but
> > some types aren't.
> > -32-bit Linux/Mac
> > -32-bit Windows, NaCl 32/64
> > -64-bit Linux/Mac/Windows
> > See
> > http://codereview.chromium.org/5340003/diff/77001/ppapi/tests/all_c_sizes.h
> > for the special cases.
> >
> > A few of the differences are because of pointer types in the struct (e.g.,
> > PP_ClassProperty has a const char* 'name' and 3 function pointers). &nbsp;I
think
> > we
> > can safely leave these be; &nbsp;in terms of NaCl proxy code, they will have
to
> > be
> > handled more specially anyway.
> >
> > Most of the differences are due to alignment of 8-byte types being different
> > on
> > 32-bit Linux/Mac vs Win32/NaCl. &nbsp;The most worrisome is PP_Var, but it
turns
> > out
> > that the current NaCl proxy code already 'pickles' it to work around the
> > difference.
> >
> > So I think the most important question is: &nbsp;do we want to make the
sizes of
> > these types consistent across platforms? &nbsp;Or do we want to do
> > platform-dependent
> > size checking for all of them?
> >
> > Here's a proposal, let me know what you think:
> > * For structs that contain no pointers:
> > &nbsp;* Pad them to make the size consistent across platforms.
> > &nbsp;* Move the compile assertion to just after the struct definition for
these
> > types. (do this for enums too)
> > * For structs that have pointers:
> > &nbsp;* Do conditional compilation to ensure the sizes are:
> > &nbsp; &nbsp;* Consistent on 32-bit platforms (+NaCl 64)
> > &nbsp; &nbsp;* Consistent on 64-bit platforms (except NaCl 64)
> > &nbsp;* Keep the compile assertion in a separate test as this CL currently
has.
> > &nbsp;* Add checking for all other structs (e.g. PPB_ and PPP_) to make sure
if
> > any
> > functions are added, we remember to change the version string.
> 
> I think this sounds like a good proposal.
> 
> 
> > The major downside with this is that PP_Var would change from 12 bytes to 16
> > bytes on Linux and Mac 32-bit, which will require updating a bunch of
> > version
> > strings and will cause version headaches (e.g. older chrome won't work with
> > recent plugin builds and vice-versa).
> 
> I think this is OK, we've had to do this for some things in the past.
> 
> Brett

[dmichael(do not use this one), 2010-12-09 00:34:59]

On Wed, Dec 8, 2010 at 4:44 PM, <neb@chromium.org> wrote:

> I don't recall that we have pointers in structs on any performance-critical
> places - can we make structs the same size on 32 and 64? Seems like it has
> a
> potential to make our lives easier.
>
 It's possible...  but a bit ugly.  We'd probably have to do conditional
compilation, maybe wrapped in a macro, sort of like this:
struct Foo {
  void* ptr1;  PP_PAD_POINTER(ptr1)  /* compiles to a int32_t on 32-bit,
nothing otherwise. */
  void* ptr2;  PP_PAD_POINTER(ptr2)
};

I could see doing this for data structs, but it would seem weird to me for
interface structs.  And I kind of like the idea of checking them, just so
we're made aware when they change.

I'm finally wrapping this up (I forgot about having to change interface
strings :-(, but I'm almost done with another clang plugin to tell me which
interfaces are affected by a change in a given set of structs).  Maybe we
can revisit this when I have a more concrete implementation uploaded.


> On 2010/11/30 20:45:44, brettw wrote:
>
>> On Tue, Nov 30, 2010 at 12:20 PM,  <mailto:dmichael@google.com> wrote:
>> > Okay, I've got clean try runs now, and I also made the size checks work
>> on
>> > NaCl.
>> > &nbsp;But this requires some ugly conditional compilation. &nbsp;There
>> are
>>
> basically 3
>
>> > equivalent sets of platforms. &nbsp;Most types are consistent across all
>> of
>>
> them,
>
>> > but
>> > some types aren't.
>> > -32-bit Linux/Mac
>> > -32-bit Windows, NaCl 32/64
>> > -64-bit Linux/Mac/Windows
>> > See
>> >
>> http://codereview.chromium.org/5340003/diff/77001/ppapi/tests/all_c_sizes.h
>> > for the special cases.
>> >
>> > A few of the differences are because of pointer types in the struct
>> (e.g.,
>> > PP_ClassProperty has a const char* 'name' and 3 function pointers).
>> &nbsp;I
>>
> think
>
>> > we
>> > can safely leave these be; &nbsp;in terms of NaCl proxy code, they will
>> have
>>
> to
>
>> > be
>> > handled more specially anyway.
>> >
>> > Most of the differences are due to alignment of 8-byte types being
>> different
>> > on
>> > 32-bit Linux/Mac vs Win32/NaCl. &nbsp;The most worrisome is PP_Var, but
>> it
>>
> turns
>
>> > out
>> > that the current NaCl proxy code already 'pickles' it to work around the
>> > difference.
>> >
>> > So I think the most important question is: &nbsp;do we want to make the
>>
> sizes of
>
>> > these types consistent across platforms? &nbsp;Or do we want to do
>> > platform-dependent
>> > size checking for all of them?
>> >
>> > Here's a proposal, let me know what you think:
>> > * For structs that contain no pointers:
>> > &nbsp;* Pad them to make the size consistent across platforms.
>> > &nbsp;* Move the compile assertion to just after the struct definition
>> for
>>
> these
>
>> > types. (do this for enums too)
>> > * For structs that have pointers:
>> > &nbsp;* Do conditional compilation to ensure the sizes are:
>> > &nbsp; &nbsp;* Consistent on 32-bit platforms (+NaCl 64)
>> > &nbsp; &nbsp;* Consistent on 64-bit platforms (except NaCl 64)
>> > &nbsp;* Keep the compile assertion in a separate test as this CL
>> currently
>>
> has.
>
>> > &nbsp;* Add checking for all other structs (e.g. PPB_ and PPP_) to make
>> sure
>>
> if
>
>> > any
>> > functions are added, we remember to change the version string.
>>
>
>  I think this sounds like a good proposal.
>>
>
>
>  > The major downside with this is that PP_Var would change from 12 bytes
>> to 16
>> > bytes on Linux and Mac 32-bit, which will require updating a bunch of
>> > version
>> > strings and will cause version headaches (e.g. older chrome won't work
>> with
>> > recent plugin builds and vice-versa).
>>
>
>  I think this is OK, we've had to do this for some things in the past.
>>
>
>  Brett
>>
>
>
>
> http://codereview.chromium.org/5340003/
>

[neb, 2010-12-09 18:58:39]

> I could see doing this for data structs, but it would seem weird to me for
> interface structs.  And I kind of like the idea of checking them, just so
> we're made aware when they change.

I forgot about the interface structs completely... Alright, I take that back.

[brettw, 2010-12-09 19:03:11]

On Wed, Dec 8, 2010 at 3:57 PM, David Michael <dmichael@google.com> wrote:
>
>
> On Wed, Dec 8, 2010 at 4:44 PM, <neb@chromium.org> wrote:
>>
>> I don't recall that we have pointers in structs on any
>> performance-critical
>> places - can we make structs the same size on 32 and 64? Seems like it has
>> a
>> potential to make our lives easier.
>
>  It's possible...  but a bit ugly.  We'd probably have to do conditional
> compilation, maybe wrapped in a macro, sort of like this:
> struct Foo {
>   void* ptr1;  PP_PAD_POINTER(ptr1)  /* compiles to a int32_t on 32-bit,
> nothing otherwise. */
>   void* ptr2;  PP_PAD_POINTER(ptr2)
> };
> I could see doing this for data structs, but it would seem weird to me for
> interface structs.  And I kind of like the idea of checking them, just so
> we're made aware when they change.

Is the point of checking the size of interface structs to detect
padding problems? Otherwise, I don't see any value in checking these,
and it seems like an extra annoying step that people will have to do
(and usually forget) whenever you add or remove a function from a dev
interface.

Brett

[dmichael(do not use this one), 2010-12-09 23:09:20]

Sorry for the late response, we had a 3 hour meeting turn in to a 6 hour
meeting :-(

On Thu, Dec 9, 2010 at 12:03 PM, Brett Wilson <brettw@chromium.org> wrote:

> On Wed, Dec 8, 2010 at 3:57 PM, David Michael <dmichael@google.com> wrote:
> >
> >
> > On Wed, Dec 8, 2010 at 4:44 PM, <neb@chromium.org> wrote:
> >>
> >> I don't recall that we have pointers in structs on any
> >> performance-critical
> >> places - can we make structs the same size on 32 and 64? Seems like it
> has
> >> a
> >> potential to make our lives easier.
> >
> >  It's possible...  but a bit ugly.  We'd probably have to do conditional
> > compilation, maybe wrapped in a macro, sort of like this:
> > struct Foo {
> >   void* ptr1;  PP_PAD_POINTER(ptr1)  /* compiles to a int32_t on 32-bit,
> > nothing otherwise. */
> >   void* ptr2;  PP_PAD_POINTER(ptr2)
> > };
> > I could see doing this for data structs, but it would seem weird to me
> for
> > interface structs.  And I kind of like the idea of checking them, just so
> > we're made aware when they change.
>
> Is the point of checking the size of interface structs to detect
> padding problems?

If you're including alignment in padding problems, then yes, I think that's
what got us here.  That's the purpose for checking the size of 'data'
structs.

> Otherwise, I don't see any value in checking these,
> and it seems like an extra annoying step that people will have to do
> (and usually forget) whenever you add or remove a function from a dev
> interface.
>
> My thinking was that it would make it obvious when a function is added or
removed to a struct, so that you remember to update the interface string.
 It would make it hard to forget to do, because your compile will break if
you don't update the size.  If that is more annoying than it is valuable,
then I can easily just not check the size of interface (PPP/PPB) structs.
 Please let me know, and I'll tweak it to take that checking back out.

> Brett
>

[brettw, 2010-12-09 23:47:43]

On Thu, Dec 9, 2010 at 3:09 PM, David Michael <dmichael@google.com> wrote:
> Sorry for the late response, we had a 3 hour meeting turn in to a 6 hour
> meeting :-(
>
> On Thu, Dec 9, 2010 at 12:03 PM, Brett Wilson <brettw@chromium.org> wrote:
>>
>> On Wed, Dec 8, 2010 at 3:57 PM, David Michael <dmichael@google.com> wrote:
>> >
>> >
>> > On Wed, Dec 8, 2010 at 4:44 PM, <neb@chromium.org> wrote:
>> >>
>> >> I don't recall that we have pointers in structs on any
>> >> performance-critical
>> >> places - can we make structs the same size on 32 and 64? Seems like it
>> >> has
>> >> a
>> >> potential to make our lives easier.
>> >
>> >  It's possible...  but a bit ugly.  We'd probably have to do conditional
>> > compilation, maybe wrapped in a macro, sort of like this:
>> > struct Foo {
>> >   void* ptr1;  PP_PAD_POINTER(ptr1)  /* compiles to a int32_t on 32-bit,
>> > nothing otherwise. */
>> >   void* ptr2;  PP_PAD_POINTER(ptr2)
>> > };
>> > I could see doing this for data structs, but it would seem weird to me
>> > for
>> > interface structs.  And I kind of like the idea of checking them, just
>> > so
>> > we're made aware when they change.
>>
>> Is the point of checking the size of interface structs to detect
>> padding problems?
>
> If you're including alignment in padding problems, then yes, I think that's
> what got us here.  That's the purpose for checking the size of 'data'
> structs.
>>
>> Otherwise, I don't see any value in checking these,
>> and it seems like an extra annoying step that people will have to do
>> (and usually forget) whenever you add or remove a function from a dev
>> interface.
>>
> My thinking was that it would make it obvious when a function is added or
> removed to a struct, so that you remember to update the interface string.
>  It would make it hard to forget to do, because your compile will break if
> you don't update the size.  If that is more annoying than it is valuable,
> then I can easily just not check the size of interface (PPP/PPB) structs.
>  Please let me know, and I'll tweak it to take that checking back out.

I'm interested in Neb's opinion. It seems to me like adding or
removing a function from an interface is just as obvious as updating
the structure size, so I don't see as much benefit from this as as we
get from the more complicated and fragile non-interface structs (if
interface padding is incorrect, everything will immediately crash
anyway).

Brett

[neb, 2010-12-10 00:04:49]

> I'm interested in Neb's opinion. It seems to me like adding or
> removing a function from an interface is just as obvious as updating
> the structure size, so I don't see as much benefit from this as as we
> get from the more complicated and fragile non-interface structs (if
> interface padding is incorrect, everything will immediately crash
> anyway).
> 
> Brett

I don't see that checking the size of the structs amounts to version checking.
Changing the signature of a function, for example, is not detected. It's a nice
check to have for most other structures though, because there it does catch
non-obvious signature changes. So +1 for not doing to much work there. And no
padding, that was just silly to suggest of me.

[dmichael(do not use this one), 2010-12-10 16:36:36]

>
>
> I don't see that checking the size of the structs amounts to version
> checking.
> Changing the signature of a function, for example, is not detected.

You're right, it would only catch a subset of changes.

It's a nice
> check to have for most other structures though, because there it does catch
> non-obvious signature changes. So +1 for not doing to much work there.

It's easy on my end (with the automation I already have).  But I think I'm
hearing that it won't be helpful enough for the amount of trouble it causes
PPAPI developers.  I'll leave it out.

And no
> padding, that was just silly to suggest of me.
>
>
> http://codereview.chromium.org/5340003/
>

This CL got a little out of control, so I'm going to break it up and upload
probably 2:
-1 for adding the actual checks and massaging a few structs to be consistent
size.
-1 for adding the tools to update it automatically later. (Clang plugins +
python)