pilcher at concentric.net
Mon Feb 12 23:43:17 CST 2001
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*
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
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
Now consider what happens when I turn around and use EnumPrinterDataEx
in the PostScript driver. It would be completely inappropriate for me
write code that relies on this undocumented behavior, even though I
The point is that there has to be a "contract". Without it, we don't
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
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.
Ian Pilcher pilcher at concentric.net
More information about the wine-devel