kaliveda-dev team mailing list archive

[John Frankland <504779@xxxxxxxxxxxxxxxxxx>]

** Changed in: kaliveda/1.8
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of KaliVeda
Development Team, which is subscribed to KaliVeda.
https://bugs.launchpad.net/bugs/504779

Title:
  bit conflict in KVSeqCollection/KVList: kIsOwner and kSignals both
  address BIT(14)

Status in KaliVeda data analysis framework:
  Fix Released
Status in KaliVeda 1.7 series:
  Fix Released
Status in KaliVeda 1.8 series:
  Fix Released

Bug description:
  in versions <= 1.7.4b: KVList::kSignals bit flag for sending Modified() signals is the same as TCollection::kIsOwner bit flag (BIT(14))
  in trunk: KVSeqCollection::kSignals bit flag for sending Modified() signals is the same as TCollection::kIsOwner bit flag (BIT(14))

  resulting conflict means that for <=1.7.4b, creating a KVList using the default constructor KVList(Bool_t owner=kTRUE)
  is not sufficient to ensure that list owns its objects, as in this constructor we do:
  SetOwner(owner);
  ResetBit(kSignals);// <=== same as SetOwner(kFALSE) !!!
  if one subsequently calls SendModifiedSignals() or SetOwner() then BOTH signals and ownership are activated
  (with potentially catastrophic results)

  in trunk version, ResetBit(kSignals) is called in KVSeqCollection ctor before SetOwner(owner) is called in KVList ctor,
  so KVList DOES own its objects... and sends signals as well. The same conflict between SendModifiedSignals() and SetOwner()
  exists.