[pulseaudio-discuss] asserts active by default

[Colin Guthrie]

Jan-Benedict Glaw wrote:
> But pulse behaves different here. A lot of circumstances where
> everybody and her turtle would just return an error, pulse will hit an
> assertion.

lol @ turtle :)

Yeah, perhaps less assertions would be better. But that said, it's very 
easy not to check a return value or implement sloppy error handling. 
It's impossible to ignore an assert. But if audio output is just part of 
your app and you can live without it, then having the whole app brought 
down by this is a bit annoying I agree.

> Right, because error handling and assertions were mixed up. Error
> handling is for errors that could expectedly happen (eg. malloc()
> returns a NULL pointer, user requests an operation that's invalid in
> this context, ...)

So when malloc fails, you should be able to recover? I would have 
thought that if malloc fails you're pretty much screwed, no?

I mean if you cannot allocate memory then how are you going to compile a 
string to display to the user what's wrong? (Unless you keep a 
pre-malloced error buffer around I guess).


> Assertions should be put on conditions that a user should *never* be
> able to provoke in *any* circumstance

Is this a hard and fast "rule" of assertions in programming or an 
opinion? Just curious :)

>> I'm not really sure of the value in disabling asserts. If they are being 
>> hit, then this just means there are bugs to be fixed!
> 
> It'll provoke undefined behaviour due to now missing error handling.

I didn't mean disabling the asserts in pulse as it stands, I meant why 
disable them at all? What does it actually gain? But I appreciate why 
this could be useful now.

> I'm quite a happy pulse user, but I found out about this long ago.
> ISTR that I even wrote an email at that time, but I'm not sure. I also
> seem to remember that Lennart considered audio output unimportant
> enough to simply let it run into an assertion instead of clobbering
> the code with overly complete error handling.
> 
> But I may be wrong here, too :)

Well if that's true (I'm sure Lennart will issue a correction if it's 
not ;)), then this doesn't really hold water. As libcanberra is used in 
*all* GTK apps and it can, in theory, hit an assert via it's pulseaudio 
output then it has the power to take down any application, not just 
"playing audio".

I can certainly see the argument that if an assert is hit as a result of 
something in libcanberra then there is no reason at all to crash the 
whole app.

I await Lennart's reply on this topic with interest :)


Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
   Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
   Mandriva Linux Contributor [http://www.mandriva.com/]
   PulseAudio Hacker [http://www.pulseaudio.org/]
   Trac Hacker [http://trac.edgewall.org/]