asserts in wine

[Reece Dunn]

Hi,

After seeing Gerald Pfeifer's patch, I decided to see how many asserts
were used in wine.

$ find . -type f -iname *.c -exec grep -H assert '{}' \; > assert1.log

This returns 2313 matching lines, some of which are including <assert.h>.

$ cat assert1.log | sed -e 's/:.*//' | sort | uniq -c | sort -n > assert2.log

This shows that there are 454 files that make use of assert, of which
166 files only reference assert once.

$ cat assert2.log | grep " 1 " | sed -e 's/ *1 //' | xargs grep -H
"#include <assert.h>" > assert3.log

This shows that 151 files pull in assert.h but don't reference it in
the c file, so could be removed.

NOTE: The results are out by a few files as some of the results just
have assert in a comment (such as dlls/wined3d/arb_program_shader.c).

-----

As a general principle, assert in:
  1/  tests should be changed to an ok and possibly a skip --
otherwise, the test results are reported as a crash, making it harder
to find out where the problem is.
  2/  dlls should be changed to a SetLastError or failure return code
(depending on the API) -- otherwise, the program triggering this will
be killed with no information as to what happened.
  3/  tools should print an error message indicating the problem
(failed to allocate memory, could not open file, ...) preferably with
as much information as possible (file does not exist, user does not
have privileges to open/write to file, ...) -- this is to make it
easier to see what the problem is and correct it.
  4/  server -- not sure here, but this should ideally return an error
code to the caller (APIs?) so it can be handled by that API/program.
  5/  programs should display an error to the user (e.g. MessageBox)
indicating the nature of the problem (file does not exist, ...) in a
way that is understandable by the user and (if possible) recover from
the error, or otherwise inform the user that the application cannot
recover (e.g. out of memory).

- Reece