5 ms·

> 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, differen

> 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.

duped 4y ago
> 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.
- 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 ago
    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
    - remexre 4y ago
      How does the compiler know if an array is a string or not?
      - duped 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. 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.
- quelsolaar 4y ago
  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.
  - duped 4y ago
    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.
    - quelsolaar 4y ago
      This is the problem. Things get complicated fast. If we mandate null termination, then its impossible to have multiple embeds in a row to concatenate files, or we need some how to have rules for when to add null termination and not. These rules in turn are not going to be read by all users, so some people will just assume that embed always adds null terminate in when it doesn't and then we are back to square one. The more we add the more corner cases there are.
      - elcritch 4y ago
        Why assume the data should be null terminated? Its an array with a known compile time size. Binary data often needs to include 0 / NULL.
        saagarjha 4y ago
        This is literally the premise of this comment chain. Can you see how the standard can get dragged around by various competing needs? People want to embed strings, with null termination, some just want to embed binary data. Neither is particularly “wrong”. And in this thread everyone is presenting “obvious” solutions that are one or the other.
- jcelerier 4y ago
  What ? No it shouldn't. Use pointer+size if you want strings
iainmerrick 4y ago
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)?
- nindalf 4y ago
  He’s just trying to justify why it took 5 years to approve a feature that is so similar to #include.
rurban 4y ago
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?
- marssaxman 4y ago
  #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.
- riking 4y ago
  Multiple big-O steps faster.
  - account42 4y ago
    That's not how big-O works.

duped 4y ago

> 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.

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 ago
  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
  - remexre 4y ago
    How does the compiler know if an array is a string or not?
    - duped 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. 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.
quelsolaar 4y ago
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.
- duped 4y ago
  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.
  - quelsolaar 4y ago
    This is the problem. Things get complicated fast. If we mandate null termination, then its impossible to have multiple embeds in a row to concatenate files, or we need some how to have rules for when to add null termination and not. These rules in turn are not going to be read by all users, so some people will just assume that embed always adds null terminate in when it doesn't and then we are back to square one. The more we add the more corner cases there are.
    - elcritch 4y ago
      Why assume the data should be null terminated? Its an array with a known compile time size. Binary data often needs to include 0 / NULL.
      - saagarjha 4y ago
        This is literally the premise of this comment chain. Can you see how the standard can get dragged around by various competing needs? People want to embed strings, with null termination, some just want to embed binary data. Neither is particularly “wrong”. And in this thread everyone is presenting “obvious” solutions that are one or the other.
jcelerier 4y ago
What ? No it shouldn't. Use pointer+size if you want strings

iainmerrick 4y ago

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)?

nindalf 4y ago
He’s just trying to justify why it took 5 years to approve a feature that is so similar to #include.

rurban 4y ago

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?

marssaxman 4y ago
#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.
riking 4y ago
Multiple big-O steps faster.
- account42 4y ago
  That's not how big-O works.