[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [pdf-devel] Public API and gl_list
From: |
Aleksander Morgado |
Subject: |
Re: [pdf-devel] Public API and gl_list |
Date: |
Tue, 11 Mar 2008 23:08:14 +0100 |
User-agent: |
Thunderbird 2.0.0.12 (Macintosh/20080213) |
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
- Re: [pdf-devel] Public API and gl_list, (continued)
- Re: [pdf-devel] Public API and gl_list, gerel, 2008/03/10
- Re: [pdf-devel] Public API and gl_list, gerel, 2008/03/11
- Re: [pdf-devel] Public API and gl_list, jemarch, 2008/03/11
- Re: [pdf-devel] Public API and gl_list, gerel, 2008/03/11
- Re: [pdf-devel] Public API and gl_list, jemarch, 2008/03/11
- Re: [pdf-devel] Public API and gl_list, gerel, 2008/03/11
- Re: [pdf-devel] Public API and gl_list, jemarch, 2008/03/11
- Re: [pdf-devel] Public API and gl_list, gerel, 2008/03/11
- Re: [pdf-devel] Public API and gl_list, jemarch, 2008/03/12
- Re: [pdf-devel] Public API and gl_list, gerel, 2008/03/11
- Re: [pdf-devel] Public API and gl_list,
Aleksander Morgado <=
- Re: [pdf-devel] Public API and gl_list, gerel, 2008/03/11
- Re: [pdf-devel] Public API and gl_list, jemarch, 2008/03/12
- Re: [pdf-devel] Public API and gl_list, Juan Pedro Bolivar Puente, 2008/03/12
- Re: [pdf-devel] Public API and gl_list, Juan Pedro Bolivar Puente, 2008/03/12
- Re: [pdf-devel] Public API and gl_list, Cirilo Bernardo, 2008/03/13
- Re: [pdf-devel] Public API and gl_list, jemarch, 2008/03/13
- Re: [pdf-devel] Public API and gl_list, jemarch, 2008/03/13
- Re: [pdf-devel] Public API and gl_list, gerel, 2008/03/13
- Re: [pdf-devel] Public API and gl_list, jemarch, 2008/03/13
- Re: [pdf-devel] Public API and gl_list, gerel, 2008/03/13