3 ms·

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 me

• 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.
        • elcritch 4y ago
          No, at least in this case I think the feature chooses the correct path on this. If you want to embed a string that’s null terminated then just save the string into a file as a null terminated string or copy it from the array to a proper string type. It looks like you may even be able to use this with a struct which might let you add a null termination after the array. Though yes I agree lots of features get bogged down trying to handle everything. But in this case not adding it creates even more complexity. You can store strings natively in C. You can’t include binary blobs in C in a platform independent way so you have hacks that explode compile times for everyone using that software. The ability to add vendor specific attributes also allows for those use cases to evolve naturally while still solving the core problem of embedding binary data.
          • saagarjha 4y ago
            I, FWIW, agree with the implementation. I'm just saying that this thread has someone saying "the compiler should add null termination" in it so the choice to make is not obvious.
    • duped 4y ago
      I don't see how that would prevent sequential embeds unless you have defined the semantics of embed to be a textual include, which if that's the case then the mistake are the semantics and not the constraints on compilers or embedded files. edit: why is it desirable to concatenate files with #embed? Does that not seem out of scope if not contrived?
  • pantalaimon 4y ago
    If you need 0 termination simply write const char foo[] = { #embed <file.txt> , 0 };