Bug 138842 – Have Vector::capacity() return an unsigned instead of a size_t

• Component: Web Template Framework
• Status: RESOLVED FIXED

[Chris Dumez]

Have Vector::capacity() return an unsigned instead of a size_t as capacity is stored as an unsigned internally.

[Chris Dumez]

Created attachment 241807 [details]
Patch

[Andreas Kling]

Comment on attachment 241807 [details]
Patch

r=me

[WebKit Commit Bot]

Comment on attachment 241807 [details]
Patch

Clearing flags on attachment: 241807

Committed r176293: <http://trac.webkit.org/changeset/176293>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Alexey Proskuryakov]

Just as commented in another bug, this seems like the wrong direction to me. 4Gb is not enough for everyone, why bring more of WebKit back to Stone Age.

[Chris Dumez]

(In reply to comment #5)
> Just as commented in another bug, this seems like the wrong direction to me.
> 4Gb is not enough for everyone, why bring more of WebKit back to Stone Age.

Sorry about that. I wasn't aware this was controversial. I was annoyed by the fact that Vector uses unsigned types internally but its API still uses size_t.

[Andreas Kling]

(In reply to comment #5)
> Just as commented in another bug, this seems like the wrong direction to me.
> 4Gb is not enough for everyone, why bring more of WebKit back to Stone Age.

The majority of Vector's clients will never need to store 4GiB or more.

It seems better to build something special-purpose if/when we do need dynamic arrays with that much capacity.

Also, making Vector strictly "unsigned" unifies the behavior between 32-bit and 64-bit platforms.

[Geoffrey Garen]

If we are going to limit Vector to 4GB, can we at least add a RELEASE_ASSERT upon grow that says we're not going to overflow the 4GB limit?

[Antti Koivisto]

Perhaps the constructor and the functions that expand size should still take size_t so we can crash on overflows?