Re: A few proposals from the C standards committee

[Linus Torvalds <torvalds@linux-foundation.org>]

On Tue, 23 Jan 2024 at 12:00, Paul E. McKenney <paulmck@kernel.org> wrote:
>
> Would you be OK with something that required a new variable for the
> pointer that was now known not to be NULL?  (My guess is "no", given the
> following discussion on value ranges, but I figured that I should ask.)

Yeah, no, I think that ends up putting the burden on the programmer in
the form of a very cumbersome syntax, and just more room for mistakes.

> In some implementations, you can use assertions to get at least part
> of this effect:

Yes. However, the problem with that is that the assert generally then
comes with extra code generation.

IOW, a plain

          _Nonnull p;

in my opinion should imply a promise by the developer - and then you
could have some "debug build" model where the compiler then verifies
the promises.

But an

        assert(p);

implies more than a promise by the developer - it implies that the
compiler *should* generate some code to verify.

And yes, obviously assert() comes with the traditional NDEBUG flag,
but that one has the historical baggage of causing the assert() to be
a no-op. IOW, you lose the code generation, but you also lose the
promise from the developer.

Could all of this be done *properly*? Yes. And I think it should. But
properly literally means having good documented "this is what this
means".

And no, __builtin_unreachable() is not it either, because it again has
the same issue as "assert()" - in *practice* compilers can use it as a
hint, but that's an incidental result, not part of a documented "this
is how you specify a known range"

So yes, I can do things like

        if (a < 0) __builtin_unreachable();

and it will generate the *code* that I want, but it sure as hell isn't
some standard C syntax.

               Linus