search

graphitemaster / incbin

Include binary files in C/C++
The Unlicense
941 stars 90 forks source link

size is not get calculated correctly on Mac #4

Closed ptrv closed 9 years ago

ptrv commented 9 years ago

The size is not calculated correctly when I use incbin on Mac. I get for every included file the value 65536

graphitemaster commented 9 years ago

Mind finding out why?

ahupowerdns commented 9 years ago

very early observation, but files end up being a few bytes bigger here than they should be too. gcc 4.9. Will investigate further. But thank you already for this wonderful include!

graphitemaster commented 9 years ago

it may be alignment related

ahupowerdns commented 9 years ago

from what I see, the size is calculated by subtracting the address of the size variable from the address of the data variable. This indeed delivers an answer that depends on the alignment between the two variables - it assumes they are flush together in the segment, which will only be the case if the file in question itself is a round multiple of 4 or 8 bytes long.

graphitemaster commented 9 years ago

It's not exactly easy to calculate the size unless we use one byte alignment, then include the data, use it to calculate the size, and somehow mark that dat to be 'ignored', and then using the appropriate alignment, include it a second time.

ahupowerdns commented 9 years ago

Yeah, this sucks, but I guess it is just reality. Perhaps something would be good to document as a limitation though. This ticket has 'Mac' in the name, but I found the 8-byte rounding on amd64 linux.

ahupowerdns commented 9 years ago

oh and finally, this is a helpful link that touches on the various methods available to 'incbin': https://dvdhrm.wordpress.com/2013/03/08/linking-binary-data/ - but they all suck to a certain extent, so it would be great if we could find some solution!

ahupowerdns commented 9 years ago

Perhaps pull request #5 might be of some use. It does appear to solve the problem here!

graphitemaster commented 9 years ago

Pull request #5 does the trick, it also exposes an "end" variable which may be of use for other things (iterator based code for instance) closing this.