The default bug view has changed. See this FAQ.

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.