Should a null terminated GPtrArray guarantee pdata != NULL?
Since 2.74, g_ptr_array_new_null_terminated()
is documented like this:
Note that if the array's length is zero and currently no data array is allocated, then pdata will still be NULL. GPtrArray will only NULL terminate pdata, if an actual array is allocated. It does not guarantee that an array is always allocated. In other words, if the length is zero, then pdata may either point to a NULL terminated array of length zero or be NULL.
but g_ptr_array_free(., FALSE)
is documented to "normalize" NULL pdata to be an empty non-NULL array:
Note that if the array is NULL terminated and free_seg is FALSE then this will always return an allocated NULL terminated buffer. If pdata is previously NULL, a new buffer will be allocated.
This has become more visible in 2.75.x with the addition of other null-terminated APIs.
The behaviour of pdata
seems unexpected to me. I would have expected that if I specifically asked for a NULL-terminated array, I would always get at least len = 0, pdata = { NULL }
, even if no non-null elements appear before the length count, so that I could pass arr->pdata
to (for example) any API like g_strv_contains()
that expects a non-NULL, NULL-terminated const char * const *
.
Is it too late to tighten this up so that null_terminated
implies pdata != NULL && pdata[len] == NULL
at all times?
/cc @3v1n0