Re: [xml] xmllib2-2.3.4 compiler warnings on QNX

On Fri, Mar 23, 2001 at 11:29:02AM +0100, Peter Jacobi wrote:
Hi Daniel, All,

   if this is the use of COPY_BUF macro it seems, I don't see how
the compiler can detect an unreachable code in

#define COPY_BUF(l,b,i,v)                                     \
    if (l == 1) b[i++] = (xmlChar) v;                                   \
    else i += xmlCopyChar(l,&b[i],v)

int val = xmlParseStringCharRef(ctxt, &str);
if (val != 0) {

  And I would appreciate insight on who's wrong there...

Calling COPY_BUF with first parameter (l) equal 0 will never process the 
b[i++] = (xmlChar) v part.

  Dohh, right ..
Question is, would calling xmlCopyChar() directly be any better ?
Maybe ...

I'm looking at a old sources (2.2.11), but I assume the documentation for 
xmlCopyChar is out of sync, as the first parameter is referred to as 
@len:  pointer to the length of the char read (or zero)

  hum, not really. In this case there was nothing read or at least
not as a char. Having len == 0 indicates we don't know what's the size
of the UTF8 serialization of this character.

On a related topic, the len parameter is hardly used in xmlCopyChar and 
can probably be eliminated, along with the code branch computing len 
when the parameter is zero:

  there is 2 things:
    - xmlCopyChar is public, it is exported from parserInternals.h
      so we can't change its signature now
    - I tend to agree that the len > 1 case don't make an useful
      use of the information. Would your patch still improve things
      considering we still pass the len parameter ? I.e. is it
      faster or cleaner ?

 Seems I have troubles making decisions today ...


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]