Re: [xml] libxml2 API crazy?



Nothing wrong with it -- if they plan to incorporate your changes into the system.  I made a layer of abstraction because there were things I wanted different that they would not incorporate, because I wanted functions that did multiple libxml2 functions instead of coding everything by hand each time, and I wanted protection against change (I have used this since libxml -- pretty much since the beginning) -- early on there were changes that required changes to code, and I find it easier to change my abstraction layer than the hundreds of programs I have using libxml2.

I bet nobody would complain about documentation!

I should point out that in practice the casting is not an issue even if you are technically correct.  My C textbook says that one cannot depend on the order of execution for "if" statements.  I have programmed C for 25 years on so many platforms and versions of O/S I can no longer count them.  TI, HP, Apple, PC, AIX, Linux, SCO, etc.  I have in practice NEVER seen a machine that did not go left to right.  So my book says:

if (a !=0 && b/a > 1) {
    /* do stuff */
}

Is not legal -- it could evaluate b/a first and get divide by zero ... For a few years I followed the book until I noticed in the real world every assumed left to right and coded that way.  What I am saying is that I use libxml2 currently on dozens of O/S and hardware combination and have no problems with casts ... even if you are textbook correct.  Nor with ifs which some of theirs are left/right dependent.  I think the world would end if anyone decided to go right to left!

And I understand about the structure padding argument -- in your example (two ints) they would certainly pad exactly the same in the real world or the real world would end as we know it.  In fact the same type should always align the same.  If you mixed double and float that is another story, they are often different.

On the other hand -- it never hurts to do it right.  If you wanted to fix all the "if" statements that would be fine too :-)

E

On 5/1/2013 9:39 PM, 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

Specifically:

https://github.com/lamefun/libxml2/blob/sanity/include/libxml/tree.h#L512

and

https://github.com/lamefun/libxml2/blob/sanity/include/libxml/tree.h#L1334

I'm documenting all the insanity and adding safe cast functions like
xmlDocToNode and xmlNodeToDoc that check node types.

If I'm doing something stupid, please tell me.




  

-- 
Eric S. Eberhard
VICS
2933 W Middle Verde Road
Camp Verde, AZ  86322

928-567-3727  work                      928-301-7537  cell

http://www.vicsmba.com/index.html             (our work)
http://www.vicsmba.com/ourpics/index.html     (fun pictures)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]