google
Migrate C-style buffers to C++ containers
Currently, compiling flatbuffers with -Wunsafe-buffer-usage yields over 10K+ warnings for unsafe pointer arithmetic, unsafe buffer access across headers and cpp files. The idea is to adopt safe programming model and to migrate C-style buffers to C++ containers.
@aardappel / @dbaileychess I am interested in putting forward PR to start discussion on implementing safe buffers and migrating c-style buffers to c++ containers. The 10K+ warnings can be divided into cpp and headers files. I wanted to put forward PR for cpp files addressing safe buffers. For implementing safe buffers, since C++ 11 is still supported, I would adhere to C++ 11 standards. The current stl_emulation.h lacks implementation of subspan. I have prepared PR which adds subspan method. Most of the code base is performing pointer arithemtic over raw pointers which is against google safe buffers guidelines. Most raw pointer arithmetic can be avoided by using flatbuffers:span class and then using subspan method to get the data. In situations when buffer access is needed, vector can be constructed using subspan.begin() and subspan.end() method and then the .at() method for vector can provide index based access. I am able to share PR which is easy to understand and adheres to C++ 11 standards but wanted to have input / suggestions on implementing safe buffer practices before I submitted PR. Thanks.
FlatBuffers is a very low level library geared towards performance, I don't think it is realistic to want to get rid of "raw pointers" entirely for the internals of such a library.
"C++ without raw pointer usage" is a dialect/subset of C++ that is certainly interesting, and would be worthwhile for new or higher level software written in C++, but given how deeply ingrained pointers are in C++, it wouldn't be easy.
Even if span and similar replacements can be shown to compile down to the exact same machine code as the equivalent raw pointer usage on every single compiler, I'd still have concerns about increased compile times, and slower execution in debug mode, as well the generally noisier and less obvious code, especially for spans of a single element for which pointers are probably easier to read than spans.
Then there are also a lot of pointers on the API surface which we can't get rid of. Converting those to spans on entry for the sake of it seems very counter productive to me. And presumably, they'd still trigger your warning.
