Re: [xml] xmlNodeGetContent behavior

On Thu, Jan 03, 2002 at 10:21:47PM -0600, Charlie Bozeman wrote:
I found that when I call xmlNodeGetContent with an element node that has
no content, the return value is non-null. From the header comments I
expected a return value of NULL. Looking at the code (line 3608 of
            ret = buffer->content;
            buffer->content = NULL;
the code is returning the buffer content which is allocated memory with
the first byte set to 0.
What is the correct behavior?

   Well. The functions will return NULL for nodes which obviously
have no text content in the usual sense like nodes from declarations
in the DTD.
   Now in the case of elements without children, one could argue
whether the returned value should be NULL or an empty string. Note
that from a serialization point of view it's not obvious:
    <foo/> is actually equivalent to <foo></foo>
and returning an empty string in the later case doesn't look unexpected.

Maybe the buffer should be created with
xmlBufferCreateSize(0) or the buffer content should be checked for 0
before returning.

  The points of the current behaviour is:
    1/ that function is complex enough, it's used a lot
       for example by the XSLT engine, changing it's effective semantic now
       doesn't sound a good idea
    2/ callers of the functions will have to handle both cases anyway
       (NULL or not NULL return values), so the current behaviour doesn't
       affect client code, at most it affects the size of some temporary

 Maybe the function comments should be updated to reflect the fact that
empty strings may be returned, but it doesn't sound a breakage of the 
behaviour, adding the test before returning at the library level would just
add one more test which would be done anyway in the client code.


Daniel Veillard      | Red Hat Network
veillard redhat com  | libxml Gnome XML XSLT toolkit | Rpmfind RPM search engine

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