Re: [xml] xmlDocDump crashing on windows

Eric Zurcher csiro au wrote:
<Igor changed the subject line to fit the thread>

Thanks, Igor. Maybe someday I'll learn to pay a bit more attention...

Hee hee :-)

Sorry, but I don't entirely understand your comments. The libxml2 API/ABI
already provides a set of memory management functions: xmlFree, xmlMalloc,
xmlRealloc, and xmlMemStrdup. I'm not suggesting any changes to these at

Well, my comment was that these are not functions. They are preprocessor macros. I was talking about memory functions while you focused on stdin, stdout and that gang. I went a bit off track with that, see below for why.

My reference to the memory functions was just an analogy. What I'm proposing
is that, just as libxml2 provides the memory functions, it might also be
useful to have exported functions (or perhaps just variables) for access to
the basic file streams - specifically:


It would also be useful to have:

XMLPUBFUN FILE * XMLCALL xmlFOpen(const char* filename, const char* mode);
XMLPUBFUN int XMLCALL xmlFClose(FILE* stream);

The implementation within libxml2 could be trivial, e.g.:

XMLPUBFUN FILE * XMLCALL xmlStdIn(void) { return stdin; }
What would be the point of this? It means that an application would be able
to make a call like:

 xmlDocDump(xmlStdOut(), doc);

instead of:

 xmlDocDump(stdout, doc);

which would still work even when the application and DLL are using totally
different runtimes. My application (perhaps compiled with BCB) would be
telling xmlDocDump to write to the stdout of the DLL (perhaps compiled with
MSVC), not the stdout of my application.
The main hazard I see is that the returned FILE pointers might not actually
be the sort of FILE pointers that the application would "think" they are.

That would not be a problem. One pointer is like the other, as long as you don't try to dereference it.

Implementing what you suggest above is easy and wouldn't break anything. It would perhaps fix the issues with stdin/stdout. but the basic problem, means crashing, would still remain. And that precisely because of the malloc/free which you wouldn't change. As I posted few days ago, doing a


will crash the app if the app and libxml use different runtimes because memory functions are incompatible. Fixing these the way you fixed stdin would break the ABI. This is where I left the stdin topic and talked about memory functions.

See, I can well imagine a full-scaled app which doesn't need or use stdout, but not even the hello world atop libxml can avoid the use of memory functions. This is why I gave them more weight. What you named just an analogy was the main showstopper in my previous post.

We could do what you suggested and in addition have the users call xmlMemSetup(), always, before they do anything else. That should redirect all memory operations to functions from the app's runtime. Sounds fine, but...

One thing is sure: The users won't call xmlMemSetup, no matter how often you write it in the docs and will still fill bug reports about crashing. At least for me, the only reason to mess with support for multiple runtimes is precisely to avoid those bug reports. And to be honest, if we implement what you suggest, most users will still use stdout and complain when the app crashes, before they find out that there exists xmlStdOut which should be used instead.

When you require an action from the users, you can place a secure bet on that the majority won't take it, but will complain about misfunctional libxml instead. Therefore, I think a good solution would be the one which libxml can handle by itself, without the user's intervention. If I knew of one for this particular problem, I would have implemented it long ago.

Well, as it is, the developers will get the flames anyway, so they can as well choose a solution which is more convenient for them. The most convenient for me was to force msvcrt on everything that runs in the same address space with libxml. I choose this way because I saw just disadvantages with other runtimes and noone proved that wrong.

I can live very well with your xmlStdOut and the sort. For the reasons outlined above, I would suggest a thing: We can do it, if you need it, if you will benefit from it. We should not do it for the hope to save the users from the runtime issues. It won't help them, it will just give them more ground for confusion.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]