Dmitry Timoshkov wrote:
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?
In theory, yes. But what about the case of a mistake on my part (or the part of the person who implemented the underlying call)? We all do everything possible to produce error-free code, but mistakes *do* happen.
There could also be legitimate reasons for these calls to fail, even with valid inputs. I don't know that this is the case, but it might be entirely correct for HeapFree to fail if another thread has corrupted the process heap.
Not really. Reverse engineering is not legal in some countries. The Wine project does *implementation* of the Win32 API.
I don't think that this affects the validity of my arguments.
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).
I agree that this is true for the implementor of a specific API. In fact, I had to entirely rethink the ASCII implementation of EnumPrinterDataEx when I realized that Windows 2000 returned ASCII and Unicode strings in the same size buffers. Basically, I did extra work to match the undocumented behavior.
Now consider what happens when I turn around and use EnumPrinterDataEx in the PostScript driver. It would be completely inappropriate for me to write code that relies on this undocumented behavior, even though I implemented it.
The point is that there has to be a "contract". Without it, we don't have an API; we have a bunch of functions. If the Win32 documentation isn't our "contract", what is?
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.
Well . . . yes.
What kind of time are we saving? I think that the processor time consumed (only when Wine is compiled with warnings on) is entirely worth it if it helps catch a single error. Developer's time? I think it's far easier to check the value returned than to adequately research the exact circumstances under which each call might fail.
As far as lines of code, that's why I used the macros.
Even if the call to HeapFree or RegCloseKey was failed, what can we do? Nothing.
We can't gracefully recover, but I think it's entirely appropriate to issue a warning -- if that's what the user has requested through their compile/runtime options.
As this discussion goes on, please keep in mind that I'm not asking anyone else to adopt my views or style, no matter how good I think the reasons for them are.