Mailinglist Archive: zypp-devel (115 mails)

< Previous Next >
[zypp-devel] tribool ... (Fwd)
  • From: Martin Vidner <mvidner@xxxxxxx>
  • Date: Mon, 23 Jul 2007 17:25:57 +0200
  • Message-id: <20070723152557.GB21500@xxxxxxxxxxxxxxxx>
Michael is not subscribed, forwarding...

----- Forwarded message from Michael Meeks <michael.meeks@xxxxxxxxxx> -----
Subject: tribool ...
From: Michael Meeks <michael.meeks@xxxxxxxxxx>
To: zypp-devel@xxxxxxxxxxxx
Cc: Ricardo Cruz <rpmcruz@xxxxxxxxxxxxxxxxxxx>
Organization: Novell, Inc.
X-Mailer: Evolution 2.6.0 
Date: Mon, 23 Jul 2007 08:55:13 +0100

Hi guys,

        So - I learned something fun, interesting and new this morning (at the
cost of an hour or so) - it was the joys of the tribool:

        if (available_obj != NULL &&
            !available_obj->repository().info().enabled()) {

        In normal usage, by the power of sequence points, this sort of thing
works nicely (and indeed, it used to work before the API re-hash I
think).

        Unfortunately, with a tri-bool around this becomes a mess, sequence
points are no longer your friend:

    return false
        && !(zypp::ResObject::constPtr(NULL)->repository().info().enabled()) ? 1 : 0;

        SEGV's immediately - try it as a return from main() ;-) it compiles to:

    return tribool.operator&& (false, <segv'ing-code>)

        Now the fix is 'obvious' - simply split it into 2 if's, or add a
'(bool)' cast to what appears to be a bool anyway ;-) but it's pretty
sickeningly non-obvious to the casual user. Also, will it survive a
future maintainer's desire for cleaner code without "all these odd /
redundant casts in it" ?

        Urgh,

                Michael.

-- 
 michael.meeks@xxxxxxxxxx  <><, Pseudo Engineer, itinerant idiot
-- 
To unsubscribe, e-mail: zypp-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups