[jey]

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 way but it just doesn’t seem to fit with how C type system works. (Yes it will make declarations uglier to do it on types but that ship has sailed long ago; see cdecl.org)

[rurban]

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]

I think the idea is simply to

  typedef __nostring__ char* bytes;

And then use that type instead of annotating every single variable declaration.

[timewizard]

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

[dataflow]

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

[_nalply]

Perhaps unsigned could help here with understanding.

unsigned means, don't use of an integer MSB as sign bit. __nonstring means, the byte array might not be terminated with a NUL byte.

So what happens if you use integers instead of byte arrays? I mean cast away unsigned or add unsigned. Of course these two areas are different, but one could try to design such features that they behave in similar ways where it makes sense.

I am unsure but it seems, if you cast to a different type you lose the conditions of the previous type. And "should this be legal", you can cast away a lot of things and it's legal. That's C.

But whatever because it's not implemented. This all is hypothetical. I understand GCC that they took the easier way. Type strictness is not C's forte.

[dwattttt]

Do you mean s & ns to be swapped? ns starts with a NUL terminator and s does not.

[leni536]

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]

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.