Am Mittwoch, dem 09.08.2023 um 14:37 +0200 schrieb Alejandro Colomar:
> Hi Martin!
>
> On 2023-08-09 14:03, Martin Uecker wrote:
>
> Regarding the issues you have with _Nonnull being a qualifier,
> I've been thinking about it for a long time and don't yet have
> a concrete answer. The more I think about it, the more I'm
> convinced it is like `restrict`. You can't have null correctness
> as we can do with `const`. With const, we know it's always bad
> to store a const object in a non-const pointer. With NULL, it
> depends on the context: if you've checked for NULL in the lines
> above, then it's fine to do the conversion.
>
> There is a proposal for Clang to add `_Optional`, a qualifier to
> the pointee, as a more correct version of _Nullable. The
> following would be equivalent:
>
> int *_Nullable i;
> _Optional int *j;
>
> However, I don't believe it's a good choice, because of the above.
> Instead, I think _Nullable or _Nonnull should be like `restrict`
> and used only in function prototypes. Let the analyzer do the
> job. I know `restrict` is hard to grasp, but I couldn't think of
> anything better.
I think this would be bad. More confusion is the least we need.
I would definitely prefer an attribute over a confusing qualifier
which is not really a qualifier.
_Optional is a something else and maybe not directly
comparable. I think it is an interesting idea. First, it
would fit well with rules the language. One gets
conversion errors exactly as with other qualifiers. So
one could add it to selected pointer in an existing code
base and incrementally improve the code by adding checks.
It would not be useful for existing interfaces that
need stay compatible.
> >
> > What is missing something which implies bounds
> > also inside the callee. You can use the "access"
> > attribute or we extend the meaning of int[N]
> > and int[static N] also imply a maximum bound.
>
> Why is the upper bound important? It's usually irrelevant.
>
> In the case where one wants to make sure that an array is of an
> exact size (instead of just "at least"), pointers to arrays can be
> used. They're just not often used, because you don't need that
> so often. I don't think we need a new addition to the language,
> do we?
>
> $ cat ap.c
> #include <stddef.h>
>
> void
> foo(size_t n, int (*a)[n])
> {
> for (size_t i = 0; i < n; i++)
> (*a)[i] = 42;
> }
> $ gcc-13 -S -Wall -Wextra ap.c
> $
>
> In the function above, n is not a lower bound, but an exact bound.
>
> GCC should add a warning for the following code:
>
> $ cat ap2.c
> #include <stddef.h>
>
> void foo(size_t n, int (*a)[n]);
>
> void
> bar(void)
> {
> int x[7];
>
> foo(3, &x);
> foo(9, &x);
> }
> $ gcc-13 -S -Wall -Wextra ap2.c
> $
>
> Neither GCC nor Clang warn about that. Not even with -fanalyzer.
I know. One can already get bounds checking side the callee with
this using UBSan. I have UBSan patch which would protect the
call itself and make sure the bounds are correct. Compile-time
warnings would also be good.
In any case, this does not work for existing interfaces.
Martin
