RE: [xml] xmlDocDump crashing on windows

[Eric Zurcher csiro au]

> -----Original Message-----
> From: Igor Zlatkovic [mailto:igor zlatkovic com]
> Sent: Friday, 28 November 2003 1:56 AM
> To: Eric Zurcher csiro au
> Cc: xml gnome org
> Subject: Re: [xml] xmlDocDump crashing on windows
>
>
> <Igor changed the subject line to fit the thread>

Thanks, Igor. Maybe someday I'll learn to pay a bit more attention...
 
> Eric Zurcher csiro au wrote:
> > Enno,
> >
> > I guess I'm not surprised that you get a crash in this context. If I
> > understand things correctly, when the application and the libxml2 DLL
are
> > using different run-time libraries, they're each going to have their own
> > "stdout", with their own file-locking mechanism in the multi-threaded
case.
> > The DLL is going to have trouble accessing a "stdout" which is under the
> > control of the main application's run-time. 
> >
> > The situation is a bit like trying to use malloc in the main
application,
> > then passing the resulting pointer to a DLL and expecting it to be able
to
> > free it. It can work if the runtime is in common, but will fail
otherwise.
> > Perhaps it might be useful if libxml2 exported its version of the
standard
> > IO units (e.g, xmlStdIn, xmlStdOut, xmlStdErr), so that the application
> > could use them in API functions that
> > make use of a FILE* as an argument. I suppose there could even be an
> > xmlFOpen and xmlFClose.
> >
> > Does that make sense to anyone else, or am I way off base here?
>
> How would you declare these? With stdin and friends I guess it would be
okay 
> to have functions which return the desired file descriptor, but what about

> malloc/free?
>
> In a production version, memory functions are macros which resolve to 
> malloc/free. These will always be tied to the runtime of any module at 
> compilation time. The only solution for this is to remove macros and use 
> functions which have their implementation in libxml and do nothing else
but 
> delegating the call to malloc/free.
>
> For one, this would break the binary compatibility. For two, this would 
> introduce an additional function call per allocation. How much impact on
the 
> performance would that give? Note that this will propagate to everything 
> that uses libxml, ie libxslt, xmlsec, GNOME...
>
> In every case, people will eat our hearts if we break the ABI, unless we
go 
> to libxml3 and do it there. Also, if the performance degradation is more 
> than three nanoseconds, noone will want to have it.
>
> It certainly would make sense to isolate all the differences between the 
> underlying runtimes and handle them in one place, in a generic way, so
that 
> everyone can use what she pleases and never get a problem. I  just don't
see 
> a way to do it. Everything I can think of breaks the ABI.

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.

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. 


> Ciao,
> Igor

Cheers,

Eric Zurcher
CSIRO Livestock Industries
Canberra, Australia
Eric Zurcher csiro au