You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
I just wanted to add that unaligned empty vectors means vectors aligned to size 4 because the size field requires that alignment, and for what we know by now, the issue is only above 4. Hence verifiers should still require at least 4 bytes alignment.
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
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 toT
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.
The text was updated successfully, but these errors were encountered: