> > > * some kind of automated regression testing, at least for
> > > non-graphical APIs (Alexandre Julliard)
> >
> > I have meantion earlier I'm working on a new project winapi_test
> > that does brute force testing of the API:s.
> >
> > What it does is that is generates a Windows (WineLib) application
> > that can be compiled and run under both Wine and Windows and
> > produces logs that can be compared and bugs fixed.
> >
> > Currently it only implements a NULL test where all functions
> > are called with all NULL arguments, but even this very simple
> > test have found a _lot_ of errors. I have already used it to
> > fix a few of them (already in the CVS).
> Umm, one question, though:
>
> I'm afraid that by adding all missing NULL pointer checks/SEH to the
> functions we'll actually *SLOW DOWN* Wine development.
Adding SEH:S is not, I believe, needed except in rare cases.
That said I do not intend to add any SEH in the first phase.
NULL pointer checks doesn't cost very much, but might make a
difference between an application working or not, so they are
more important.
> Suppose you got a NULL pointer.
> Then what will Wine do about that ?
The same as Windows does. If the function crashes on Windows,
it is often OK if it crashes with Wine. If it doesn't crash on Windows,
Wine really can't crash either since some application might rely
on that it doesn't crash and checks for a FALSE return values.
But note that crashing functions in general, regardless of what Windows
does, is not very good since applications might have a SEH that basicly
tell the user what you tried to do failed but I have recovered the
application internal data structures, so you can continue running.
However the application can't recover Wine's internal data structures
so it might cause crashes or deadlocks later if we don't recover.
Few application probably does this, but it is bad not to support it.
Just because Windows can't recover does nessarily mean that Wine
shouldn't be able to do it. Wine should IMHO be better than Windows.
Note that recovering doesn't nessarily mean that the function doesn't
crash it mean that even if it crashes, the integrity of Wine's
internal data is preservend, so the application might use a SEH
as a failure indication. In fact there might be some application
that relies on the fact that some functions crashes for certain
input values. Doing that is not very good programming IMHO,
but we might need to support that regardless.
Beside crashing might in some cases be a symtom of much worse problems,
so all function that does should IMHO be checked out and carefully
thought about whether crashing is acceptable or not, regardless of
whether Windows does or not.
> In the worst case it'll silently ignore/handle this error.
> And then you'll NEVER see a crash hinting you about the
> problem as you do now.
> That's one reason why I didn't pursue my stress testing.
> Not sure whether I'm right here, though...
Well there are two cases here
(1) The application really behaves this way and this
works on Windows.
(2) A previous API that failed cause directly or
indirectly a NULL value being passed.
The (1) case should obviously be fixed, case (2) is
more problematic of course. But the problem is that
one application might work if a function doesn't crash
and another might be harder to debug because it didn't
crash.
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.
> Same goes with the Win32 debug string functions.
> IMHO they are quite important.
I agree.
> But nonetheless they are completely silenced right now
> ("don't annoy the user").
Indeed, but some application might legally use NULL
values, and we don't want a lot of bogus bug reports.
Beside WARN is turned off by default, it is supposed
to be use it for these kind of problems, so please use it.
