Re: [pdf-devel] Updated tokeniser/parser patch

[gerel]

 > Date: Thu, 22 Jan 2009 20:48:24 +0100
 > From: address@hidden
 > 
 >    One annoying thing I noticed was that pdf_list_t needs a heap allocation
 >    to use an iterator, which means that pdf_obj_equal_p could fail with an
 >    ENOMEM error (but currently has no way to return that error). It would
 >    be nice if the iterator could be kept on the stack -- struct
 >    pdf_list_iterator_s only contains one member anyway.
 > 
 > Gerel, what do you think about this? We would of course loose the
 > benefits of the opaque pointers in this case, but 'pdf_obj_equal_p'
 > throwing PDF_ENOMEM sounds quite weird, and I think that we could make an
 > exception and publish the iterator structure.

Hi hackers,

Well, before going further, I think the design of the list module is ok as it is
now. We can write any predicate procedure on top of any module and not for that
reason the module is to blame on status codes. We have to deal with status
codes.

If we publish the iterator structure and allocate it from the stack, we also
need to make public the gl_list_* structures which was in first place something
we didn't want. Correct me if I'm wrong.

Moreover, if code cleanliness is the issue ignoring the status code like it's
being done in pdf_obj_equal_p() is fine. By pushing the iterator to the stack,
we're not safe from anything since the process stack has a limit too (and
smaller than the heap), and we can deal with heap limits while stack limits
are simply fatal, we can't deal with them.

IMHO if we follow this philosophy of using the stack to avoid the check of
status codes, soon we might be tempted to push more structures to the stack
going nowhere and losing binary code compatibility (no opaque pointers).
I guess the gnulib folks have gone through this discussion and settled on the
abort() call for some reason, right?. And gnulib is also a library.

That said, I'll modify the API and implementation of the list module if you
still believe it is the correct path. 

cheers,
-gerel