LossyUTF8ToUTF16() in nsNSSCertHelper.cpp uselessly uses ToNewUnicode()

RESOLVED FIXED in Firefox 63

Status

()

RESOLVED FIXED
7 months ago
7 months ago

People

(Reporter: hsivonen, Assigned: hsivonen)

Tracking

unspecified
mozilla63
Points:
---

Firefox Tracking Flags

(firefox63 fixed)

Details

Attachments

(1 attachment)

(Assignee)

Description

7 months ago
LossyUTF8ToUTF16() in nsNSSCertHelper.cpp uses XPCOM string conversions in an awkward way. Instead of ToNewUnicode() + Adopt(), it should use strings in a regular non-Adopt() way.
(Assignee)

Comment 1

7 months ago
This does not change the outward behavior of LossyUTF8ToUTF16(). Both
ToNewUnicode() and CopyASCIItoUTF16() convert from Latin1 to UTF-16.

MozReview-Commit-ID: 8SDgvoGaN4A
(Assignee)

Comment 2

7 months ago
Aside: The original motivation in bug 1461037 was to avoid assertions when UTF-8 is bogus. Nowadays UTF-8 to UTF-16 conversion replaces errors with the REPLACEMENT CHARACTER instead of asserting.
Comment on attachment 9005109 [details]
Bug 1487310 - Let XPCOM strings manage their own buffer in LossyUTF8ToUTF16().

Dana Keeler [:keeler] (she/her) (use needinfo) has approved the revision.
Attachment #9005109 - Flags: review+

Comment 4

7 months ago
Pushed by hsivonen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c45b51ec248e
Let XPCOM strings manage their own buffer in LossyUTF8ToUTF16(). r=keeler

Comment 5

7 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/c45b51ec248e
Status: ASSIGNED → RESOLVED
Last Resolved: 7 months ago
status-firefox63: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
You need to log in before you can comment on or make changes to this bug.