Re: [pdf-devel] Public API and gl_list

[gerel]

 > Date: Tue, 11 Mar 2008 23:08:14 +0100
 > From: Aleksander Morgado <address@hidden>
 > 
 > 
 > > 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.

Yes, that's why gl_list doesn't check for NULL pointers in each function
implementation.

 > 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:
 > 

if we don't abort we need to patch many functions and check for NULL pointers.


 > Is there an easy workaround taking into account that:
 > 1. gnulib sources shouldn't be modified
 > 2. the library shouldn't abort the program
 > 

Since the idea is to use and don't modify gl_list, I think the only solution is
to do our own gl_list-based implementation. But I can't make that desicion.

 > 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 */
 >    }
 > ##
 > 

Yes, that is how I'd do it but I wanted to do the smallest possible changes.  If
everyone agrees I'll redefine it though.

Thanks for your notes Aleksander.

-gerel