http://bugs.winehq.org/show_bug.cgi?id=17518
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |9916
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle@users.sourceforge.ne | |t
--- Comment #6 from Jörg Höhle hoehle@users.sourceforge.net 2010-05-28 16:10:01 --- Dan's patch became commit ea5a6f2db5e6f05acf38f9257278cbcad58ab898 There's no more crash.
Let's keep this bug open as a remainder that not all relevant places are patched.
1. TRACE(... "%s", debugstr_w(lpstrRet)) seems just as problematic. http://www.winehq.org/pipermail/wine-devel/2010-May/083747.html
2. MCI_HandleReturnValues is called even in case of error, which is at least inconsistent with Dan's commit (the buffer is left as Wchars, not 8bit). E.g. winmm logs of MCI_OPEN show that a MCI device id is placed in the buffer even when open fails.
Actually, we'd IMHO first need more than that one test formerly marked todo_wine to analyse if/how the supplied buffer ever gets modified in case of error (actually mciSendStringW sets *lpstrRet = '\0' -- quite late in the code, i.e. not always, bug #3?). The question is whether some apps can expect particular contents in some error situations (e.g. partially filled buffer with MCIERR_PARAM_OVERFLOW?).