Re: [pdf-devel] Public API and gl_list

[Aleksander Morgado]

> 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