"Ian Pilcher" pilcher@concentric.net wrote:
- I do not really know that the parameters I am passing are valid. OK, I'm pretty darn sure in this case, but I guarantee that the day I make that assumption will be the day I pass the wrong variable or make some similarly stupid mistake.
You *really know* that the parameters you pass are valid, because you did check the value of the call that did return that value. Isn't it?
- My understanding is that the goal of the Wine project is to reverse engineer the Win32 API.
Not really. Reverse engineering is not legal in some countries. The Wine project does *implementation* of the Win32 API.
If this is true, the Win32 API documen- tation is the "contract" between the author of a function (such as HeapFree) and the caller of that function.
Available Win32 API documentation is not more than "the feed for the thought". All behind that is achieved via writing test apps and some other things: learning traces, debugging and (sometimes) disassembling (sort of).
Since the documentation does not mention the circumstances under which the call will fail, assuming that it doesn't fail is relying on an undocumented behavior.
Since *any* API call theoretically could fail, are you going to check all the returned values? Some reasonable approach could save a lot of time and lines of code.
(Even if I examine the source code of the Wine functions that I call and ensure that the current implementations cannot fail when I call them, there is no guarantee that this behavior will not change in the future.)
- Consider the actual impact of this check. In each case it's a comparison of a 32-bit return value (presumably a register on all platforms) to 0. Assuming a successful call to the ASCII version of this function, this is a total of six comparisons to 0. If Wine is compiled with warnings disabled, the compiler should optimize out the comparisons entirely.
Even if the call to HeapFree or RegCloseKey was failed, what can we do? Nothing.