[redland-dev] [patch] librdf_storage_hashes_context_serialise_get_statement

John Fieber jfieber at adobe.com
Tue May 6 15:35:33 BST 2008


On May 6, 2008, at 5:23 AM, Michael Stahl wrote:

> so i found another problem in librdf_stream_get_context... namely  
> that it does not work with hashes storage.

Do you have a simple test case to illustrate this?  I'm able to  
retrieve contexts in streams on hashes storage without trouble.

That said, I do have a different problem with iterator/stream map  
functions regarding contexts.  The mapping function for an iterator  
has the signature (rdf_iterator.h):

   typedef void* (*librdf_iterator_map_handler)(librdf_iterator  
*iterator, void *map_context, void *item);

The problem is the list of iterator methods you cannot call within the  
map function because they produce infinite recursion:

  librdf_iterator_have_elements
  librdf_iterator_end
  librdf_iterator_next
  librdf_iterator_get_object
  librdf_iterator_get_context
  librdf_iterator_get_key
  librdf_iterator_get_value

Clearly not all of those are necessary or even appropriate to use in a  
map callback since you are handed a pointer to the object, but getting  
the context is relevant, and the only way to get it is to violate  
encapsulation of the iterator.  The stream methods exhibit the same  
behavior.

Another bug that affects the iterator only is that the callback  
signature is

   typedef void* (*librdf_iterator_map_handler)(librdf_iterator  
*iterator, void *map_context, void *item);

but it called with second two arguments swapped (rdf_iterator.c):

       /* apply the map to the element  */
       element=map->fn(iterator, element, map->context);

I'm guessing this is wrong since the argument order is consistent in  
three out of four cases: stream callback signature, stream callback  
call and iterator callback signature.

-john



More information about the redland-dev mailing list