New EnumPrinterDataEx

[Ian Pilcher]

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.

-- 
========================================================================
Ian Pilcher                                       pilcher at concentric.net
========================================================================