Re: [xml] xmlFreeStr



[ Bcc'ing the Gnome 2 release team, this a request for libxml2 API extension ]

On Sat, Jan 26, 2002 at 12:55:07PM +0100, Petr Kozelka wrote:
Hello Daniel,

after some discussions and experiments, we discovered that the best (and nearly only) way to release memory 
allocated for strings in
libxml2 is, to have an API function there; anything else would be just a workarround. As Martijn Brinkers 
wrote:

  I'm still a bit unconvinced.
Have you tried to:
   1/ make wrapper around you own set of malloc/free/realloc/strdup functions
   2/ call xmlMemSetup() with those at the initialization of the 
      libxml2 wrapper.

Can you try it and check it does not work ! If it does work then the
API extension is IMHO unnecessary.

[ http://www.geocrawler.com/lists/3/SourceForge/13788/0/7648278  ]
Personally I think providing a exported function xmlFree (like you did) is
more elegant. It just happened that the dll was build with VC++ and that the
function is exported but this is not 'by design'. Now if I would like to
recompile everything with C++ builder I will have to export that same (VC++)
function myself. So my point is that it should be (by design) a part of the
API and not just a 'coincidence'. So I would 'urge' the maintainer to add it
to the API, not just because we only need it but all user who do not use
VC++ will use it.

My opinion is that it makes the API well ballanced, if it enables the user to deallocate anything that has 
been allocated by its
other parts.
Also, take in consideration that adding this function will help in extending the library to one more 
platform (Delphi on Win32)
which might be of some importance.

  Okay. In a nutshell, the current API for freeing data allocated by the
library is xmlFree() defined as a pointer to the current freeing function.
The use of this pointer is impossible for you and you need a real function
entry point. This is clearly not string specific. So the name is in my 
opinion badly chosen.
  xmlFreeFunction() seems more appropriate.
  The other related question is whether you would need access to other
entry points from the same group, namely xmlMalloc() and xmlRealloc()
which are also exported as pointer to functions.
  I think if I go to the relative pain of extending the API again I want
to do it for good and not have to revisit this in 2 months. So I'm suggesting
to add
  xmlFreeFunction()
  xmlMallocFunction()
  xmlReallocFunction()

 with the same set of signature as their pointer counterparts.

I am aware that you said that "...adding new APIs is a problem ATM..." [
http://mail.gnome.org/archives/xml/2002-January/msg00209.html ]
May I ask you when will this not be problem, and what causes it ?

  libxml2 is part of the Gnome2 platform which entered an API freeze.
I will try to see if there is opposition to exten the API in this
case, I'm Carbon Copying them on this answer.

The implementation is of course trivial, but perhaps it helps you to have it here at hand:
---------------------
/**
 * xmlxmlFreeStr:
 * Deallocate the string allocated by an api call.
 */
void
xmlFreeStr(xmlChar* str)
{
    free(str);

  wrong this would have to be xmlFree() ! It still unclear to me that
you really understood how libxml2 memory allocation handler really works.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard redhat com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/



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