@@ -1164,18 +1164,20 @@ sufficient, but for example standard 32-bit Windows only allocates on an
1164
1164
aligned fields.
1165
1165
1166
1166
NOTE: as of August 2024 it has been discovered that C++ writer code has been
1167
- aligning empty vectors to the size field only, even if elements where larger,
1168
- like the double type of size 8. This would cause the FlatCC verifier to
1169
- (correctly) reject these vectors because it would result in an invalid C pointer
1170
- type on some architectures. However, because this has been in effect for over
1171
- 10 years, the consensus is to have verifiers tolerate this behaviour even if
1172
- C++ will eventually fix this issue. The FlatCC verifier will be updated to
1173
- accept such buffers by default with a compile time flag to enforce the strict
1174
- behaviour as well. In principle the misaligned vectors can lead potentially
1175
- lead to undefined behaviour in agressively optimized C compilers. As of now
1176
- it appears to be safe to read such buffers on common platforms and it is
1177
- preferably to avoid additional runtime reader overhead to deal with this.
1178
- For more, see [ FlatCC #287 ] , [ Google Flatbuffers #8374 ] .
1167
+ aligning empty vectors to the size field only, even if elements require
1168
+ greater alignment like the double type which requires 8. This would cause the
1169
+ FlatCC verifier to (correctly) reject these vectors because it would result
1170
+ in an invalid C pointer type on some architectures. However, because this has
1171
+ been in effect for over 10 years, the consensus is to have verifiers tolerate
1172
+ this behaviour even if C++ will eventually fix this issue. The FlatCC
1173
+ verifier has been updated to accept such buffers by default with an optional
1174
+ compile time flag to enforce the strict behaviour as well
1175
+ (` FLATCC_ENFORCE_ALIGNED_EMPTY_VECTORS ` ). In principle the misaligned vectors
1176
+ can lead potentially lead to undefined behaviour in agressively optimized C
1177
+ compilers. As of now it appears to be safe to read such buffers on common
1178
+ platforms and it is preferable to avoid additional runtime reader overhead to
1179
+ deal with this. For more, see [ FlatCC #287 ] , [ Google Flatbuffers #8374 ] ,
1180
+ [ FlatCC #289 ] .
1179
1181
1180
1182
1181
1183
### Potential Name Conflicts
@@ -2718,3 +2720,4 @@ See [Benchmarks]
2718
2720
[ WebKit Style ] : https://webkit.org/code-style-guidelines/
2719
2721
[ FlatCC #287 ] : https://github.com/dvidelabs/flatcc/issues/287
2720
2722
[ Google Flatbuffers #8374 ] : https://github.com/google/flatbuffers/issues/8374
2723
+ [ FlatCC #289 ] : https://github.com/dvidelabs/flatcc/issues/289
0 commit comments