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)
_______________________________________________
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml