Comment by Cloudef
3 years ago
I've always used xxd -i for embedding, doesn't have the mentioned problems and works everywhere, as it simply outputs a header file with byte array.
3 years ago
I've always used xxd -i for embedding, doesn't have the mentioned problems and works everywhere, as it simply outputs a header file with byte array.
Well, congratulations, you now have a build dependency on Vim. (xxd is not a standard tool, it ships with Vim.)
It's also only suitable for tiny files: compile time and RAM requirements will blow up once you go beyond a couple of megabytes.
> It's also only suitable for tiny files: compile time and RAM requirements will blow up once you go beyond a couple of megabytes.
Do you know what makes it so? Is there a technical argument why the compiler could do better, except maybe for xxd not being specifically optimized for this use case?
The compiler has an as-if rule on its side.
It's allowed to do whatever it wants so long as the results are as-if it did what the standard says. So even though the standard says this is making a big list of integers like your xxd command, the compiler won't do that, because (as a C compiler) it knows perfectly well it would just parse those integers into bytes again, just like the ones it got out of the binary file. It knows the integers would all be valid (it made them) and fit in a byte (duh) and so it can skip the entire back-and-forth.
1 reply →
Yeah, these are reasonable arguments against it
The one in the original article I that it performs badly for large files.
1 reply →
The article spends a fair bit of time discussing the build speed and memory use problems with that approach. Like, the benchmark results [0] linked to from this post literally have xxd as one of the rows. It's not a viable option for embedding megabytes of data.
[0] https://thephd.dev/embed-the-details#results
And even if the data is small enough, not every C programmer uses Unix or knows their way around it.
But you have to have build system stuff for that and it's obviously non portable.
True, i dont personally ever have problem with this because i always compile from unix system anyways. (Even for windows)