_Optional: a type qualifier to indicate pointer nullability
In August, I had an idea for a C language extension to improve null pointer safety. The tl;dr is that whereas a pointer-to-const may have undefined behaviour on write access, a pointer-to-_Optional may have undefined behaviour on read or write access. I shared this proposal with my colleagues, many of whom offered feedback and suggested improvements. Having finished prototyping my idea in Clang and experimentally applying it in a large closed-source codebase, I recently submitted a paper (n3089) to the WG14 committee in charge of C standardisation for ISO: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3089.pdf I also wrote an article explaining every aspect of my design and prototype: https://medium.com/itnext/why-c-needs-a-new-type-qualifier-61ad553cbe71 (long! sorry) I had hoped that a working prototype would help further my cause, but the code owners for Clang have just rejected my patches: https://discourse.llvm.org/t/rfc-optional-a-type-qualifier-to-indicate-pointer-nullability/ Obviously, I am disappointed -- not only because of the huge amount of thought and effort I put in, but also because I genuinely believe in the potential of my idea to transform C programming for the better (particularly when compared to the alternatives). In my experience my prototype works better than Clang's existing solution in the same problem space, yet its implementation is orders of magnitude simpler. Some of the issues with Clang's nullability qualifiers are bugs; others are more conceptual. I raised some of the issues I found in another thread: https://discourse.llvm.org/t/nullability-analyzer-doesnt-seem-to-work-and-how-to-fix-it/ Does the lack of support for Clang's nullability qualifiers in GCC indicate a greater likelihood for my proposed feature to be accepted into GCC? I am determined to avoid putting a huge amount of my own time into another inplementation, only to have it rejected again. If my proposal has little value to you (quite likely, if you are a C++ programmer), please bear in mind that it is just a simple tool (like 'const') that individuals can choose to use, or not. It entails only a minor change to the semantics of one operator. Yes, it is contagious, but nobody will be forced to use _Optional in their project, and it is easy to hide using a macro. I don't feel that it deserves to be killed at birth. Please could someone direct me to the process and/or gatekeepers responsible for allowing such an extension into GCC. Thanks for reading -- Christopher Bazley -- Christopher Bazley
Re: _Optional: a type qualifier to indicate pointer nullability
On Sat, 4 Feb 2023, 17:01 Christopher Bazley via Gcc, wrote: > > Does the lack of support for Clang's nullability qualifiers in GCC indicate > a greater likelihood for my proposed feature to be accepted into GCC? No, I don't think so. I think it would be better to support the same qualifiers as Clang, not diverge in this way. I agree with Aaron Ballman when he said: "The proposal is largely experimental in terms of design and needs a stronger indication that a standards body really believes in this design (in terms of syntactic choices, at the very least) and data demonstrating how this feature catches bugs that cannot be caught by other features in the same space (not just due to missing diagnostics that are possible to implement)." In fact I agree with most of his comment at https://discourse.llvm.org/t/rfc-optional-a-type-qualifier-to-indicate-pointer-nullability/68004/16 I particularly agree that no new language extension is needed to express a pointer that can be null, that's just how pointers have always worked. A pointer that cannot be null is more deserving of special attributes or qualifiers to say that it has additional guarantees that aren't implied by just being a pointer. I am > determined to avoid putting a huge amount of my own time into another > inplementation, only to have it rejected again. > > If my proposal has little value to you (quite likely, if you are a C++ > programmer), please bear in mind that it is just a simple tool (like > 'const') that individuals can choose to use, or not. It entails only a > minor change to the semantics of one operator. Yes, it is contagious, but > nobody will be forced to use _Optional in their project, and it is easy to > hide using a macro. I don't feel that it deserves to be killed at birth. > Language extensions don't deserve to be added to a compiler just because somebody put a lot of work into them. > Please could someone direct me to the process and/or gatekeepers > responsible for allowing such an extension into GCC. > A thread like this on the mailing list is how such decisions get made.
Re: _Optional: a type qualifier to indicate pointer nullability
On Sat, 4 Feb 2023 at 20:40, Jonathan Wakely wrote: > > On Sat, 4 Feb 2023, 17:01 Christopher Bazley via Gcc, > wrote: > >> >> Does the lack of support for Clang's nullability qualifiers in GCC >> indicate >> a greater likelihood for my proposed feature to be accepted into GCC? > > > No, I don't think so. I think it would be better to support the same > qualifiers as Clang, not diverge in this way. > Clang’s _Nullable qualifier is broken and pretty useless (even according to the code owner), so good luck with that. In fact I agree with most of his comment at > > https://discourse.llvm.org/t/rfc-optional-a-type-qualifier-to-indicate-pointer-nullability/68004/16 > > I particularly agree that no new language extension is needed to express a > pointer that can be null, that's just how pointers have always worked. A > pointer that cannot be null is more deserving of special attributes or > qualifiers to say that it has additional guarantees that aren't implied by > just being a pointer. > It’s not a matter what which kind of pointer is “deserving”. One choice is pleasant and expressive, whereas the other (C with _Nonnull attributes) is neither type-safe nor ergonomic. Meanwhile, on Reddit, my proposal has an 85% upvote rate, and on LinkedIn, “Great idea and I hope it gets itself in to a future standard, but I couldn't wait for something like that to arrive in C…” I wonder how many other people “couldn’t wait”. I guess they already left the debate. If my proposal has little value to you (quite likely, if you are a C++ >> programmer), please bear in mind that it is just a simple tool (like >> 'const') that individuals can choose to use, or not. It entails only a >> minor change to the semantics of one operator. Yes, it is contagious, but >> nobody will be forced to use _Optional in their project, and it is easy to >> hide using a macro. I don't feel that it deserves to be killed at birth. >> > > Language extensions don't deserve to be added to a compiler just because > somebody put a lot of work into them. > I never said that they did. You’ve conflated two unrelated paragraphs. -- Christopher Bazley
gcc-12-20230204 is now available
Snapshot gcc-12-20230204 is now available on https://gcc.gnu.org/pub/gcc/snapshots/12-20230204/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 12 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-12 revision 646c208608723046e29cc529614df1584f34d9d2 You'll find: gcc-12-20230204.tar.xz Complete GCC SHA256=7113408c1f30e9f8ceb8eff49cd8ad399b609be4450fbb4e2569419cb1124c4d SHA1=8b043f5b2c235d9ece9c8edb79896428a3688f96 Diffs from 12-20230128 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-12 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: _Optional: a type qualifier to indicate pointer nullability
On Sat, 4 Feb 2023, 21:23 Christopher Bazley, wrote: > > > On Sat, 4 Feb 2023 at 20:40, Jonathan Wakely > wrote: > >> >> On Sat, 4 Feb 2023, 17:01 Christopher Bazley via Gcc, >> wrote: >> >>> >>> Does the lack of support for Clang's nullability qualifiers in GCC >>> indicate >>> a greater likelihood for my proposed feature to be accepted into GCC? >> >> >> No, I don't think so. I think it would be better to support the same >> qualifiers as Clang, not diverge in this way. >> > > Clang’s _Nullable qualifier is broken and pretty useless (even according > to the code owner), so good luck with that. > But marking pointer arguments as non-null is already supported in GCC (with an attribute on the function, not the argument). Supporting a nonnull attribute on individual arguments seems useful to me. Far more than marking pointers as maybe-null, which is already true for all pointers.
