#224 Use new libxml2 buffer API

Stable
open-accepted
None
5
2015-02-19
2013-05-24
No

These compile-time warnings appear when compiling Liferea with libxml2 >= 2.9.0, e.g. on my Ubuntu 13.04 system:

update.c: In function update_apply_xslt:
update.c:332:3: warning: passing argument 1 of xmlBufferLength from incompatible pointer type [enabled by default]
In file included from /usr/include/libxml2/libxml/parser.h:16:0,
                 from update.c:25:
/usr/include/libxml2/libxml/tree.h:741:3: note: expected ‘xmlBufferPtr’ but argument is of type ‘xmlBufPtr’
update.c:333:4: warning: passing argument 1 of xmlBufferContent from incompatible pointer type [enabled by default]
In file included from /usr/include/libxml2/libxml/parser.h:16:0,
                 from update.c:25:
/usr/include/libxml2/libxml/tree.h:734:3: note: expected ‘xmlBufferPtr’ but argument is of type ‘xmlBufPtr’

Similar in render.c. This appears to be related to these changes in the API. Here's a patch that upgrades to the new API if available, although current code works because the new struct is binary compatible with the old.

I was a little bit confused about the various different old and new buffer size functions in libxml that are variably called "size", "length" and "use", but as far as I can understand (also see discussion after the linked message above) they do refer to the same thing: the buffer size. :)

Regards, Simon

1 Attachments

Discussion

  • Adrian Bunk

    Adrian Bunk - 2013-05-25

    What exactly is the relation between xmlBufferPtr and xmlOutputBufferPtr?

    Is it correct to call xmlOutputBufferGet*() functions on an xmlBufferPtr, as your patch does?

     
  • Simon Kågedal Reimer

    I can't really answer your first question, but as far as I can see the variable buf that is passed to xmlOutputBufferGet*() is declared xmlOutputBufferPtr and initialized with xmlAllocOutputBuffer(NULL), in both places my patch touches (render.c:render_xml() and update.c:update_apply_xslt()).

    By the way, there is a do { ... } while (FALSE); in that function (update_apply_xslt) that seems to have lost its purpose.

     
    • Adrian Bunk

      Adrian Bunk - 2013-05-25

      My bad, I looked at the wrong place.

      Regarding the while loop in update_apply_xslt(), it is still needed. It is perhaps more common to implement such a logic using goto's, but the while(FALSE) approach is also valid.

       
      • Simon Kågedal Reimer

        Right, of course. Was looking a bit too quick there!

         
  • Emilio Pozuelo Monfort

    Sounds like 1.11 material

     
    • Simon Kågedal Reimer

      Yes, it can absolutely wait.

       
  • Lars Windolf

    Lars Windolf - 2014-01-14

    Merged for 1.11.0 in git master.

     
  • Lars Windolf

    Lars Windolf - 2014-01-14
    • status: open --> open-accepted
    • assigned_to: Lars Windolf
     

Log in to post a comment.