New EnumPrinterDataEx

[Dmitry Timoshkov]

"Ian Pilcher" <pilcher at 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.