Re: [xml] libxml2 API crazy?
You are right -- must be a reason I buy cars and keep them a long time (my 1980 Toyota 4x4 I bought new and now it has historic vehicle plates) -- I think things should last. And if they work, don't change them JUST for the sake of change. There is so much to do that needs doing, re-doing things that work is madness. IMHO. My software was written around 1980 -- it is a complete ERP system (that talks to business partners, shipping companies, credit cards -- ALL with libxml2) -- it is STILL character based, still sells well including many big-name companies and systems as large as 12,000 users. It uses a home-grown modified b-tree database. It is full of added functionality since 1980, and absolutely zero technology changes. There is a market for it -- I know it is not for everyone. Essentially I get away with a very inexpensive hardware environment (from the machine to network to backups to hard support), inexpensive database, etc -- that does a LOT of work. It is a work horse, not a pretty horse. I generally sell into industries with low gross margin that need to handle comparatively large numbers of transactions (say T-Shirt distributors where a shirt costs 1.35 and they make 3 cents -- it takes a LOT of transactions to do 100 million in sales and they don't have a lot of margin to throw away on anything). Hence I stay relevant in that niche. It is also why I like Unix (we use Linux, AIX, and a lot of lesser-knowns) -- it is made to last a long time. I have had customers with the same machine for 20 years. We just had a customer who we thought was long dead that called after ... 20 years ... and wanted an upgrade. They had never had one (we were Y2K compliant a long time ago). In their case our software worked too well for too long and when they finally had a problem they became a paying customer again. E On 5/7/2013 9:51 PM, Daniel Veillard wrote: On Mon, May 06, 2013 at 11:10:46AM -0700, Eric S. Eberhard wrote: [...] So they paid a nice young man to replace my server with a JAVA server (why do people feel compelled to replace working programs I'll never know -- guess the new IT person had to feel important). JAVA has built-in XML and TCP/IP and it was so easy to program, yack yack ... it also fell to it's knees at volumes that would be about 10,000 documents per day if it did not crash and burn when the load got high. That is less than 1/2% of what my libxml2 server can process. This, of course, led to AIX trashing and the IT guy wanted a room full of Linux boxes with server load balancing and all kinds of things. Fortunately sanity prevailed and the new IT guys is gone. The cheap little AIX box purrs doing all that work (and running the order desk, inventory, warehouse, shipping, credit, accounting -- all in real time all on one little box) ... Well I'm sure you too got similar story 20 years ago but with ASM or FORTRAN instead of C, some kind of mainframe instead of AIX, etc :-) . What we wrote will be obsolete sometimes. My own personal goal when I code is make sure the code will stay around for long, mothing depresses me as much as my code going to the trash (which happened a few times, and one of the reason why I do only Open Source code). But admitedly this is against a global economic trend, stuff is being designed to be wasted, replaced unresonably soon, and unfortunately that's true for code too even if it's so damn hard to get out and running. That's why I actually love Linux, there is no constraints put into the code to make it suitable only to a timeframe, a platform, or any specific use. Sorry for going from the anecdotic to philosophic, but that thread was already diverging :-) Daniel -- 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
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)
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] libxml2 API crazy?
It is hard to argue with someone that is technically correct. I am glad they mandated order as I have always programmed that way. Now I can sleep better, thanks :-) However, I am old, experienced, etc. C was not what it is now 30 years ago. libxml came along and solved a problem. It is nicely coded, simple to read and understand, and FREE and supported. I have used so much for so many years (and I have contributed occasionally) that I feel some pride in it. I think many of us on the list and using the product feel that way and are happy with the product. And for us old guys real programmers read code and documentation is for those too stupid to figure it out for themselves (and that is a joke of sorts even if half true) :-( :-D :-P :-* If some nice young new person wants to jump in and fix things (that for us are not broken) -- I suspect it would be fine. BUT -- it must remain 100% compatible. So if you recast things in function calls ... some people may fund their code does not compile any more unless they run around re-casting stuff. Might piss people off. Me -- since I use my own abstraction layer, I would care very little. I could re-do my code in an hour even though I use it literally in hundreds of places. You might think on that -- see if you can re-cast again in the functions to make them safer. Or better -- use a sizeof to make sure the padding did not mess with you. Or just add documentation :-) Or add a wrapper level so that people can use the old functions as-is and use more modern better casted functions if they chose. In 5-10 years when I retire and have time I'll help :-) I've actually always wanted to donate my wrappers as they are very useful and cut the coding to a fraction to use libxml2 ... E On 5/2/2013 8:31 PM, Nikita Churaev wrote: I bet nobody would complain about documentation! Normal people who value their time will. XML is the official data format of planet Earth. Every programming platform must have a decent, well-documented XML API if it is to survive. 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 think they've made it standard: http://stackoverflow.com/questions/628526/is-short-circuiting-boolean-operators-mandated-in-c-c-and-evaluation-order 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. Someone on this list said they've made it standard too. 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 :-) The problem is not portability, people said all things that libxml2 uses are standard, but lack of docs: without reading the libxml2 code, you can't know what element types XML_ELEMENT_NODE, XML_TEXT_NODE structures (xmlDoc, xmlNode, xmlAttr) correspond to, etc. There are lots upon lots of quirks with xmlNodePtr: https://github.com/lamefun/libxml2/blob/efd3b16f974d64e3dde05228a1ed9a70c9b4421e/include/libxml/tree.h#L580 -- 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
Re: [xml] libxml2 API crazy?
I agree, Daniel -- I love them -- and have done VERY well with them. Rock solid code and for me, easy to understand and use. I've thanked you before I'll thank you again. E On 5/3/2013 7:23 AM, 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 -- 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
Re: [xml] libxml2 API crazy?
Daniel said The key point is the absolute imperative of keeping API and ABI stability. I would add -- ALL changes must be 100% compatible -- with ALL of the O/S libxml2 runs on. Which is daunting. The switch from libxml to libxml2 was a minimal change despite a vast increase in functions and usability. Certainly any cleaning up needs to not make people's code not compile. And making it work with PHP, Linux, AIX, SCO, TI, HP, etc -- you have to be careful and most people don't even have access to a lot of platforms like that. What works on Linux may not work on AIX or SCO. And vice-versa. Some of what looks like confusion is really odd code to make it work everyplace -- I know, a decade ago I cleaned something up on my AIX box and it crashed and died when I put it on Linux. Then I knew why it was odd code. Simple things like the PRAGMA statement are different (otherwise it could solve the padding issue you brought up -- and easy fix is to stop padding altogether and suffer the minimal performance hit). I suggest, Nikita, that you study and look around some more ... although I see no objection to the example you gave I still would bet if a poll was made, most people already have their own abstraction layer. I was going to offer mine years ago and that was one issue Daniel reminded me of along with the fact that it was more work than just giving the code -- I'd have to make it work for everything on earth, not an easy task. E On 5/3/2013 9:36 AM, Daniel Veillard wrote: On Fri, May 03, 2013 at 08:17:12PM +0400, Nikita Churaev wrote: 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. I originally planned to format a patch with git from my first commit to last when I get something finished and file it to Bugzilla (or should I file it here to the list?), with proper explanation. Actually I'm going to scrap the branch and start anew, without moving the functions around. What do you want to achieve ? I think I understand but it is better if stated. Then we can see how to get there with minimal disruption and a clear set of patch each doing one step. Probably don't need to scrap everything, but reorganize in an easy to follow/review set. The key point is the absolute imperative of keeping API and ABI stability. I would also prefer to not add too many new entry points for both human and technical reasons (first because the API is confusingly too big already, and second because the resolution of all entry points in ELF shared library may turn quadratic and we are already quite big) Beside that I will hadly say no to anything improving documentation :-) thanks ! Daniel -- 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
Re: [xml] libxml2 API crazy?
I agree with everything except ... I still use plain old C ... I just
make my wrappers manage a lot of the underlying things. I would
moderate your description a little -- these are low-level routines. It
would be like comparing C to C++ -- it is not that C is so limited, it
is for a different purpose. It is faster and more efficient -- and
clumsier to work with.
To each his own. I probably should not have gotten into this thread
except I have used this library for so long and it has been so good to
me, I hated to see it trashed -- of course it can be better, but it is
free. When I needed some improvements, I made them and submitted them
and Daniel incorporated them. Cool. If you are willing to do the work
... you can have whatever you like. It might be nice someday to have a
place for everyone to share their wrappers. Mine (IMHO) are unique and
useful. I am sure others are as well.
I WOULD be willing to put some time into making a wrapper suppository ...
Eric
On 5/3/2013 6:21 PM, Sam Varshavchik wrote:
Nikita Churaev writes:
I'm glad that the layer of abstraction helped you personally, but
libxml2 really needs to be usable as-is and the GObject wrappers (GXml,
etc.) should just be trivial things. If wrappers are made but the
libxml2 itself is kept in this current insane state, it'll just become
more and more entangled, so no one will step up to maintain it if the
current maintainer leaves and it will die. XML is the most important
data format in the world, in fact, the official data format of planet
Earth, if GNOME is to survive, it should better have a well-documented,
maintainable and sane XML API. Without an XML API usable by normal
people who value their time, GNOME will surely die.
I think that, for what it is, namely a C API library, libxml2 is quite
usable, and the API is clean, and logical.
But I wouldn't use it directly for large scale application
development. The reason being that, at least in my corner of the
world, C is simply not suitable for developing large, complicated
applications. Those beasts are written, pretty much exclusively these
days, in C++. And libxml2 simply lives on a different, lower level,
than C++, and you need higher level C++ bindings to be productive, so
I've written my own bindings: http://www.libcxx.org/xml.html
If I wanted to write out a simple Hello world, in XHTML, more or less:
auto doc=x::xml::doc::create();
doc-writelock()-create_child()-element({html})-element({body})
-element({p, {
{style, font-family: courier new}
}})-text(Hello)-parent()-create_next_sibling()
-element({p, {
{style, font-family: arial}
}})-create_child()-text(world!);
doc-readlock()-save_file(filename.xml);
Doing the equivalent directly using libxml2's native API calls
probably take a little bit longer than eight lines of code, if you
also need the results to be: 1) thread safe, and 2) take care of
releasing all memory/objects/handles/etc (thread safety is not a
factor in this particular case, but, if something was going on in that
area, this would be thread safe).
This creates a simple XML document, using libxml2's tree API, and
saves it. Of course, you can just dump a literal string into a file
directly, but that's besides the point.
Once code grows besides a certain size, the additional burden of
releasing all handles, and resources, to avoid leaking memory,
implementing thread safety, and other tedious tasks, just adds to the
overhead. The above example uses reference-counted objects, and once
all variables and objects go out of scope, all libxml2-obtained
resources will get released, and I'll have better things to worry
about, with my time, than that.
The native C-based libxml2 API is just not feasible for non-trivial
tasks. You need to keep track of all the objects/memory that it
creates for you. You need to make arrangements for implementing
everything in a thread-safe manner. And I really don't really want to
spend a lot of time doing that, so libxml2 native API is just not
enough, but it's perfectly fine as a foundation for more higher-level
API abstractions, and I don't think there's anything wrong with that.
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
--
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
Re: [xml] libxml2 API crazy?
I never thought of it ... I just code as suggested:
node-parent == node-doc or node-parent-type ==
XML_ELEMENT_NODE/XML_DOCUMENT_NODE and so on before you assume it really
is a xmlNode
In fact, I always test the type before doing anything EXCEPT that one node-parent
== node-doc test which somehow I picked up someplace (old samples?) I just don't
find it strange AT ALL in the C world to have pointers that point to different things
and need conditional processing based on a type. Try coding with Oracle's C
interface for example (not the SQL or higher language, they still have an actual C
interface). It has all kinds of pointers to all kinds of things that require tests
if they are non-NULL and what type they are. C is not a language that has objects
and protections against everything ... it is a language great for performance when
coded properly.
As an example, I have a customer that hired a new IT manager who decided that using my
old fashioned non-object oriented hard to program (if you don't know C :-) ),
etc. server program was awful and needed to be replaced. It is a simple server fired up
by inetd and reads in an XML document and returns one (generally after doing some
database calls -- it servers Web pages and large XML file uploads for example 1,000
orders in a batch from Walmart. On a VERY modest AIX box I process in and out about 2.5
million documents in a day.
So they paid a nice young man to replace my server with a JAVA server (why do people feel
compelled to replace working programs I'll never know -- guess the new IT person had to
feel important). JAVA has built-in XML and TCP/IP and it was so easy to
program, yack yack ... it also fell to it's knees at volumes that would be about 10,000
documents per day if it did not crash and burn when the load got high. That is less than
1/2% of what my libxml2 server can process. This, of course, led to AIX trashing and the
IT guy wanted a room full of Linux boxes with server load balancing and all kinds of
things. Fortunately sanity prevailed and the new IT guys is gone. The cheap little AIX
box purrs doing all that work (and running the order desk, inventory, warehouse,
shipping, credit, accounting -- all in real time all on one little box) ...
E
On 5/3/2013 9:15 PM, Callum Gibson wrote:
Thanks for that.
I guess my only comment is that doc-type and node-type are there for
a reason. But I agree it's a bit disingenuous to be traversing up a tree
via -parent and discover that you've hit a node which is actually a xmlDoc.
In practice this means always having to have a special case test for
node-parent == node-doc or node-parent-type ==
XML_ELEMENT_NODE/XML_DOCUMENT_NODE and so on before you assume it really is a xmlNode.
I'm not even sure why the root node parent of a doc points to the xmlDoc
given that there is a node-doc value to use if you want it.
On 04May13 07:35, Nikita Churaev wrote:
}this gives out an error:
}
}#includelibxml/parser.h
}#includelibxml/tree.h
}#includestdio.h
}
}int
}main (int argc, char** argv)
}{
} xmlDocPtr doc = xmlReadMemory(doc/, 6, egg.xml, NULL, 0);
}
} /* XmlNode *//* XmlDoc */
} printf(%s\n, (doc-children-parent == doc) ? true : false);
} return 0;
}}
}
}and this crashes on my machine (as xmlDoc has different fields than
}xmlName):
}
}#includelibxml/parser.h
}#includelibxml/tree.h
}#includestdio.h
}
}int
}main (int argc, char** argv)
}{
} xmlDocPtr doc = xmlReadMemory(doc/, 6, egg.xml, NULL, 0);
}
} if (doc-children-parent-ns doc-children-parent-ns-href)
}printf(%s\n, doc-children-parent-ns-href);
}
} return 0;
}}
--
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
Re: [xml] libxml2 API crazy?
On Mon, May 06, 2013 at 11:10:46AM -0700, Eric S. Eberhard wrote: [...] So they paid a nice young man to replace my server with a JAVA server (why do people feel compelled to replace working programs I'll never know -- guess the new IT person had to feel important). JAVA has built-in XML and TCP/IP and it was so easy to program, yack yack ... it also fell to it's knees at volumes that would be about 10,000 documents per day if it did not crash and burn when the load got high. That is less than 1/2% of what my libxml2 server can process. This, of course, led to AIX trashing and the IT guy wanted a room full of Linux boxes with server load balancing and all kinds of things. Fortunately sanity prevailed and the new IT guys is gone. The cheap little AIX box purrs doing all that work (and running the order desk, inventory, warehouse, shipping, credit, accounting -- all in real time all on one little box) ... Well I'm sure you too got similar story 20 years ago but with ASM or FORTRAN instead of C, some kind of mainframe instead of AIX, etc :-) . What we wrote will be obsolete sometimes. My own personal goal when I code is make sure the code will stay around for long, mothing depresses me as much as my code going to the trash (which happened a few times, and one of the reason why I do only Open Source code). But admitedly this is against a global economic trend, stuff is being designed to be wasted, replaced unresonably soon, and unfortunately that's true for code too even if it's so damn hard to get out and running. That's why I actually love Linux, there is no constraints put into the code to make it suitable only to a timeframe, a platform, or any specific use. Sorry for going from the anecdotic to philosophic, but that thread was already diverging :-) Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] libxml2 API crazy?
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'm glad that the layer of abstraction helped you personally, but libxml2 really needs to be usable as-is and the GObject wrappers (GXml, etc.) should just be trivial things. If wrappers are made but the libxml2 itself is kept in this current insane state, it'll just become more and more entangled, so no one will step up to maintain it if the current maintainer leaves and it will die. XML is the most important data format in the world, in fact, the official data format of planet Earth, if GNOME is to survive, it should better have a well-documented, maintainable and sane XML API. Without an XML API usable by normal people who value their time, GNOME will surely die. ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] libxml2 API crazy?
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 -- Daniel Veillard | Open Source and Standards, Red Hat veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] libxml2 API crazy?
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
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] libxml2 API crazy?
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. I originally planned to format a patch with git from my first commit to last when I get something finished and file it to Bugzilla (or should I file it here to the list?), with proper explanation. Actually I'm going to scrap the branch and start anew, without moving the functions around. ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] libxml2 API crazy?
On Fri, May 03, 2013 at 08:17:12PM +0400, Nikita Churaev wrote: 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. I originally planned to format a patch with git from my first commit to last when I get something finished and file it to Bugzilla (or should I file it here to the list?), with proper explanation. Actually I'm going to scrap the branch and start anew, without moving the functions around. What do you want to achieve ? I think I understand but it is better if stated. Then we can see how to get there with minimal disruption and a clear set of patch each doing one step. Probably don't need to scrap everything, but reorganize in an easy to follow/review set. The key point is the absolute imperative of keeping API and ABI stability. I would also prefer to not add too many new entry points for both human and technical reasons (first because the API is confusingly too big already, and second because the resolution of all entry points in ELF shared library may turn quadratic and we are already quite big) Beside that I will hadly say no to anything improving documentation :-) thanks ! Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] libxml2 API crazy?
What do you want to achieve ? I think I understand but it is better if
stated.
Make so you can use libxml2 and be sure that you use it correctly rather
than just blindly guess.
The main problem here is casting quirks, libxml2 tree seems to cast
xmlDoc*, xmlAttr* and even xmlNs* into xmlNode*, so not only the fields
after the common node parts are unsafe to access without checking, even
ones in the common part are, except xmlElementType type. The
documentation provides no answer whatsoever on what structures
correspond to each xmlElementType. Casting xmlNs* to xmlNode* is the
worst one.
I want to add:
safe casting functions, for example:
xmlNodePtr xmlDocToNode(xmlDocPtr node);
xmlDocPtr xmlNodeToDoc(xmlNodePtr node); // returns NULL if
// node is not a doc
safe accessor functions for the common part (this might not be needed if
casting of xmlNs* to xmlNode* is only needed for dead code), for
example:
xmlNodePtr
xmlGetNextSibling (xmlNodePtr node)
{
if (node == NULL)
return NULL;
/* struct _xmlNs, doesn't have the common node part */
if (node-type == XML_NAMESPACE_DECL)
return NULL;
return node-next;
}
documentation, eg:
https://github.com/lamefun/libxml2/blob/5e06cbb88c1debbfbb8ad047e0a2e46f691cf09e/include/libxml/tree.h#L572
Probably don't need to scrap
everything, but reorganize in an easy to follow/review set.
I moved too many functions around the tree.h and tree.c, this will make
the patch hard to read. I'll just do all the same changes I made, but
without moving stuff around too much.
The key point is the absolute imperative of keeping API and ABI
stability.
I don't want to break anything. I'll add documentation (only editing the
comments), and add some new functions that hide all the crazy things.
I would also prefer to not add too many new entry points
for both human and technical reasons (first because the API is confusingly
too big already, and second because the resolution of all entry points in
ELF shared library may turn quadratic and we are already quite big)
I think the human problem is solvable by adding categories in the
documentation.
Also, things will be much more simple if casting xmlNs* to xmlNode* is
only used by dead code and is not a normal behavior, like some people
suggested on IRC, the common part will them be safe to access directly.
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] libxml2 API crazy?
On 03May13 22:44, Nikita Churaev wrote: } What do you want to achieve ? I think I understand but it is better if } stated. } }Make so you can use libxml2 and be sure that you use it correctly rather }than just blindly guess. } }The main problem here is casting quirks, libxml2 tree seems to cast }xmlDoc*, xmlAttr* and even xmlNs* into xmlNode*, so not only the fields }after the common node parts are unsafe to access without checking, even }ones in the common part are, except xmlElementType type. The }documentation provides no answer whatsoever on what structures }correspond to each xmlElementType. Casting xmlNs* to xmlNode* is the }worst one. You seem to be talking about the internal implementation, rather than use of the API? Can you provide specific examples in the code of how one might be using the API in a valid fashion (ie. as documented and per the examples) and yet be potentially using the wrong struct type? If you are worried about polymorphic aspects of using certain structures this is perfectly standard behaviour and, as I mentioned earlier, has been well-known since KR 2nd edition. It's also used extensively in the X11 API and associated widget toolkits. }I want to add: } }safe casting functions, for example: } }xmlNodePtr xmlDocToNode(xmlDocPtr node); } }xmlDocPtr xmlNodeToDoc(xmlNodePtr node); // returns NULL if } // node is not a doc Why would an application being using docs as nodes and vice versa? Can you give examples where this happens? regards, Callum -- Callum Gibson @ home ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] libxml2 API crazy?
On Fri, May 03, 2013 at 10:40:48AM -0700, Eric S. Eberhard wrote: I agree, Daniel -- I love them -- and have done VERY well with them. Rock solid code and for me, easy to understand and use. I've thanked you before I'll thank you again. E Thanks Eric ! If there is ways to improve code and people willing to put the effort I will take them though, as it is clearly far from perfect. The documentation unfortunately covers only a small subset of the possible uses, and some of the tricks we are used to but confuse beginners ought to be spelled out :-) Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] libxml2 API crazy?
Thanks for that.
I guess my only comment is that doc-type and node-type are there for
a reason. But I agree it's a bit disingenuous to be traversing up a tree
via -parent and discover that you've hit a node which is actually a xmlDoc.
In practice this means always having to have a special case test for
node-parent == node-doc or node-parent-type ==
XML_ELEMENT_NODE/XML_DOCUMENT_NODE and so on before you assume it really is a
xmlNode.
I'm not even sure why the root node parent of a doc points to the xmlDoc
given that there is a node-doc value to use if you want it.
On 04May13 07:35, Nikita Churaev wrote:
}this gives out an error:
}
}#include libxml/parser.h
}#include libxml/tree.h
}#include stdio.h
}
}int
}main (int argc, char** argv)
}{
} xmlDocPtr doc = xmlReadMemory(doc/, 6, egg.xml, NULL, 0);
}
} /* XmlNode *//* XmlDoc */
} printf(%s\n, (doc-children-parent == doc) ? true : false);
} return 0;
}}
}
}and this crashes on my machine (as xmlDoc has different fields than
}xmlName):
}
}#include libxml/parser.h
}#include libxml/tree.h
}#include stdio.h
}
}int
}main (int argc, char** argv)
}{
} xmlDocPtr doc = xmlReadMemory(doc/, 6, egg.xml, NULL, 0);
}
} if (doc-children-parent-ns doc-children-parent-ns-href)
}printf(%s\n, doc-children-parent-ns-href);
}
} return 0;
}}
--
Callum Gibson @ home
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] libxml2 API crazy?
I bet nobody would complain about documentation! Normal people who value their time will. XML is the official data format of planet Earth. Every programming platform must have a decent, well-documented XML API if it is to survive. 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 think they've made it standard: http://stackoverflow.com/questions/628526/is-short-circuiting-boolean-operators-mandated-in-c-c-and-evaluation-order 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. Someone on this list said they've made it standard too. 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 :-) The problem is not portability, people said all things that libxml2 uses are standard, but lack of docs: without reading the libxml2 code, you can't know what element types XML_ELEMENT_NODE, XML_TEXT_NODE structures (xmlDoc, xmlNode, xmlAttr) correspond to, etc. There are lots upon lots of quirks with xmlNodePtr: https://github.com/lamefun/libxml2/blob/efd3b16f974d64e3dde05228a1ed9a70c9b4421e/include/libxml/tree.h#L580 ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] libxml2 API crazy?
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. ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] libxml2 API crazy?
OK, so this is really guaranteed by the standard, good. But how libxml2
uses that is still insane. In GTK+, I can always expect a GtkWidget * to
point to a GtkWidget or a descendant (like GtkButton), so I can be sure
that all of its stucture fields don't contain garbage or point outside
the structure (I'm sure that the last field of xmlDoc (int properties)
points outside xmlNode's last element (int extra) and if I accidentally
try to access it in the xmlNodePtr that really points to an xmlDoc, my
program will end up with corrupted memory or crash). I'd expect libxml2
to have a common structure that only contains the common part, like
this:
/* this only contains the common part */
typedef strcut xmlNode {
void*_private; /* application data */
xmlElementType type; /* type number */
const xmlChar *name; /* used differently */
struct _xmlNode *children; /* parent-childs link */
struct _xmlNode *last; /* last child link */
struct _xmlNode *parent;/* child-parent link */
struct _xmlNode *next; /* next sibling link */
struct _xmlNode *prev; /* previous sibling link */
struct _xmlDoc *doc; /* the containing document */
};
typedef struct xmlDoc {
void*_private; /* application data */
xmlElementType type; /* type number */
const xmlChar *name; /* used differently */
struct _xmlNode *children; /* parent-childs link */
struct _xmlNode *last; /* last child link */
struct _xmlNode *parent;/* child-parent link */
struct _xmlNode *next; /* next sibling link */
struct _xmlNode *prev; /* previous sibling link */
struct _xmlDoc *doc; /* the containing document */
/* end of common part */
/* document specific stuff */
};
/* what the current xmlNode seems to be */
typedef struct xmlTagOrText {
void*_private; /* application data */
xmlElementType type; /* type number */
const xmlChar *name; /* used differently */
struct _xmlNode *children; /* parent-childs link */
struct _xmlNode *last; /* last child link */
struct _xmlNode *parent;/* child-parent link */
struct _xmlNode *next; /* next sibling link */
struct _xmlNode *prev; /* previous sibling link */
struct _xmlDoc *doc; /* the containing document */
/* end of common part */
/* tag-or-text specific stuff */
};
/* useful help functions */
xmlDocPtr xmlToDoc(xmlNodePtr node) {
if (node-type == XML_DOCUMENT_NODE)
return (xmlDocPtr)node;
else
return NULL;
}
xmlTagOrTextPtr xmlToTagOrText(xmlNodePtr node) {
if (node-type == XML_ELEMENT_NODE
|| node-type == XML_TEXT_NODE
|| node-type == XML_CDATA_SECTION_NODE)
return (xmlTextOrTagPtr)node;
else
return NULL;
}
On Mon, 2013-04-29 at 01:06 -0400, Liam R E Quin wrote:
On Mon, 2013-04-29 at 08:32 +0400, Nikita Churaev wrote:
It doesn't have anything to do with C standard.
It does. Take for example:
struct A {
int q;
int w;
/* end of common part */
float x;
};
struct B {
int q;
int w;
/* end of common part */
double x;
};
What if the C standard allows the compiler to place q and w further
apart in struct A than in struct B?
Then every kernel or device driver on the planet would break, as would
large amount of application code. But it doesn't allow the compiler that
freedom.
C specifies the behaviour very precisely and carefully exactly so you
can do this. See structure padding...
Liam
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] libxml2 API crazy?
On Mon, 2013-04-29 at 21:26 +0400, Nikita Churaev wrote: OK, so this is really guaranteed by the standard, good. But how libxml2 uses that is still insane. The libxml API has been... rather widely used... for more than a decade... Your mail described some of your expectations when coming to libxml2 for the first time but didn't ask any questions. If the answer you are expecting is oh, sorry, you're right, we'll change both the ABI and the API now and break everything I'm not sure this is a good time to do that :-) If there were to be a libxml3 it would be a time to try and think about reworking it to support XSLT 3 and XPath 3 but I don't see that happening, no-one has the time. If you're wondering about the documentation, and it's available for your operating environment, the devhelp program has the libxml2 documentation neatly indexed. OK, that's more than enough guessing on my part :-) Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org freenode/#xml ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] libxml2 API crazy?
On 4/29/2013 07:30, Nikita Churaev wrote:
#include libxml/parser.h
#include libxml/tree.h
#include stdio.h
int
main (int argc, char** argv)
{
xmlDocPtr doc = xmlReadMemory(doc/, 6, egg.xml, NULL, 0);
/* XmlNode *//* XmlDoc */
printf(%s\n, (doc-children-parent == doc) ? true : false);
return 0;
}
This gives out true... Why? xmlNode.parent is xmlNodePtr... So I can't
just rely on xmlNode pointers to actually point to xmlNode?
Just take a look what xmlDocPtr actually is - document is also a node.
I looked all
around the API reference and tutorials and found nothing on this topic.
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] libxml2 API crazy?
No it's not.
http://xmlsoft.org/html/libxml-tree.html#xmlDoc
http://xmlsoft.org/html/libxml-tree.html#xmlNode
xmlDoc has int compression instead of xmlNode's xmlNs
On Mon, 2013-04-29 at 07:48 +0400, Nikolay Sivov wrote:
On 4/29/2013 07:30, Nikita Churaev wrote:
#include libxml/parser.h
#include libxml/tree.h
#include stdio.h
int
main (int argc, char** argv)
{
xmlDocPtr doc = xmlReadMemory(doc/, 6, egg.xml, NULL, 0);
/* XmlNode *//* XmlDoc */
printf(%s\n, (doc-children-parent == doc) ? true : false);
return 0;
}
This gives out true... Why? xmlNode.parent is xmlNodePtr... So I can't
just rely on xmlNode pointers to actually point to xmlNode?
Just take a look what xmlDocPtr actually is - document is also a node.
I looked all
around the API reference and tutorials and found nothing on this topic.
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] libxml2 API crazy?
On 4/29/2013 07:59, Nikita Churaev wrote:
No it's not.
http://xmlsoft.org/html/libxml-tree.html#xmlDoc
http://xmlsoft.org/html/libxml-tree.html#xmlNode
xmlDoc has int compression instead of xmlNode's xmlNs
I see what you mean. All node types are using same layout containing basic
stuff to link node in a tree - up to 'doc' field. That's what a comment
in tree.h means:
---
struct _xmlNode {
void *_private;/* application data */
xmlElementType type;/* type number, must be second ! */
const xmlChar *name; /* the name of the node, or the entity */
struct _xmlNode *children;/* parent-childs link */
struct _xmlNode *last;/* last child link */
struct _xmlNode *parent;/* child-parent link */
struct _xmlNode *next;/* next sibling link */
struct _xmlNode *prev;/* previous sibling link */
struct _xmlDoc *doc;/* the containing document */
/* End of common part */
---
So to be clean with casting it should have some sort of header struct
containing these fields only,
and have every node type start with this header, it's just not done this
way. To be safe you always
need to check type and cast appropriately.
On Mon, 2013-04-29 at 07:48 +0400, Nikolay Sivov wrote:
On 4/29/2013 07:30, Nikita Churaev wrote:
#include libxml/parser.h
#include libxml/tree.h
#include stdio.h
int
main (int argc, char** argv)
{
xmlDocPtr doc = xmlReadMemory(doc/, 6, egg.xml, NULL, 0);
/* XmlNode *//* XmlDoc */
printf(%s\n, (doc-children-parent == doc) ? true : false);
return 0;
}
This gives out true... Why? xmlNode.parent is xmlNodePtr... So I can't
just rely on xmlNode pointers to actually point to xmlNode?
Just take a look what xmlDocPtr actually is - document is also a node.
I looked all
around the API reference and tutorials and found nothing on this topic.
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] libxml2 API crazy?
Is this allowed by the C standard? And where is this documented?
On Mon, 2013-04-29 at 08:14 +0400, Nikolay Sivov wrote:
On 4/29/2013 07:59, Nikita Churaev wrote:
No it's not.
http://xmlsoft.org/html/libxml-tree.html#xmlDoc
http://xmlsoft.org/html/libxml-tree.html#xmlNode
xmlDoc has int compression instead of xmlNode's xmlNs
I see what you mean. All node types are using same layout containing basic
stuff to link node in a tree - up to 'doc' field. That's what a comment
in tree.h means:
---
struct _xmlNode {
void *_private;/* application data */
xmlElementType type;/* type number, must be second ! */
const xmlChar *name; /* the name of the node, or the entity */
struct _xmlNode *children;/* parent-childs link */
struct _xmlNode *last;/* last child link */
struct _xmlNode *parent;/* child-parent link */
struct _xmlNode *next;/* next sibling link */
struct _xmlNode *prev;/* previous sibling link */
struct _xmlDoc *doc;/* the containing document */
/* End of common part */
---
So to be clean with casting it should have some sort of header struct
containing these fields only,
and have every node type start with this header, it's just not done this
way. To be safe you always
need to check type and cast appropriately.
On Mon, 2013-04-29 at 07:48 +0400, Nikolay Sivov wrote:
On 4/29/2013 07:30, Nikita Churaev wrote:
#include libxml/parser.h
#include libxml/tree.h
#include stdio.h
int
main (int argc, char** argv)
{
xmlDocPtr doc = xmlReadMemory(doc/, 6, egg.xml, NULL, 0);
/* XmlNode *//* XmlDoc */
printf(%s\n, (doc-children-parent == doc) ? true : false);
return 0;
}
This gives out true... Why? xmlNode.parent is xmlNodePtr... So I can't
just rely on xmlNode pointers to actually point to xmlNode?
Just take a look what xmlDocPtr actually is - document is also a node.
I looked all
around the API reference and tutorials and found nothing on this topic.
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] libxml2 API crazy?
On 4/29/2013 08:18, Nikita Churaev wrote:
Is this allowed by the C standard? And where is this documented?
It doesn't have anything to do with C standard. Not sure if it's
documented anywhere,
you have headers with all that info, personally I just read lib code if
in doubt.
On Mon, 2013-04-29 at 08:14 +0400, Nikolay Sivov wrote:
On 4/29/2013 07:59, Nikita Churaev wrote:
No it's not.
http://xmlsoft.org/html/libxml-tree.html#xmlDoc
http://xmlsoft.org/html/libxml-tree.html#xmlNode
xmlDoc has int compression instead of xmlNode's xmlNs
I see what you mean. All node types are using same layout containing basic
stuff to link node in a tree - up to 'doc' field. That's what a comment
in tree.h means:
---
struct _xmlNode {
void *_private;/* application data */
xmlElementType type;/* type number, must be second ! */
const xmlChar *name; /* the name of the node, or the entity */
struct _xmlNode *children;/* parent-childs link */
struct _xmlNode *last;/* last child link */
struct _xmlNode *parent;/* child-parent link */
struct _xmlNode *next;/* next sibling link */
struct _xmlNode *prev;/* previous sibling link */
struct _xmlDoc *doc;/* the containing document */
/* End of common part */
---
So to be clean with casting it should have some sort of header struct
containing these fields only,
and have every node type start with this header, it's just not done this
way. To be safe you always
need to check type and cast appropriately.
On Mon, 2013-04-29 at 07:48 +0400, Nikolay Sivov wrote:
On 4/29/2013 07:30, Nikita Churaev wrote:
#include libxml/parser.h
#include libxml/tree.h
#include stdio.h
int
main (int argc, char** argv)
{
xmlDocPtr doc = xmlReadMemory(doc/, 6, egg.xml, NULL, 0);
/* XmlNode *//* XmlDoc */
printf(%s\n, (doc-children-parent == doc) ? true : false);
return 0;
}
This gives out true... Why? xmlNode.parent is xmlNodePtr... So I can't
just rely on xmlNode pointers to actually point to xmlNode?
Just take a look what xmlDocPtr actually is - document is also a node.
I looked all
around the API reference and tutorials and found nothing on this topic.
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] libxml2 API crazy?
It doesn't have anything to do with C standard.
It does. Take for example:
struct A {
int q;
int w;
/* end of common part */
float x;
};
struct B {
int q;
int w;
/* end of common part */
double x;
};
What if the C standard allows the compiler to place q and w further
apart in struct A than in struct B? Then if you cast struct A *a into
struct B *b, you'll get garbage in b-w.
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] libxml2 API crazy?
On Mon, 2013-04-29 at 08:32 +0400, Nikita Churaev wrote:
It doesn't have anything to do with C standard.
It does. Take for example:
struct A {
int q;
int w;
/* end of common part */
float x;
};
struct B {
int q;
int w;
/* end of common part */
double x;
};
What if the C standard allows the compiler to place q and w further
apart in struct A than in struct B?
Then every kernel or device driver on the planet would break, as would
large amount of application code. But it doesn't allow the compiler that
freedom.
C specifies the behaviour very precisely and carefully exactly so you
can do this. See structure padding...
Liam
--
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] libxml2 API crazy?
On 29Apr13 08:32, Nikita Churaev wrote: } It doesn't have anything to do with C standard. } }What if the C standard allows the compiler to place q and w further }apart in struct A than in struct B? Then if you cast struct A *a into }struct B *b, you'll get garbage in b-w. See KR II (ie. the ANSI version) pg 213. -- Callum Gibson @ home ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
