3 ms·
I don't think adding a null terminator is useful for binary files which are not null-terminated strings, and may even have embedded 0 bytes in the middle.
by nyanpasu64 4y ago
I don't think adding a null terminator is useful for binary files which are not null-terminated strings, and may even have embedded 0 bytes in the middle.
- duped 4y agosure, but if it's a string that requires it to be null terminated, there's no reason the compiler can't solve that problem
- remexre 4y agoHow does the compiler know if an array is a string or not?
- duped 4y agoIt doesn't have to, you just add a zero byte at the end of the embedded byte sequence in the object file. It's up to the programmer to make the choice how to interpret that. That said for binary embeds you almost always need the length embedded as well, which has been the case for every tool I've used to embed files in object code. You usually get something like const size_t My_FILE_LENGTH = ... ; const uint8_t MY_FILE[] = { ... };
- remexre 4y ago> It doesn't have to, you just add a zero byte at the end of the embedded byte sequence in the object file. It's up to the programmer to make the choice how to interpret that. Like, are you proposing that the ideal semantics for `#embed "foo"` if foo contained 0x10 0x20 0x30 0x40 to be to expand to `16, 32, 48, 64, 0`? That seems more annoying than the opposite, given that: > That said for binary embeds you almost always need the length embedded as well, which has been the case for every tool I've used to embed files in object code. You usually get something like TFA demonstrated it by relying on sizeof() of arrays doing the right thing: static_assert((sizeof(sound_signature) / sizeof(*sound_signature)) >= 4, "There should be at least 4 elements in this array."); You'd need to change this to subtract one every time, which sounds more annoying when embedding binary resources than adding the zero to strings would be.