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

[OskarS]

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]

There is a difference if the type is used inside a structure.

[OskarS]

Fair, good point.

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

[badmintonbaseba]

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.