Docs are confusing about "end" symbol

[bryceschober]

OK, now that I've looked down into the tests, which take the address of the end symbol, I know how to use it: https://github.com/graphitemaster/incbin/blob/6a3ca1590754679bf9155ac00cbf9259a87ac412/test/asserts.c#L12-L18

I didn't find anywhere in the docs that show an example usage. What they do say implies that the symbol is already a const unsigned char*, when it's actually a const unsigned char immediately after the data, of which you must take the address. https://github.com/graphitemaster/incbin/blob/6a3ca1590754679bf9155ac00cbf9259a87ac412/incbin.h#L270-L288

[bryceschober]

FWIW, that makes the "end" symbol pointless to use, since computing an end pointer as gFooData + gFooSize is way easier to read and doesn't require the unexpected take-the-address-and-cast-it maneuver.

[graphitemaster]

Yeah the documentation is wrong about the ending symbol being an actual byte marker that you need to take the address of. The end marker isn't useless though, it's what is used to calculate and provide you the size. It's also much nicer to use for functions expecting beg/end pointers (or iterators in the case of C++ for stuff like std::{...}::insert or std::copy, ala most of <algorithm> too.) You're free to avoid it, and yes - generally &data_beg[size] will be the same as &data_end.

[graphitemaster]

There is no need to cast anything either in the case of the end of the data, you can just apply address-of operator to it, not sure what you mean there. Not sure why the tests do it either. I didn't write those.

[graphitemaster]

Fixed the documentation

[bryceschober]

I was trying to use it in a C++ context, and instead of trying to explain in detail, I've recreated my problem on wandbox.org, and it seems to disprove your assertions, unless I'm missing something.