9 ms·

That the annotation applies to variables and not types is surely an oversight or mistake right? Seems like it could have been easier to initially implement that

• leni536 1y ago
  I either don't understand how the annotation would work on types, or what would be gained by it. What type would be annotated? A typedef to char[]? edit: Unless what they actually mean is annotating struct members, that would actually make sense.
  • _nalply 1y ago
    I do understand. I imagine that it could work a little bit like unsigned: a modifier to integer types that tells that an integer's MSB is not to be used as a sign bit. __nonstring__ tells that the last byte of a byte sequence doesn't need to be NUL. I would find it sensible allowing putting the attribute to a type, but whatever.
    • leni536 1y ago
      But that doesn't make any difference in the way you have to address existing `char arr[4] = "abcd"` declarations.
      • _nalply 1y ago
        True. This would be only useful in typedefs. An API could declare some byte arrays not strings. But again, whatever.
• rurban 1y ago
  And how would you type a string vs byte array then? C doesn't even have proper string support yet, ie unicode strings. Most wchar functions don't care at all about unicode rules. Zero-terminated byte buffers are certainly not strings, just garbage. C will never get proper string support, so you'll never be able to seperate them from zero-terminated byte buffers vs byte-buffers in the type system. So annotating vars is perfectly fine. The problem was that the PM and Release manager was completely unaware of the state of the next branch, of its upcoming problems and fixes, and just hacked around in his usual cowboy manner. Entirely unprofessional. A release manager should have been aware of Kees' gcc15 fixes. But they have not tooling support, no oversight, just endless blurbs on their main mailinglist. No CI for a release candidate? Reminds us of typical cowboys in other places.
  • iforgotpassword 1y ago
    I think the idea is simply to typedef __nostring__ char* bytes; And then use that type instead of annotating every single variable declaration.
    • OskarS 1y ago
      But you would still need to change it everywhere, right? Like, instead of changing the annotation everywhere you have to change the type everywhere. Doesn't seem like a huge difference to me.
      • Animux 1y ago
        There is a difference if the type is used inside a structure.
        • OskarS 1y ago
          Fair, good point.
    • deleted 1y ago
      [deleted]
  • timewizard 1y ago
    > No CI for a release candidate? If the CI system didn't get the Fedora upgrade then it would not have caught it. Aside from that the kernel has a highly configurable build process so getting good coverage is equally complex. Plus, this is a release candidate, which is noted as being explicitly targeted at developers and enthusiasts. I'm not sure the strength of Kees' objections are well matched to the size of the actual problem.
    • badmintonbaseba 1y ago
      But Linus broke the kernel for gcc<15, a CI would have surely caught it. And Linus is usually much more critical in what gets into master when it comes to other people's contribution, let alone into an RC.
• dataflow 1y ago
  > That the annotation applies to variables and not types is surely an oversight or mistake right? I don't think so. It doesn't make sense on the type. Otherwise, what should happen here? char s[1]; char (__nonstring ns)[1]; // (I guess this would be the syntax?) s[0] = '1'; ns[0] = '\0'; char* p1 = s; // Should this be legal? char* p2 = ns; // Should this be legal? char* __nonstring p3 = s; // Should this be legal? char* __nonstring p4 = ns; // Should this be legal? foo(s, ns, p1, p2, p3, p4); // Which ones can foo() assume to be NUL-terminated? // Which ones can foo() assume to NOT be NUL-terminated?? By putting it in the type you're not just affecting the initialization, you're establishing an invariant throughout the lifetime of the object... which you cannot enforce in any desirable way here. That would be equivalent to laying a minefield throughout your code.
  • dwattttt 1y ago
    Do you mean s & ns to be swapped? ns starts with a NUL terminator and s does not.
    • dataflow 1y ago
      No actually, that was the point. I was asking, what do you think should happen if you store a NUL when you're claiming you're not. Or if you don't store a NUL, when you claim it's there.
      • dwattttt 1y ago
        Well, as a human compiler, I said "Hey, you've non-NUL terminated a NUL terminated string". If that was what you intended you should use the type annotation for that, so I think that case worked as intended. EDIT: > what do you think should happen if you store a NUL when you're claiming you're not I don't believe nonstring implies it doesn't end with a NUL, just that it isn't required to.
        • dataflow 1y ago
          But char[] already isn't required to be NUL-terminated to begin with. char a[1] = {'a'} is perfectly fine, as is a[0] = '1'. If all you want to do is to document the fact that a type can do exactly what it already can... changing the type to something new doesn't make sense. Note that "works as intended" isn't sole the criterion for "does it make sense" or "should we do this." You can kill a fly with a cannon too, and it achieves the intended outcome, but that doesn't mean you should.
• deleted 1y ago
  [deleted]