Re: [pdf-devel] Public API and gl_list

[Juan Pedro Bolivar Puente]

Hi,

I am thinking of a solution. There are ways of implementing exceptions 
in ANSI C, as explained here:
http://www.on-time.com/ddj0011.htm

You could provide an implementation of xmalloc_die that rises an 
exception on error, then you catch it on our pdf_list_t wrapper. For 
example, using the syntax purposed in the previous article:

int pdf_list_foo()
{
   XTRY

     case XCODE:
        {
                /* gl_list code that may use xmalloc_die */
                gl_list_foo();
        }
        break;

     case XMALLOC_ERROR
     default:
        return PDF_ERROR;

     case XFINALLY: 
	/* finally handler for cleaning up. */ 
  XEND

  return PDF_OK;
}

However, I'm not sure wether this may lead to memory leaks unless we 
touch into gl_list private data.

Just my two cents,

JP

address@hidden wrote:
>     > 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.
>
> If we are facing this problem then anyone trying to use the gl_list
> module to be used in a library will face this problem too. I will talk
> with the gnulib people about this issue.
>
> In the meanwhile, let's use the current implementation: regardless our
> final decision the pdf_list API will be the same, so we can design and
> write the unit tests and use the module.
>
>
>