On Tue, Aug 21, 2012 at 03:05:50PM +0300, Andrew W. Nosenko wrote: > Proposal: expose the new xmlBufShrink() to the "public" API for > compatibility with xmlBufUse(). > > Reason: the following scenario: > > 1. Read something into xmlParserInputBuffer (e.g. using > xmlParserInputBufferRead()) > 2. Extract content through xmlBufContent() > 3. Extract content length through xmlBufUse(). Result have type 'size_t'. > 4. Use this content > 5. Now, you need to shrink the buffer. How to do it? Doing that > through legacy xmlBufferShrink() is unsafe because it uses 'unsigned > int' and the whole point of introducing the new API was handling the > cases, when 'unsigned int' is not enough. Therefore, need to use the > new xmlBufShrink(). But it is "private". > > Therefore, I propose to expose the new xmlBufShrink() in the same way, > as xmlBufContent() and xmlBufUse() are exposed.
Thanks Andrew ! You hit a good point, when I did buf.c I decided to hide most of the APIs and see how people would react to add them back only as needed, and you're the first, congratulations :-) ! Agreed, this makes sense, pushed ! http://git.gnome.org/browse/libxml2/commit/?id=82cdfc4eb338f039024e1619aca8ff14b5c3dc71 Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ [email protected] | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] https://mail.gnome.org/mailman/listinfo/xml
