OwningStringOrUnsignedLong union value cannot be set if the type is not matched

RESOLVED FIXED in mozilla32

Status

()

defect
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: airpingu, Assigned: airpingu)

Tracking

Trunk
mozilla32
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Supposed we have something like:

  typedef (DOMString or unsigned long) DataStoreKey;

  dictionary DataStoreChangeEventInit : EventInit {
    DataStoreKey id = 0;
  };

When we do:

  DataStoreChangeEventInit eventInit;
  eventInit.mId = aId;

where |aId| is a String type.

This assignment will assert because the OwningStringOrUnsignedLong union value initialized by DataStoreChangeEventInit is always set to a UnsignedLong type by default. This will fail the later assignment when the type of value we want to assign is actually String.

A work-around is to call:

  eventInit.mId.~OwningStringOrUnsignedLong();

before the assignment.
See bug 958540.

>  eventInit.mId.~OwningStringOrUnsignedLong();

I would much prefer you used eventInit.mId.DestroyString() as the workaround, since that doesn't look like you're using an object after calling its destructor.....
Depends on: 958540
(In reply to Boris Zbarsky [:bz] from comment #1)
> See bug 958540.
> 
> >  eventInit.mId.~OwningStringOrUnsignedLong();
> 
> I would much prefer you used eventInit.mId.DestroyString() as the
> workaround, since that doesn't look like you're using an object after
> calling its destructor.....

Thanks for the input. :) I guess you're saying eventInit.mId.DestroyUnsignedLong()? because it's initialized as 0 in the WebIDL. If it's initialized as "", then we have to use eventInit.mId.DestroyString().

However, both DestroyString() and DestroyUnsignedLong() are private functions called by ~OwningStringOrUnsignedLong() which is public, so I'd still use ~OwningStringOrUnsignedLong() as work-around for now.
> However, both DestroyString() and DestroyUnsignedLong() are private functions

Ugh. Please add a nice comment before the destructor call referencing bug 958540?
Sure!
I just landed a fix for bug 958540, so this should work now, I would think.
Posted patch PatchSplinter Review
I apologize for not cleaning this up when landing bug 949325... These codes was supposed to be removed.
Assignee: nobody → gene.lian
Attachment #8415145 - Flags: review?(bzbarsky)
Comment on attachment 8415145 [details] [diff] [review]
Patch

r=so-many-minuses-it-must-be-good.  ;)
Attachment #8415145 - Flags: review?(bzbarsky) → review+
https://hg.mozilla.org/mozilla-central/rev/d811c553a165
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
You need to log in before you can comment on or make changes to this bug.