nullability annotations in C

Posted Feb 11, 2025 23:45 UTC (Tue) by khim (subscriber, #9252)
In reply to: nullability annotations in C by alx.manpages
Parent article: Maintainer opinions on Rust-for-Linux

> I'm 31. I hope to continue using C for many decades. :)

You certainly would be able to do that, after all Cobol 2023 and Fortran 2023 both exist.

The question is how many outside of “Enterprise” (where nothing is updated… ever, except when it breaks down and falls apart completely) would care.

The problems with strings, why they have been blamed for so long, wasn't really fault of strings themselves, but of the language, which wasn't as expressive as it could be.

The problem with strings are precisely strings. It's not even the fact that NUL is forbidden to be used inside (after all Rust strings are guaranteed UTF-8 inside).

The problem lies with the fact that something that should be easy and simple (just look in register and you know the length) is incredibly hard with null-terminated strings. It breaks speculations, requires special instructions (like what SSE4.2 added or “no fault vector load”, used by RISC-V), plays badly with many algorithms (why operation that shouldn't change anything in memory at all – like splitting string in two – ever changes anything?).

Null-terminated strings are not quite up there with the billion dollar mistake but they are very solid contenders for the 2nd place.

> The problem was devising the way to do it properly.

Try again. _Generic is C11 and tgmath is C99.

Means were there for 12 or 24 years (depending on how you are counting), there was just no interest… till 100% guaranteed job-security stance that C would never be replaced (simply because all prospective “C killers” were either built around C core or were unable to support effective interop with C) was threatened by Rust and Swift.

Then and only then wheels started moving… but I'm pretty sure they would pretty soon be clogged again… when it would be realized that on one side only legacy projects are interested in using C anyway and the other side the majority of legacy projects just don't care to change anything unless they are forced to do that.

> The kernel can probably implement this for their internal APIs pretty easily. The kernel already supports C11, so all the pieces are there. The bottleneck is in committer and reviewer time.

Yeah, but that's precisely the issue: while existing kernel developers may want to perform such change they are already already overworked and overstressed… and newcomers, normally, want nothing to do with C. I guess the fact that exceptions like you exist gives it a chance… but it would be interesting to see how it'll work.

Kernel is one of the few projects that can actually pull that off.

nullability annotations in C

Posted Feb 13, 2025 8:46 UTC (Thu) by aragilar (subscriber, #122569) [Link] (6 responses)

I do wonder how much of people not adopting new features of C is/was due to the primary compiler of a certain OS basically limiting itself to C89, and the other options not integrating with said compiler/OS?

nullability annotations in C

Posted Feb 13, 2025 9:59 UTC (Thu) by taladar (subscriber, #68407) [Link] (5 responses)

So called enterprise/long term support distros also have a lot to answer for in terms of holding back the adoption of new features because they would be a problem for their back ports to their ancient 10-15 year old versions.

nullability annotations in C

Posted Feb 13, 2025 10:28 UTC (Thu) by khim (subscriber, #9252) [Link] (4 responses)

How would backports hurt anyone? Sure, you can only use GCC 12 on RHEL 7, but that beast was released more than ten years ago, before first version of Rust, even!

Sure, at some point backporting stops, but I don't think the hold ups are “enterprise distros” (at least not RHEL specifically): these, at least, provide some updated toolchains. GCC 12 was released in a year 2022, thus it's pretty modern, by C standards. “Community distros” don't bother, most of the time.

nullability annotations in C

Posted Feb 14, 2025 14:26 UTC (Fri) by taladar (subscriber, #68407) [Link] (3 responses)

Your link goes to the Developer Toolset, those are optional tools that can be used on the platform but are not used for the platform itself.

nullability annotations in C

Posted Feb 14, 2025 14:29 UTC (Fri) by khim (subscriber, #9252) [Link] (2 responses)

Who even cares what they use for he development of the platform itself?

Developers shouldn't even care about that, it's internal implementations detail.

nullability annotations in C

Posted Feb 17, 2025 8:49 UTC (Mon) by taladar (subscriber, #68407) [Link] (1 responses)

It is relevant for the language features that can be used in code backported to the versions of software used in their distro, the entire point of this discussion thread. Or rather the language features that can not be adopted yet because people who want to do those backports will complain.

nullability annotations in C

Posted Feb 17, 2025 9:15 UTC (Mon) by khim (subscriber, #9252) [Link]

How is that relevant? Linux kernel was all too happy to adopt features not implemented by clang, and patches needed to support clang – and clang, at that point, was already used by Android, the most popular Linux distrubution used by billions… why RHEL should be treated differently?

Let RHEL developers decide what to do with their kernel: they can create special kgcc package (like they already did years ago) or rework features in any way they like.