> Date: Thu, 22 Jan 2009 18:28:47 -0500 > From: Michael Gold <[email protected]> > 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
