Issue 99711 - stoc: unused code and bogus code
Summary: stoc: unused code and bogus code
Status: CLOSED FIXED
Alias: None
Product: udk
Classification: Code
Component: code (show other issues)
Version: DEV300m42
Hardware: All Linux, all
: P3 Trivial (vote)
Target Milestone: OOo 3.2
Assignee: Stephan Bergmann
QA Contact: issues@udk
URL:
Keywords:
: 103769 (view as issue list)
Depends on:
Blocks:
 
Reported: 2009-02-27 10:44 UTC by caolanm
Modified: 2009-07-24 10:53 UTC (History)
1 user (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
option 1 (3.06 KB, patch)
2009-02-27 10:45 UTC, caolanm
no flags Details | Diff
option 2 (3.02 KB, patch)
2009-02-27 10:45 UTC, caolanm
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description caolanm 2009-02-27 10:44:44 UTC
in stoc/source/servicemanager/invocation.cxx we have some weirdness.

a) pItems = new MemberItem[nTotalCount] with no matching delete[]
b) ppItems = new MemberItems*[nTotalCount] with no matching delete[]
c) the address of each item in pItems is assigned to a position in ppItems
   and then we sort "ppItems", so we have a nicely ordered set of pointers in
ppItems. And then we traverse "pItems" in order, which of course remains in the
original order. The intent may have been to either sort "pItems" or to traverse
"ppItems" in order.

Attached is option1 and option2. 
option1 removes ppItems and adds delete[] pItems and removes the useless sort,
so current behaviour continues. Probably the preferred option, as what we're
doing now presumably has been what we've been doing for a decade or so, so why
change it.
option2 removes ppItems and adds delete[] pItems and changes the sort to sort
pItems which might have been the original intent
Comment 1 caolanm 2009-02-27 10:45:00 UTC
Created attachment 60543 [details]
option 1
Comment 2 caolanm 2009-02-27 10:45:13 UTC
Created attachment 60544 [details]
option 2
Comment 3 kay.ramme 2009-03-09 10:56:37 UTC
Stephan, please have a look ...
Comment 4 Stephan Bergmann 2009-03-09 11:50:51 UTC
.
Comment 5 Stephan Bergmann 2009-04-20 12:44:57 UTC
applied attached stoc.option1.patch (with slight modifications) as
cws/sb109/stoc/source/invocation/invocation.cxx@270978 and
cws/sb109/stoc/source/servicemanager/servicemanager.cxx@270978; generating
sorted data (option 2) appears to be unnecessary
Comment 6 Stephan Bergmann 2009-04-20 13:02:35 UTC
.
Comment 7 Stephan Bergmann 2009-04-27 10:11:41 UTC
.
Comment 8 caolanm 2009-05-16 14:51:56 UTC
stoc went to 0 in m47,
http://people.redhat.com/caolanm/callcatcher/DEV300_m47/
closing
Comment 9 Stephan Bergmann 2009-07-24 10:53:10 UTC
*** Issue 103769 has been marked as a duplicate of this issue. ***