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

[gerel]

 > Date: Thu, 22 Jan 2009 18:28:47 -0500
 > From: Michael Gold <address@hidden>
 > Content-Disposition: inline
 > 
 > > If we publish the iterator structure and allocate it from the stack, we a=
 > lso
 > > need to make public the gl_list_* structures which was in first place som=
 > ething
 > > we didn't want. Correct me if I'm wrong.
 > 
 > I was reading the code wrong and didn't notice it was allocating a
 > gl_list_iterator_t (rather than a pdf_list_iterator_s). Still, we don't
 > necessarily need to publish gl_list_iterator_t -- as I mentioned in my
 > other mail, we need a struct that's large enough to hold that struct,
 > and we can use padding for future compatibility. Publically, it could
 > simply be declared like struct { void *x[12]; }.
 > 
 > Note that pdf_hash_t would need similar changes.

Ok, I guess this is an effective hack, though I won't say it is 100% 'binary
comptaible' at all. :-)
Before changing anything I'll wait until the task for the lexer/parser is
actually open, after the Object layer design is complete, etc...

[...]
 > gnulib is not a shared library. The files are designed to be copied
 > directly into programs -- so if a programmer decides they don't want to
 > abort on OOM conditions, they can avoid or fix those modules. But GNU
 > PDF will usually be loaded dynamically, which means the same binary
 > could be used by many applications, each with a different OOM policy.
 > We shouldn't impose any policy on them.
 > 

It was hardly suggested to not fix/modify the gnulib modules in previous emails,
I don't know...


cheers,
-gerel