Re: [xslt] calling EXSLT function str:replace() without transform context raises memory error in 1.1.27

[Nick Wellnhofer <wellnhofer aevum de>]

On 28/09/2012 15:33, Stefan Behnel wrote:
> Hi,
>
> a side effect of this commit:
>
> http://git.gnome.org/browse/libxslt/commit/?id=0602c535e9c34efca22dba1b1b7465e0618e7bfc
>
> is that the str:replace() function is no longer usable without a transform
> context. I take it from the bug report that it is not supposed to be used
> from plain XPath but only from XSLT according to the EXSLT specification.
>
> However, the previous implementation used to work in XPath and is still
> registered on an xmlXPathContext by the exsltStrXpathCtxtRegister()
> function. When called from plain XPath, it results in a memory error in
> line 526 (exsltStrReturnString()) of strings.c because xsltCreateRVT()
> returns NULL as an error indicator due to a NULL transform context being
> passed in, which was the return value from xsltXPathGetTransformContext() a
> bit further up (and the code doesn't validate that).
>
> I see two ways to deal with this. Either fix the error handling in
> exsltStrReturnString() and deliberately break backwards compatibility by
> removing the function from exsltStrXpathCtxtRegister(), or rewrite the new
> function in a way that makes it work in both contexts, i.e. from both XSLT
> and plain XPath. I have no idea if the latter is possible, but it would
> certainly be the "friendlier" solution.

One of the problems of the old str:replace implementation was that it 
returned a string whereas it should return a node set. From what I 
understand, the nodes in the node set have to be added to a RVT, so they 
will be garbage collected later. I don't see a way to do that without a 
transform context.

The str:tokenize and str:split function do the same thing btw, although 
it seems that they don't raise an error, but simply return an empty node 
set when used without a transform context.

Nick