Hi,
We saw some test failures running the python tests for libxml-2.7.8 that
turned out to be related to libc's vsnprintf being buggy.
Unfortunately, though vsnprintf(buf,len,format,ap) should return the number
of chars that would have been written to buf (not including the final
NULL), not all systems see it that way.
For example, with a string that ends up being 7 chars long we get these
return values for different values of 'len':
OS \ len 4 1 0
+---------+-------+-----+-----+-----+
|Solaris 6-9 | 7 | 7 | -1 |
|Solaris 10 | 7 | 7 | 7 |
|HPUX 10.20-11.23 | -1 | -1 | 7 |
|HPUX 11.31 | -1 | -1 | 0 |
|AIX 5.1 | 7 | 7 | 0 |
|AIX 5.2-7.1 | 7 | 7 | 7 |
|Tru64 5.1 | 3 | 0 | 0 |
|SGI IRIX 6.5 | 3 | 0 | -1 |
|Linux/Glibc | 7 | 7 | 7 |
+-----------------+-----+-----+-----+
On Tru64 and IRIX vsnprintf returns the # of chars it actually copied,
on HP-UX it usually just returns -1 if len isn't long enough. To make
matters worse, if buf is NULL, it causes sigsegv or sigbus on HP-UX <
11.31, AIX 5.1 and Tru64.
While it is possible to check in configure how the system's stdio
implementation is broken, it seems easier to use libxml's included trio.
Trio's vsnprintf doesn't like NULL buffers either, so we avoid doing
that.
Hack attached
Peter
--
Peter O'Gorman
pogma thewrittenword com
Attachment:
vsnprintf.patch
Description: Text document