On Wed, 2012-05-09 at 17:12 +0200, Dalleau, Frederic wrote: > > What triggered this was a question about what to do if BlueZ claims that > > there are two devices with the same address (that should never happen). > > I'd like to store the devices in a hashmap with the address as the key, > > so there are complications if there are multiple devices with the same > > address. Those complications can be avoided, if I do just: > > > > pa_assert_se(pa_hashmap_put(bluetooth_core->devices_by_address, device->address) >= 0); > > > > Why should I implement any more complex error handling? > > The error handling don't have to be necessarily complex (goto fail?). > And the use of an assertion creates the perception that PulseAudio has > crashed, whereas in this case (if it ever happened) the bug would not be > in pulse. > > Let's put the question another way : What is the benefit at not being > paranoid? The benefit is simpler code. It's clearly not a very popular idea to add assertions about D-Bus service behavior. I'll forget about it then. It shouldn't be a big burden to add the necessary message validation checks. If there is clearly invalid stuff in the messages, I'll just ignore the message and log an error: "The same address is assigned to multiple devices. This may be a bug in BlueZ. In any case, the Bluetooth functionality probably won't work very well." Also, I think I now finally understood David's point about libraries' ability to corrupt the process memory: incorrectly behaving libraries undermine the trust in all of the process memory in a way that buggy D-Bus services can't do. Therefore there's less reason with D-Bus services for just giving up and aborting if something unexpected happens. -- Tanu
