Investigate potential alignment issue

[bjornharrtell]

See dvidelabs/flatcc#210 (comment).

It is likely that this disallows zero-copy reading of invidivual buffers from a stream. I think we circumvent it everwhere now by copying buffers out from the stream into a new chunk of aligned memory but this is not optimal.

I believe it should be possible to tail pad the buffers without breaking backward compatibility. However, I would need to bump the format version a "patch" level to enforce it so that reader implementations can take advantage of it. And I think existing reader implementations doesn't have the foresight to read higher "patch" levels of the format so that should be introduced ASAP.

[bjornharrtell]

Discussed today and proper flatbuffers are always aligned to the minimum stored scalar in the buffer (size prefixed or not). There is a bug in flatcc in that it does not adhere to this.

But the problem remains due to flatgeobuf schemas having only 8 byte scalars in vectors and they can be left unset in which case the buffers can be aligned to 4 bytes instead. To avoid this in the C++ implementation of flatbuffers one can force min alignment to the desired size by fbb.TrackMinAlign(8).

[pka]

Can't find this setting in Rust https://docs.rs/flatbuffers/. So this should be tested in a Rust writer implementation.

[bjornharrtell]

@pka probably deserves a missing feature issue at https://github.com/google/flatbuffers. I will check if it's the same situation with TS, Java and C# implementations. I currently struggle with the C implementation in general but that's another story...

[bjornharrtell]

Also notable is that the GDAL implementation was made with forsight on format patch levels. It only verifies the first four bytes of the magicbytes. I've already made the specification change noted here https://github.com/flatgeobuf/flatgeobuf#specification and will when I get time ensure that my reference implementations do not get stuck on patch level 0.

[bjornharrtell]

Just to be clear - this does not cause issues with any of existing implementations AFAIK. It can potentially cause alignment related issue if a reading implementation attempt to read a feature straight from an offset in flatgeobuf in memory.

[bjornharrtell]

With #146 all impl. are lenient on patch level but only C++ can produce aligned (patch level 1) versions so this will have to remain open.