Tuesday, March 7, 2006, 3:22:28 PM, Peter Beutner wrote:
H. Verbeet schrieb:
On 07/03/06, Ivan Gyurdiev ivg2@cornell.edu wrote:
This doesn't really make sense to me - the point of unspecified behavior if a parameter is NULL would be to speed up the function under contract with the caller. If you're already doing the check, why not handle it in some way other than crashing?
Because we *want* to crash and get a nice backtrace.
hm maybe I'm missing something but afaik you will get a backtrace right back into the application code, which will help you exactly nothing (unless you have the source code of the game and the binary doesn't have its debugging information stripped which is very likely not the case). So you have to figure out where you might have returned something wrong by looking at the traces from _before_ GetCreationParameters. The backtrace itself won't give you _any_ clues.
Unless some app relies on this crashing behaviour(which I doubt), I don't think wine should implement bugs just because MS does it. Seems a bit obscure strategy to me to crash in case of an error instead of proper error checking/reporting.
If anything Wine does crash in much more cases then native. Look at all the ntdll functions. Native never crash there (because all those are direct kernel calls). Wine on the other hand will crash whenever you have a bad pointer dereference.
So I don't see any reasons why we should check for NULL pointer here. It will still crash if pointer is bogus, but not NULL. Also having a crash in a debug trace helps to find the place where did it crash. If Wine just returns from this function, you never know where it will cause the real problem.
Vitaliy.