Re: [pdf-devel] Patch for FS#93 stack based iterators

[gerel]

 > Date: Tue, 27 Jan 2009 16:20:31 -0500
 > From: Michael Gold <address@hidden>
 > Content-Disposition: inline
 > 
 > 
 > On Tue, Jan 27, 2009 at 08:37:08 -0800, address@hidden wrote:
 > > Hi hackers,
 > >=20
 > > I attach a patch for stack based iterators, in list and hash modules.
 > >=20
 > > BTW, the current gnulib iterators are 28 bytes long, correct me if I'm wr=
 > ong.=20
 > > I gave 48 bytes to iterators, though this remains open to discussion.
 > 
 > They're 56 bytes on x86_64. Since all the struct's values are pointers
 > or size_t (which is pointer-sized on x86/x86_64), it would make sense to
 > use a type like intptr_t instead of char.

Yes, I discussed this on IRC with jemarch, what about a 'void*' pointer ?

 > 
 > We should also verify
 >        sizeof(pdf_list_iterator_s) >=3D sizeof(gl_list_iterator_t)
 >        and sizeof(pdf_hash_iterator_s) >=3D sizeof(gl_list_iterator_t)
 > 
 > Is there a portable way to do this at compile time? If not, assertions
 > could be used in pdf_{list,hash}_iterator.

If it is, then we can just use the gl real size. :-)
OTOH, I'm really against assertions in code. I consider it a serious design
flaw. So if we can't get the size at compile time, I'd suggest either to ask the
gnulib guys to provide the size or give a large enough size, whatever that
means. :-)

 > Are the _iterator_free methods necessary? gl_list_iterator_free doesn't
 > do anything, and it would be a bit simpler to use the types without
 > them. If _iterator can't fail with ENOMEM, I don't see what we'd need to
 > free in the future.

Consider that the pdf_list is a wrapper, if gnulib developers tomorrow decide
that the free procedure IS necessary, we will regret about this decision. :-)

cheers,

-gerel