2012-05-09 00:19, Tanu Kaskinen skrev: > 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? I tend to think about drawing the line at the process. Libraries can access process memory, if they are buggy, they can overwrite pointers inside pulseaudio, causing PulseAudio to crash and do other crazy stuff, and there is nothing we can do about that (except fixing the bug in the library). Things out of process context, such as data coming from badly behaving clients, should be correctly verified, and errors given back when they fail. If we draw the line there, things you access over dBus would then be out of process, and should then be properly verified. But as these error paths are seldom tested anyway, I guess it's okay to be a bit pragmatic about it - if you know that the particular dBus service is of good quality and has served you well for a longer period of time, I guess one could relax the restriction a bit and allow a few asserts here and there, at least for the most uncommon errors. For the Bluez dbus service, I think it's relatively new and under active development (or is it? correct me if I'm wrong here!), so it would not fall under this category of "relaxed checking" at all. // David
