[pulseaudio-discuss] asserts active by default
gmane at colin.guthr.ie
Tue Sep 2 08:23:32 PDT 2008
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
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
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
I await Lennart's reply on this topic with interest :)
Tribalogic Limited [http://www.tribalogic.net/]
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
More information about the pulseaudio-discuss