Closed Bug 27343 Opened 25 years ago Closed 25 years ago

|NS_IF_ADDREF(expr)| evaluates |expr| multiple times even in non-logging builds

Categories

(Core :: XPCOM, defect, P2)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: scc-obsolete, Assigned: scc-obsolete)

Details

(Keywords: verifyme)

Attachments

(1 file)

This makes it innappropriate to do the efficient thing NS_IF_ADDREF(*result = mThing); because this makes the assignment happen multiple times. Additionally, you want |result| to only be dereferenced once which you can't get from *result = mThing; NS_IF_ADDREF(*result); So if the first form can be made to work, it is preferred. These efficiency considerations were pointed out by <jband@netscape.com>, though the form recommended in the first example above does not exactly match his desired coding style. The solution must work even if |mThing| in the example above is an |nsCOMPtr|. The solution should not, in my opinion, compromise the safety/conversion feature of |nsCOMPtr| that denies clients the ability to |AddRef()| them directly, e.g., nsCOMPtr<nsIThing> mThing; // ... NS_IF_ADDREF(mThing); // error: can't |AddRef()| an |nsCOMPtr| NS_IF_ADDREF(*result = mThing); // OK Note: |NS_ADDREF(expr)| already has the property that |expr| is only evaluated once in non-logging builds.
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: M15
Assuming this builds and tests OK then r=jband
Patch tested and checked in. Marking FIXED as of "nsISupportsUtils.h" 1.56. Note the small change to the template (omitting the |*| from |T*|) to improve the error message given when the macro is mistakenly applied to an |nsCOMPtr|.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Adding verifyme keyword.
Keywords: verifyme
- Per last comments, age of bug, and no reopen - Marking Verified/Fixed. Please reopen if still a problem.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: