[webkit-dev] Proposal about integer types used in WebKit

[Peter Kasting]

On Fri, Jul 24, 2009 at 12:46 PM, Darin Adler <darin at apple.com> wrote:

> Some of our code uses types like int32_t, uint32_t, int64_t, and uint64_t.
> I don’t see the point of doing this. I’d like to suggest that we always use
> int where we’d otherwise use int32_t except where there is some issue of
> integration with an underlying library.
>
> Am I missing something? Is there some real benefit to using types like
> int32_t instead of int in some places in our code and not others? If so,
> what are these critical places and what makes them different from the rest
> of the code?


Besides the issue of integration with an underlying library (for example,
ImageDecoder.h uses uint32_t in one place for Skia, because Skia itself uses
uint32_t there), there are three possibilities I can think of:

* Perhaps some places that use "long long" cause MSVC to barf, and
[u]int64_t may be a necessary typedef sometimes?

* int32_t self-documents that the fact that the type is 32 bits is
critically important to the code.  (Most places that use "int", e.g. in
simple loop indexes or for "small" values, may not particularly care about
its size.)  This is much more obvious than when "int" is used.

* What if we stop assuming LP64, or WebKit code gets borrowed for use by
other projects? Personally I'd prefer to allow coders to be explicit as this
increases portability of code between different environments.

Only the first of these is a serious issue, but honestly I don't see any
benefit to forbidding int32_t (as I assume it's currently only used in a few
places, most of which probably match #2 above).

PK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090724/4331788d/attachment.html>