Re: [xml] xmlDocDump crashing on windows

[Igor Zlatkovic <igor zlatkovic com>]

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
> all.

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:
>
> XMLPUBFUN FILE * XMLCALL xmlStdIn(void);
> XMLPUBFUN FILE * XMLCALL xmlStdOut(void);
> XMLPUBFUN FILE * XMLCALL xmlStdErr(void);
>
> 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

  xmlFreeDoc(xmlNewDoc("1.0"));

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.

Ciao,
Igor