[Gllug] C/C++ mentor

[Daniel P. Berrange]

On Sun, Nov 26, 2006 at 09:09:32PM +0000, Nix wrote:
> On 24 Nov 2006, Daniel P. Berrange told this:
> 
> > On Thu, Nov 23, 2006 at 11:02:11PM +0000, Nix wrote:
> >> So what's your opinion of libdbus-1.0.0+'s charming `check failed? we
> >> SIGABRT you' failure mode? If it stays it seems very unlikely that D-Bus
> >> will be used by many important services: keeping those services running
> >> is often far more important than sending notification messages out.
> >
> > Well, its a tricky / interesting problem. These assertions are identifying
> > real programming flaws, so while I certainly do want key system services
> > to run reliably, I equally don't want these flaws being allowed through
> > to potentially become security exploits. These checks are usually only
> > enabled when dbus is built with assertion checking enabled - in production
> > release builds 95% of them disappear to be no-ops.
> 
> ... except that the docs recommend you *always* build with --enable-checks.
> Daniel Stone and others have pointed out that this appears to be honoured
> mostly in the breach...

Which docs recommend it ? The README file merely documents the presense of
the --enable-checks option, but doesn't recommend it one way or  the
other. The INSTALL doc is just the generic autoconf doc. Whenever someone
has asked on the mailing lists / IRC channel its always been pretty clear
that its not recommended except for core DBus/binding developers.

> > There was one particularly annoying check though that seems to have
> > caused a hell of alot of pain. The API contract of one method was
> > changed shortly before the 1.0 release. In doing so an assertion check
> > was added to easily detect apps relying on the old semantics. In
> > retrospect though, this was probably a mistake because its caused a
> > lot of unneccessary & very user visible pain during this transition
> > phrase where apps adapt to new API semantics.
> 
> Doing it at a point where app developers could reasonably have assumed
> that things are stable was not terribly nice either.

Yeah, that sucked.

> > Finally it is worth noting that it really isn't intended for application
> > developers to be using the core libdbus.so directly in most cases. It
> > was expected that in the general case people would use the higher 
> > level language bindings, eg python, glib, qt, perl, java, etc. These
> > bindings mask most of the low-level messaging APIs, providing a high
> > level API more easily used by app developers. In doing so, these high
> > level APIs would protect apps from the possibility of violating any of 
> > the assertion checks.
> 
> But if by chance your binding is buggy, oops, SIGABRT and you're dead.
> A bit tough on the app if sending bus messages isn't its sole reason
> for existence.

That's why the checks are only supposed to be enabled in developer
builds, not production builds going into distros. Guess that message 
hasn't been getting across as clearly as it should have to people 
packaging up DBus for the distros :-(

Regards,
Dan.
-- 
|=-            GPG key: http://www.berrange.com/~dan/gpgkey.txt       -=|
|=-       Perl modules: http://search.cpan.org/~danberr/              -=|
|=-           Projects: http://freshmeat.net/~danielpb/               -=|
|=-   berrange at redhat.com  -  Daniel Berrange  -  dan at berrange.com    -=|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: Digital signature
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20061127/53a44660/attachment.pgp>
-------------- next part --------------
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug