Hello again Nikolay and others,
I'm back online. The first attachment is try 2 of the second patch, i.e. the one discussed in this thread. I hope it meets all of your concerns. I adjusted my plan slightly at this point:
Den 12-06-2012 13:55, Ulrik Dickow skrev:
Den 12-06-2012 13:21, Nikolay Sivov skrev:
On 6/12/2012 11:55, Ulrik Dickow wrote:
Patch 2 of 2 from http://bugs.winehq.org/show_bug.cgi?id=26226 . [...]
- /* Emit appropriate fixme or warning in case of unsupported or invalid namespace.
[...]
The question is more like what libxml2 thinks about that. If it follows w3c here which is likely the question will be - won't it break somewhere internally in libxml2 code if we hack it that way?
[...] But maybe you are right that it is safer to return E_INVALIDARG, as I did in an earlier version, to guard against future increased intelligence in libxml2. Both of the applications in bug 26226 use the correct W3C namespace, so they don't care. I'll change it back.
The new patch returns E_NOTIMPL instead. That seems more appropriate to me, knowing that native msxml3 returns S_OK (like the first version of my patch) and that we will have to change it back if it turns out to break a real-life application. Evil apps that try to break us intentionally don't count :).
The new patch gives exactly the same output for the tst-msxml_make_soap.c program as the old one. Consistent with this test, it also still succesfully fixes bug 26226 for BridgeCentral: BridgeCentral's SOAP requests again succeed perfectly.
The new patch changes the output of the tst-msxml_xmlns_simple.c program. The new E_NOTIMPL behaviour actually made the original program crash because I failed to do proper error checking (see second attachment if you like, patch relative to the C attached to bugzilla).
The new output of the fixed tst-msxml_xmlns_simple.c is in the third attachment. The differences to the old wine patch are in test 03 (only the FIXME text changed) and in test 04 (FAILures instead of ok, and now quite detailed FIXME texts instead of more general, invisible warnings).
Of course, only the first attachment will be sent to wine-patches, and only if no objections appear here to prevent it.
- Ulrik