RE: [xml] xmlDocDump crashing on windows

[Murray Cumming Comneon com]

I think it is in principle impossible/inadvisable/bad to use both versions
of the Windows runtime libraries anywhere in your libraries and application.
That's why there are often 4 versions of every Windows library. 2
(debug/release) * 2 (the 2 runtimes) = 4.

Murray Cumming
www.murrayc.com
murrayc usa net

> -----Original Message-----
> From: xml-admin gnome org [mailto:xml-admin gnome org] On 
> Behalf Of Igor Zlatkovic
> Sent: Donnerstag, 27. November 2003 15:56
> 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>
>
> 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.
>
> Ciao,
> Igor
>
> _______________________________________________
> xml mailing list, project page  http://xmlsoft.org/ 
> xml gnome org http://mail.gnome.org/mailman/listinfo/xml