On 4/28/26 15:56, Martin Uecker wrote:
>> In Aaron's and my alternate world, we'd need a more nuanced brush for
>> "dropping qualifiers" when forming the signature of a function in C.
>>
>> void f(int * const); === void f(int *);
>>
>> But maybe don't drop the _Optional here when forming the signature:
>>
>> void f(int * _Optional);
>
> But "not dropping the qualifier" would follow naturally when putting
> it on the pointee. So this would seem to give you the right semantics
> using existing language mechanisms when putting on the pointee. So now
> I am even more confused about what the problem is.

I guess part of the problem is how much of _Optional is part of the
type system.

> But neither "const", "volatile" nor "_Optional" describe a
> property of an object, they all describe semantics of an
> access to an object using the giving type of the lvalue.

> For "const" it says you can not write using that lvalue,
> for "volatile" it says that all accesses appear according
> to the rules of the abstract machine,

Right. For these two cases, we first do *x
and then ask whether it's allowed to modify via that lvalue
and/or what accesses through *x mean in the abstract
machine.

> and for "_Optional"
> it says that an access without prior null pointer check
> is forbidden.

And that seems qualitatively different to me: We (want to)
diagnose the formation of *x (the lvalue) without a surrounding
"if" guard, not the use of that lvalue afterwards.
So, it's a restriction on stuff you can do with the pointer x,
not on stuff you can do with the lvalue formed by *x.

(Lvalues are more prevalent in C++ than they probably
are in C, so this probably is more of a pain point from a
C++ viewpoint.)

Jens