nsIVersionComparator is still broken in some circumstances

RESOLVED FIXED

Status

()

Core
XPCOM
P1
normal
RESOLVED FIXED
12 years ago
11 years ago

People

(Reporter: Nickolay_Ponomarev, Assigned: bsmedberg)

Tracking

({fixed1.8})

Trunk
x86
Windows XP
fixed1.8
Points:
---
Bug Flags:
blocking1.8rc1 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
The following code returns 1 instead of 0 for me.

Components.classes["@mozilla.org/xpcom/version-comparator;1"]
          .getService(Components.interfaces.nsIVersionComparator)
          .compare("0+", "1pre");

This happens because ParseVP() doesn't initialize numC and extraD if strB[0]=='+'. 

---
Also, either check the other two parts or document that you ignore them in case
if strB starts with '+' (in the nsIVersionComparator.idl). Currently the
documentation implies that the other two parts are evaluated even if strB is '+'.
(Reporter)

Comment 1

12 years ago
For some reason, on the second iteration of the loop in NS_CompareVersions numC
and extraD get nulled, and 1.0+ correctly compares as equal to 1.1pre, but I
think this may break on certain compilers. Asking for blocking1.8 for that reason.

Don't have a tree, so can't make a patch, sorry.
Flags: blocking1.8rc1?

Comment 2

12 years ago
benjamin, do you think this is a real problem that we should stop the 1.5
release for?
(Assignee)

Comment 3

12 years ago
Yeah, there seem to be cases where uninitialized memory can peek through.
Assignee: dougt → benjamin
Flags: blocking1.8rc1? → blocking1.8rc1+
(Assignee)

Comment 4

12 years ago
Created attachment 199828 [details] [diff] [review]
Always initialize versionparts, rev. 1

This initializes the versionparts up front, which is probably how I should have
done it in the first place.
Attachment #199828 - Flags: review?(darin)
(Assignee)

Updated

12 years ago
Priority: -- → P1

Updated

12 years ago
Attachment #199828 - Flags: review?(darin) → review+
(Assignee)

Comment 5

12 years ago
Fixed on trunk.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
(Assignee)

Updated

12 years ago
Attachment #199828 - Flags: approval1.8rc1?

Updated

12 years ago
Attachment #199828 - Flags: approval1.8rc1? → approval1.8rc1+
(Assignee)

Comment 6

12 years ago
Fixed on 1.8 branch.
Keywords: fixed1.8
You need to log in before you can comment on or make changes to this bug.