Issue originally discovered here: dvidelabs/flatcc#287
(please read that fully for details).
The short of it is that a [T] (where sizeof(T) > 4, e.g. double) has so far always been aligned to 4 (for the size field) in the specific case of empty vectors.
This may seem benign since there is no T element to access, but at least in C/C++ this generates unaligned pointers (when calling e.g. Vector::data() whose mere existence, even if never accessed, can be undefined behavior (C) or generate an unspecified value (C++). While in practice no compiler/hardware causes trouble with this (currently), for the long term correctness of FlatBuffers it may be better to also align to T as the code originally intended.
Verifiers and other code must however always work with these unaligned empty vectors given how much data & code is in the wild.
For details of what that would entail, again, see above link.
Issue originally discovered here: dvidelabs/flatcc#287
(please read that fully for details).
The short of it is that a
[T](wheresizeof(T) > 4, e.g.double) has so far always been aligned to4(for the size field) in the specific case of empty vectors.This may seem benign since there is no
Telement to access, but at least in C/C++ this generates unaligned pointers (when calling e.g.Vector::data()whose mere existence, even if never accessed, can be undefined behavior (C) or generate an unspecified value (C++). While in practice no compiler/hardware causes trouble with this (currently), for the long term correctness of FlatBuffers it may be better to also align toTas the code originally intended.Verifiers and other code must however always work with these unaligned empty vectors given how much data & code is in the wild.
For details of what that would entail, again, see above link.