[pulseaudio-discuss] Is it OK for PulseAudio to crash when BlueZ is buggy?

[Tanu Kaskinen]

Hi,

While writing code, I've used a rule that if a library that we use is
buggy (acts against its documentation), it's OK to crash in an
assertion. For example, I've used a lot of assertions on libdbus calls
that, according to the documentation, can fail only if there's not
enough memory. Since PulseAudio handles OOM by aborting, it's OK to
abort also when those libdbus calls fail. If they fail for some other
reason than OOM, that's then against the documentation, and the correct
course for action is to fix the bug in libdbus (or its documentation),
not to work around the problem by adding recovery code in PulseAudio.

I've also used a rule that buggy D-Bus services (and sound card drivers)
that PulseAudio relies on shouldn't be able to crash PulseAudio, unlike
buggy libraries. I can't really explain to myself why I've made that
distinction between libraries and D-Bus services. I think it should be
OK to assume that D-Bus services are working as documented, and when
there are problems with that, fix the bug where it is.

Opinions?

-- 
Tanu