Re: BUG #18943: Return value of a function 'xmlBufferCreate' isdereferenced at xpath.c:177 without checking for NUL

On Thu, Mar 12, 2026 at 07:00:00AM +0200, Alexander Lakhin wrote:
> Hello Michael,
> 
> Maybe you would like to fix in passing one more anomaly there:
> create extension xml2;
> select xslt_process('<aaa/>','<xsl:stylesheet version="1.0"
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform"></xsl:stylesheet>');
> 
> leads to:
> varlena.c:199:2: runtime error: null pointer passed as argument 2, which is declared to never be null
>     #0 0x640756666936 in cstring_to_text_with_len .../src/backend/utils/adt/varlena.c:199
>     #1 0x7e46c0f4805e in xslt_process .../contrib/xml2/xslt_proc.c:149
>     #2 0x640755a3ecbf in ExecInterpExpr .../src/backend/executor/execExprInterp.c:1001
>     #3 0x640755a277aa in ExecInterpExprStillValid .../src/backend/executor/execExprInterp.c:2299
>     #4 0x640755ef11e0 in ExecEvalExprSwitchContext ../../../../src/include/executor/executor.h:444
>     #5 0x640755efd7b6 in evaluate_expr .../src/backend/optimizer/util/clauses.c:5724
> 
> for a build made with -fsanitize=undefined.

Indeed, I can reproduce it locally.  This one is a super old
inconsistency, from what I can see.  This predates the introduction to
xml2 in contrib and even the use of cstring_to_text_with_len().  We've
never thought that xsltSaveResultToString() could return a NULL
xmlChar with a valid status code and a length of 0.  Back in the
day, before cstring_to_text_with_len(), that would be a memcpy with a
NULL pointer.

I am not sure if this is worth backpatching, so let's just use
something like the attached on HEAD.  This result cannot be NULL,
historically it has always been an empty string.

Opinions?
--
Michael