GNOME Bugzilla – Bug 412787
snprintf is leaking into trio-enabled builds on DEC OSF/1 again
Last modified: 2007-08-23 19:14:04 UTC
Please describe the problem: The symptoms are that builds on platforms lacking snprintf() end up incorporating references to snprintf() into libxslt, leading to libxslt refusing to load. Trivial patch forthcoming (if I can figure out how to attach it...) Steps to reproduce: 1. Build libxslt on a platform lacking snprintf(). 2. make check or try to use libxslt in any way at all. Actual results: Undefined symbol. Expected results: Does this happen every time? Other information:
Created attachment 83491 [details] [review] Use trio.h in namespaces.c, which calls snprintf(); replace vsnprintf() in xsltutils.c only if the platform lacks it 2007-02-27 Nix <nix@esperi.org.uk> * libxslt/namespaces.c: Include trio.h and replace snprintf() if needed. * libxslt/xsltutils.c: Only replace vnsprintf() if needed.
I agree that namespaces.c should have an "#ifdef XSLT_NEEDS_TRIO" clause. However, reading the source of trio.h it looks to me as if the other parts of your proposed patch to namespaces.c (#if !defined(HAVE_SNPRINTF), etc.) are already present in trio.h. It also looks as if the "#define vsnprintf" in xsltutils.c should be deleted rather than adding a "#if !defined(vsnprintf)", for the same reason. Would you agree?
Yes, *iff* something-or-other is done to #define TRIO_REPLACE_STDIO in configure.in when snprintf/vsnprintf/some-other-function are missing (as without that none of the #defines in trio.h will kick in). But doing that is a little trickier: you'd have to be sure that configure.in tested for all the various stdio things that trio.h's #ifdefs check, or it'll end up replacing *them* as well. That was a little more than I wanted to do in this quick hack, but doing it is probably a good idea :)
Good point - I hadn't noticed that. OK, I've enhanced the configuration checking code (xsltconfig.h.in only - configure.in was already ok), and also modified xsltutils.c and namespaces.c as we agreed. The modified code is in SVN. I don't have any really good way to test it, so I'd appreciate it if you could try it and see if it seems ok. Thanks for the report.
I'll test it on the old DEC Alpha in question next week. (It's `protected' by a firewall that's so paranoid that it blocks svn and svn+ssh, and so buggy that it breaks svn's http transport, too, so I'll have to tar it up and carry it there by hand...)
No comment back but based on comment #4 I assume it's fixed in HEAD, or maybe the last OSF/1 box died due to its old age >;-> (and it's definitely not environment friendly to run those anymore!) Daniel
Oops, my apologies, I thought I'd followed up. Yes, it's fixed and works fine (and libxml is about ten thousand times faster than the monstrous Oracle Java libraries on this platform, and that's not an exaggeration: they're so slow that Oracle support are actually recommending that people use libxml and libxslt when performance is at all important. I think your code has, what's the phrase, pwned theirs :) )