Re: [xml] Proposal: expose the new xmlBufShrink() to the "public" API for compatibility with xmlBufUse()

[Daniel Veillard <veillard redhat com>]

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/
daniel veillard com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/