> > So it is an issue between teoretical correctness
> > vs practical easy of debugging. Since the debugging
> > problem can be solved by other means, it doesn't weight
> > very much compared to correctness IMHO.
>
> I disagree. We should try to catch problems as soon as possible, not
> hide them and hope the app will stumble along for a little while
> longer. Unfortunately Win 95 uses the latter approach so there are
> cases where we have to ignore bad inputs;
Note that there are three primary kind of bad inputs.
(1) Random values because of unitialized values
(2) NULL values because something earlier failed.
(3) NULL values because the developer didn't check
for it because he knew Windows would do it.
Note that (2) might be delibarate that something
earlier failed doesn't nessessarily imply the
Wine is buggy.
There might be application that do
BOOL Example(ARG1 arg1, ARG2 arg2) {
HANDLE handle = Foo(arg1, arg2);
return Bar(handle);
}
If Foo fails Bar will fail to and thus Example will fail...
This is not the fault of Wine. For and as the result Example
will fail on Windows to because of the value of the arguments.
> but we shouldn't do it unless there is a real app that depends on it.
The point is that you don't know if a real application depends on it
until you run it. When we release Wine 1.0 we will hopeful get a few
more companies that will consider running Wine. They try their
application under Wine (Wine, not WineLib) it crashes. They
don't know how to fix the problem and they don't bother sending
us a bug report. We have just lost a potential user of Wine.
That is why I wish to make every function behave like Windows
for NULL values.
> Feeding garbage to all
> the APIs and fixing them to ignore it is counterproductive at this
> point IMO.
NULL values are not garbage IHMO, there are legitime uses for depending
on NULL values returning failure because
1. Checking for NULL is a waste of time since the API already does it.
2. An explict check "pollutes" the code and is potentially less readable.
I can understand you concern but not fixing broken functions is not
the way to debug Wine IMHO.
Note that said that the debugging problem can be solved by other means.
We could for example do.
BOOL Foo(ARG1 arg1, ARG2 arg2)
{
if(!arg1) FAIL(FALSE);
/* ... */
}
Where FAIL is like
#ifdef SOMETHING
#define FAIL(value) do { DebugBreak(); return (value); } while(0);
#elif defined(SOMETHING_ELSE)
#define FAIL(value) do { if(OPTION_fail) DebugBreak(); return (value); }
while(0);
#else
#define FAIL(value) do { return (value); } while(0);
#endif
Then we could both have the cake and eat it. :-)
