I am just doing some small fixes in the Nim bindings, mostly for the new deterministic memory management with compile option --gc:arc
One recent issue was the behaviour when gtk libs return NULL value. Proposed solution was to make proxy object nil for this (very rare) case.
So it is the question if we should check for NULL for all gtk related functions, or just for the case when return value is flagged “nullable”. The first case is more secure, but is a few more bytes in the executable.
Unfortunately the “nullable” flag for function results seems to be not reliable, as in
So the question is, is this an exceptionally bug, or is the flag often wrong for results? And may reporting it to gtk bugzilla or somewhere else makes any sense?
(My current guess is that for constructors like gtk_button_new() the result is never NULL, so we may have to do no check for constructors at all, but this is only my current guess, I have to do some investigations…)
In general, you should only check for NULL when the API is marked as nullable—but considering that a lot of the API in the GNOME stack was written before introspection was a thing, you may want to be more conservative. These days, we try to keep the annotations up to date.
Additionally, not every function that can return NULL will have its return value marked as nullable; for instance, if a function has a GError argument and returns NULL only on error conditions—i.e. the error out argument will be set—then we don’t mark the return value as nullable.
It’s a simple omission; evidently nobody has been using this API from a language binding.
The GError case is handled separately for our Nim bindings, we raise an exception in error case.
I think I will assume that there are not too many missing “Nullable” flags then and will generate extra code only for the cases when “nullable” is specified for function results.
Will consider a merge request, but maybe I will inspect gobject-introspection files for more missing “nullable” flags first.
