5

I have been looking at the FlatBuffers library recently. I was looking to evaluate it for use in my project. Upon looking at flatbuffers.h, I am wondering if there is a violation of the strict-aliasing rule and if it does account for strict aliasing, can someone explain how it does this?

In previous projects, I have learned this rule the hard way, optimization gives subtle bugs which are hard to find. I've been using the placement new operator to avoid using compiler flags to account for this.

Links:

Community
  • 1
  • 1
Chap
  • 2,776
  • 24
  • 31

1 Answers1

3

Currently, reading a FlatBuffer is entirely a read only affair, so the compiler could assume no pointers alias, and this should not create any problems.

Writing a FlatBuffer is possibly trickier, but here too each piece of memory get touched just once by a single pointer, and never gets read back, except for the vtable comparisons in EndTable() (which are read by memcmp()).

Then in theory, if you first construct a FlatBuffer and then immediately read it, it could optimize across the writing and reading code, and do "evil" optimisations of the kind Linus was referring to in your link above (pretend the writing never happened).

The code is clean w.r.t. -fstrict-aliasing -Wstrict-aliasing=3, not that that gives any guarantees.

If there's any code in particular that you feel is unsafe, or have any ideas on how to better protect against aliasing issues (that are not -fno-strict-aliasing :), I'd love to hear.

Aardappel
  • 5,559
  • 1
  • 19
  • 22