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) |