Re: [xml] libxml2 API crazy?

[Nikita Churaev <lamefun x0r gmail com>]

Sorry.

I'm not doing much in my branch, the API is basically good, but there
are some crazy undocumented casts, like xmlNs* -> xmlNode*, xmlNs*
doesn't have the common node part, making access even to
node->next,prev,children potentially unsafe (does this cast actually
take place used or is it dead code, like someone on the IRC
suggested?). 

I'm going to document that and add safe casting/accesor functions, like
xmlDocPtrToNodePtr, xmlNodePtrToDocPtr, tools to check whether or not
the xmlNodePtr points to a certain structure, like xmlNodePtrIsDoc or
xmlNodePtrIsNode.

I'm also going to add safe accessor functions, like xmlNodeGetParent,
xmlNodeGetDoc, etc, for example:

xmlNodePtr
xmlGetNextSibling (xmlNodePtr node)
{
    if (node == NULL)
        return NULL;

    /* struct _xmlNs */
    if (node->type == XML_NAMESPACE_DECL)
        return NULL;

    return node->next;
}

On Fri, 2013-05-03 at 22:23 +0800, Daniel Veillard wrote:
> On Thu, May 02, 2013 at 08:39:47AM +0400, Nikita Churaev wrote:
> > > Further -- my own advice -- wrap everything in your own functions.
> > > This protects against changes or casting problem and makes the API
> > > work like you expect. 
> >
> > Why a layer of abstraction? This issue is mainly about lack of
> > documentation and safe casting functions. I think it would be better to
> > improve the libxml2 itself. Here's my current attempt on this:
> >
> > https://github.com/lamefun/libxml2
> [...]
> > If I'm doing something stupid, please tell me.
>
> instead of flaming and then stating to write tons of patches on your
> git clone without comments on the git commits nor discussions on this
> list about what you intent to do the most likel outcome is lot of
> patches rotting somewhere in a corner of github.
> I'm not gonna magically pull your set of patches.
> I will review patches if they are sent on this list with explanation of
> what they are doing. And before rolling dozen of those get feedback on
> the first ones.
> Oh and use less incendiary mail subjects, after all my code and API
> as crazy as they are, I love them (to some extent, lot of this was
> set up 15+ years ago !)
>
> Daniel