There are some changes for the API documentation though. Functions
pdf_list_iterator() and pdf_list_iterator_from_to() may fail when calling
pdf_alloc() so the caller must check for the NULL value before using it.
What about pdf_list_create()? The gnulib list implementation uses the
memory allocation routines and macros from gnulib (xmalloc and so on).
The problem is that those memory management functions directly abort
when a memory allocation failure occurs (gnulib's xalloc_die). Even in
`gl_array_list.c' you can see direct calls to xalloc_die.
I guess that you can choose whether you want to use xalloc_die from
gnulib or provide an own implementation, but in any case the function
should abort the program. If it doesn't abort, and xmalloc just returns
a NULL pointer, a segfault will occur when the gnulib list
implementation uses the pointer:
gl_array_list.c:62
struct gl_list_impl *list = XMALLOC (struct gl_list_impl);
list->base.vtable = implementation;
list->base.equals_fn = equals_fn;
list->base.hashcode_fn = hashcode_fn;
Is there an easy workaround taking into account that:
1. gnulib sources shouldn't be modified
2. the library shouldn't abort the program
Or am I missing something?
Example,
##
pdf_list_iterator_t itr;
itr = pdf_list_iterator (list);
if (itr.gl_iterator != NULL)
{
/* Use the iterator... */
}
else
{
/* failed to alloc an iterator... */
}
###
What about something like this?
Definition:
##
pdf_status_t
pdf_list_iterator(pdf_list_iterator_t *p_itr, pdf_list_t list);
Example:
##
pdf_list_iterator_t itr;
if(pdf_list_iterator(&itr,list) != PDF_OK)
{
/* failed to alloc an iterator */
}
##
In this way, we keep the black box view of the types, so that no one
needs to know if pdf_list_iterator_t is a structure with some contents
to check. Just a suggestion :-)
-Aleksander
