1296577 - Give nscoord_MAX a better definition to avoid potential integer overflowing

Status: RESOLVED DUPLICATE of bug 1383492

(Core :: Layout, defect, P3)

Description

[Jeremy Chen ([e-mail])]

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 1

[Jeremy Chen ([e-mail])]

Attachment: Bug 1296577 - redefine nscoord_MAX to avoid potential integer overflowing.

Review commit: https://reviewboard.mozilla.org/r/73090/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/73090/

Comment 2

[Jeremy Chen ([e-mail])]

Comment on attachment 8783153 [details]
Bug 1296577 - redefine nscoord_MAX to avoid potential integer overflowing.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/73090/diff/1-2/

Comment 3

[Jeremy Chen ([e-mail])]

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 4

[Jeremy Chen ([e-mail])]

Comment on attachment 8783153 [details]
Bug 1296577 - redefine nscoord_MAX to avoid potential integer overflowing.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/73090/diff/2-3/

Comment 5

[Hiroyuki Ikezoe (:hiro)]

The value has been change in bug 1383492. Is it enough for you, Jeremy?

Comment 6

[Jeremy Chen ([e-mail])]

Yes, thanks for the info. Let's resolve this. \o/