Re: [xml] reproducible coredump libxml2-2.3.8, trio or libxml or both

[Bjorn Reese <breese mail1 stofanet dk>]

[ Apologies if this email appears twice. Due to problems with Adam Clarke's
  address, my first reply was rejected by my mailserver. In this second
  reply, I removed his address from the cc: list ]

Daniel Veillard wrote:

>    Well, clearly xmlGetVarStr() expect args to not have been changed in
> case of unsifficient lenght of the formatting buffer.

And unfortunately this is exactly the problem.

C99 (section 7.15.2) states that "The object ap [va_list argument] may
be passed as an argument to another function; if that function invokes
the va_arg macro with parameter ap, the value of ap in the calling
function is indeterminate and shall be passed to the va_end macro
prior to any futher reference to ap".

Furthermore, C99 description of vsnprintf (section 7.19.6.12) says that
"The vnsprintf function does not invoke the va_end macro", followed by
a footnote that says "As [...] vnsprintf [...] invoke the va_arg macro,
the value of the arg[ument] after the return is indeterminate".

In summary, the use of vsnprintf in xmlGetVarStr is "too creative".
Making a workaround in trio does not help on the platforms where
trio_vsnprintf is not used.

>    I reread this function and it looks relatively clear. It will try to
> format the string, if the buffer is too small it will grow it up and
> call vsnprintf again, until this succeed.

The trio solution to this is trio_vasprintf, which allocates enough
memory to contain the output.

Alternatively, xmlGetVarStr could call va_end followed by va_start
every time it has to re-invoke vsnprintf (although C99 seems to allow
using a pointer instead, just like Stan's suggested workaround in
TrioFormat, this will not work on every platform in practice -- on
64-bit Alpha machines va_list is not a pointer).