use assert etc. in Wine dlls? What is better?

Maarten Lankhorst m.b.lankhorst at gmail.com
Tue Mar 13 10:24:01 CDT 2012


Hey,

Op 13-03-12 15:05, Joerg-Cyril.Hoehle at t-systems.com schreef:
> Hi,
>
> Maarten's wine-pulse contains several instances of assert()
> I've been thinking about adding a bit of protection against
> inconcsistencies within mmdevapi code too.
>
> There are two variants that could be applicable depending on the situation:
> /* this should not happen, but if we detect it early, we can work-around the situation */
> if (a > limit) { ERR("%d > %d\n", a, limit); a = limit; }
> or
> assert(a <= limit, "whatever %d", a);
>
> I'm not too fond of assert.  An assert in DSound was one of my first bug
> fixes in Wine, years ago. It was not obvious why the app should not
> continue running -- perhaps without sound.
> OTOH, if an assert is violated, as a programmer, I'd like to hear about it.
>
> I found little on that topic in Wine. In 2002, Alexandre Julliard wrote:
> http://www.winehq.org/pipermail/wine-devel/2002-October/009766.html
The asserts I use are for internal consistency errors and shouldn't ever
trigger. If they do trigger something has seriously gone wrong. For
example This->pad <= This->bufsize_bytes should always hold true,
and for render in the write callback, This->pad <= oldpad should hold
true, since pulseaudio can only decrease padding. I don't even know
how  to recover from this, since applications will bug if padding
somehow increases since it's behavior that should never occur.
None of the asserts should ever be triggered by misbehaving
applications, unless there's a bug in pulseaudio.

~Maarten



More information about the wine-devel mailing list