[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