If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Give nscoord_MAX a better definition to avoid potential integer overflowing

RESOLVED DUPLICATE of bug 1383492

Status

()

Core
Layout
P3
normal
RESOLVED DUPLICATE of bug 1383492
a year ago
11 days ago

People

(Reporter: jeremychen, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment)

In our code base, we use nscoord_MAX to clamp some huge integers. I'm wondering how did this definition [1] come out? Why it is not (1 << 31 - 1)?

If this is for avoiding integer overflows while adding two integers, would it be better to define nscoord_MAX to be (1 << 30 - 1)? Since (1 << 30) + (1 << 30) would still overflow.


[1] http://searchfox.org/mozilla-central/rev/ae78ab94fadabc89fc6258d03c4a1a70f763f43a/gfx/src/nsCoord.h#49
Comment hidden (mozreview-request)
See Also: → bug 265084
Comment hidden (mozreview-request)
Hmm... looks like we set nscoord_MAX to (1 << 30) for applying a runtime rounding algorithm on XP_WIN32 platform [1].

[1] http://searchfox.org/mozilla-central/rev/f433f0dd7158d7bfc4c4607161fc6baa88b5a9f4/xpcom/ds/nsMathUtils.h#41
Comment hidden (mozreview-request)

Updated

2 months ago
Priority: -- → P3
The value has been change in bug 1383492. Is it enough for you, Jeremy?
Flags: needinfo?(jeremychen)
Yes, thanks for the info. Let's resolve this. \o/
Status: NEW → RESOLVED
Last Resolved: 11 days ago
Flags: needinfo?(jeremychen)
Resolution: --- → DUPLICATE
Duplicate of bug: 1383492
You need to log in before you can comment on or make changes to this bug.