https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87003

--- Comment #1 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
It would be good to make the header file be more self-documenting.

In general, every pointer argument ought to be non-NULL, but a NULL will be
checked for and gracefully rejected.

The exception is gcc_jit_location *, which can always be NULL.

libgccjit performs error-checking at the API boundary: there are many places
where a NULL pointer argument will lead to a failure that puts the context into
an "invalid" state, but such a failure will be handled gracefully without
segfaulting:
  https://gcc.gnu.org/onlinedocs/jit/topics/contexts.html#error-handling

This means that e.g. C code calling into the API doesn't need to check
everywhere for NULL results before passing them back in as arguments to
followup calls; it can just check once at the end of populating a context.

(FWIW, I notice that the Rust bindings don't do error-handling yet:
https://github.com/swgillespie/gccjit.rs#error-handling )

The docs for attribute "nonnull":
https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Common-Function-Attributes.html#Common-Function-Attributes

say it:
> "...causes the compiler to check that [...] arguments [...] are
> non-null.  If the compiler determines that a null pointer is passed
> in an argument slot marked as non-null, and the -Wnonnull option is
> enabled, a warning is issued. The compiler may also choose to make
> optimizations based on the knowledge that certain function arguments
> will never be null"

That last sentence about optimizations makes me a little wary: it *is* possible
for such arguments to be NULL (and my test cases make use of this to verify
that the API does indeed gracefully handle these errors).

But it does seem useful to mark all those arguments, and potentially warn for
obvious "NULL in the wrong places" typos.

Thoughts?

Reply via email to