Various MSVC x64 compiler size_t warnings (C4267) about snappy HOT 6 CLOSED

I can confirm this. (MSVC 9.0 SP1, x64)

Forgot to add: Happens with Snappy 1.1.0

I've looked a bit of these.

Note that in general, Snappy is not meant to support compressing blocks of 
64-bit size, so in itself, this is not a very high-priority goal.

We have a few classes of these warnings: One is the kind where we knowingly 
narrow the size_t into something much smaller. See e.g. this example from 
EmitCopyLessThan64, with len_minus_4 and offset being size_t, and op being 
char*:

  *op++ = COPY_1_BYTE_OFFSET + ((len_minus_4) << 2) + ((offset >> 8) << 5);
  *op++ = offset & 0xff;

We already have ample asserts here, so there's no bug that the warning 
uncovers. To fix it, we could have to do something like

  *op++ = static_cast<uint8>(COPY_1_BYTE_OFFSET + ((len_minus_4) << 2) + ((offset >> 8) << 5));
  *op++ = static_cast<uint8>(offset & 0xff);

except we'd need to break the line:

  *op++ = static_cast<uint8>(COPY_1_BYTE_OFFSET + ((len_minus_4) << 2) +
                             ((offset >> 8) << 5));
  *op++ = static_cast<uint8>(offset & 0xff);

I think this reduces readability enough that it's a clear negative.

Another, more interesting class is in cases like this:

  static inline void IncrementalCopyFastPath(const char* src, char* op, int len) {

where IncrementalCopyFastPath is called with a size_t argument for len. Also, 
we repeatedly do things like:

    len -= op - src;

We can't have len be size_t since we need to be able to check for it being 
negative; however, it could reasonably be ssize_t. As an added bonus, it would 
then seem we can avoid a signed 32-to-64-bit conversion on a hot path, which 
wins us something like 2% in decompression. It looks like this varies a bit 
between GCC versions, though; it's easy to get unlucky with what's presumably a 
good change.

Unfortunately, just changing everything blindly to ssize_t where it used to be 
int doesn't really help; seemingly, the cases here have to be implemented and 
benchmarked on a case-by-case basis, since some of them appears to hurt 
performance (for whatever reason).

So, in short, while some of these are interesting, I don't think we can fix all 
of them without unduly hurting readability and/or speed, so in that case, I'd 
say you should simply disable the warning in Chromium.

Comments?

Yep, we've already disabled the warning in Chromium. Thanks for taking a look.

r77 is relevant for this bug.

I'll leave it open until I get to look if the other cases have performance 
impact, just so I have a tracker on that. After that, I'll close it, since 
we're not going to be fixing all of them.

Found no further ones. Closing as mentioned.