[RFC] creating Wine's own 'assert' variant

[Lionel Ulmer]

Hi all,

Currently, Wine's code is full of 'asserts'. The problem I have with that if
that when such an assert is reached, only the thread being asserted is
aborted, but Wine is not 'shut down' properly. Moreover, if I want the
debugger to be launched on assert, I would need first to start the
application with the debugger and add a breakpoint on some libc internal
function.

So, don't you think it would be better to have our own 'wine_assert'
macro / function that could be configurable (ie abort or start the debugger)
and that would also shut-down Wine properly ?

Lionel

[Dimitrie O. Paun]

On October 26, 2002 08:48 am, Lionel Ulmer wrote:
> So, don't you think it would be better to have our own 'wine_assert'
> macro / function that could be configurable (ie abort or start the
> debugger) and that would also shut-down Wine properly ?

Did you forget the patch? ;)

I would suggest that we still call it 'assert', but somehow we get
the wine specific one from the headers (like wine/debug.h).

So we can break the patch in two steps:
  1. include <assert.h> in 'wine/debug.h', and
     get rid of all other '#include <assert.h>'
     from the tree
  2. implement our own version of assert() in
     wine/debug.h

[Lionel Ulmer]

On Sat, Oct 26, 2002 at 09:42:59AM -0400, Dimitrie O. Paun wrote:
> Did you forget the patch? ;)

Well, did not want to submit a patch changing 218 files and after receiving
a 'ah no, I do not like this idea' refusal mail :-)
> I would suggest that we still call it 'assert', but somehow we get
> the wine specific one from the headers (like wine/debug.h).

Yeah, it would limit the change to the 218 files to just removal of the
#include line (plus also maybe addition of 'wine/debug.h').

If nobody yells before monday, I will send a patch for your step 1. by then.
Then we will have to discuss exactly what features Wine's own assert should
have :-)

Lionel

[Eric Pouech]

> > I would suggest that we still call it 'assert', but somehow we get
> > the wine specific one from the headers (like wine/debug.h).
>
> Yeah, it would limit the change to the 218 files to just removal of the
> #include line (plus also maybe addition of 'wine/debug.h').
>
> If nobody yells before monday, I will send a patch for your step 1. by then.
> Then we will have to discuss exactly what features Wine's own assert should
> have :-)

just to help confusing users, defining our own assert.h would do too
(and it
would also work while porting program with winelib)

A+

[Alexandre Julliard]

"Dimitrie O. Paun"  writes:
> So we can break the patch in two steps:
> - include <assert.h> in 'wine/debug.h', and
> get rid of all other '#include <assert.h>'
> from the tree
> - implement our own version of assert() in
> wine/debug.h

A better approach would be to leave assert() alone, and raise an
exception on the SIGABRT signal.

[Dimitrie O. Paun]

On October 26, 2002 12:54 pm, Alexandre Julliard wrote:
> A better approach would be to leave assert() alone, and raise an
> exception on the SIGABRT signal.

Interesting, I didn't know abort() raised SIGABRT. That's cool,
and works better in general, particularly for winelib apps.