On Mon, 2015-12-28 at 16:37 +0100, Max Reeves wrote:
As the empty G(S)List is represented by NULL, this makes it a perfectly valid G(S)List. For most other objects NULL represents the absence of an object. I suppose it's possible to have NULL represent both the empty list and the absence of an object, eg a NULL G(S)List argument to a "nullable" in parameter could just be ignored - as it probably would anyway. But what sense does it make to mark a G(S)List parameter or return value as "not nullable"?
It’s not defined anywhere that I know.
I'm currently working on a binding from libraries with GIR data to Standard ML, so I'm concerned what approach I should use to pass “not nullable” G(S)List or if I should completely ignore it. Are there any introspectable code conventions I should know about that regulates this?
I think other bindings treat GList and GSList specially (as they do with other inbuilt GLib types, like GHashTable and GPtrArray), so I suggest you do the same. This probably means assuming that GList parameters are (nullable) by default, and perhaps emitting a warning if a GList parameter is marked as (not nullable), because that is nonsensical. Philip
Attachment:
signature.asc
Description: This is a digitally signed message part