Comment by quelsolaar
3 years ago
> That's not something to be proud of.
Its learning from old mistakes.
Look at embed as an example. Look how complex it is, dealing with empty files, different ways of opening files, files without lengths, null termination... the list goes on. This is typical of a proposal for C, it starts out simple "why cant i just embed a file in to my code?" and then it gets complicated because the world is complicated.
I worry a lot about people loading in text files and forgetting to add null termination to embeds. I would not be surprised if in a few years that provides a big headline on Hacker news, about how that shot someone in the foot and how C isn't to be trusted. The details matter.
I worry a lot about people loading in text files and forgetting to add null termination to embeds.
If you really worry about that, why did you vote in favour of this feature (as you stated earlier)?
He’s just trying to justify why it took 5 years to approve a feature that is so similar to #include.
null termination is not to be added to embed. embed adds a const sized buffer of unsigned bytes, not strings. files are not strings, files do contain \0.
and I still don't get why embed is so much better than xxd included buffers. it's more convenient sure, but 10x faster?
#embed is faster because it skips the parsing step. xxd generates source code tokens, which the parser must then decode back into bytes; embed just reads the bytes directly.
Multiple big-O steps faster.
That's not how big-O works.
> I worry a lot about people loading in text files and forgetting to add null termination to embeds. I would not be surprised if in a few years that provides a big headline on Hacker news, about how that shot someone in the foot and how C isn't to be trusted. The details matter.
The compiler should insert the null terminator if it's not in the embedded file.
This is another issue here. If loads of compilers start doing this then programs start relying on it an then it becomes a de-facto undocumented feature. That means if you move compilers/platforms you get new issues. A lot of what the C standard does is mopping up these kinds of issues.
Then require compilers implement it in the standard. I think it's really backwards to ignore the tool chain and its ability to prevent bugs from entering software.
It's stuff like this that leaves us writing C to rely on implementation defined behavior. Under specification that leaves easy holes to fill will be filled by the compiler and we will rely on them. Just like type punning.
7 replies →
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.
sure, but if it's a string that requires it to be null terminated, there's no reason the compiler can't solve that problem
3 replies →
What ? No it shouldn't. Use pointer+size if you want strings