Make SkSHA1 and SkM5 use common SkDigestHash result type

src/utils/SkMD5.h

 /*
  * Copyright 2012 Google Inc.
  *
  * Use of this source code is governed by a BSD-style license that can be
  * found in the LICENSE file.
  */
 
 #ifndef SkMD5_DEFINED
 #define SkMD5_DEFINED
 
+#include "SkEndian.h"
+#include "SkHashDigest.h"
+#include "SkStream.h"
 #include "SkTypes.h"
-#include "SkEndian.h"
-#include "SkStream.h"
 
 //The following macros can be defined to affect the MD5 code generated.
 //SK_MD5_CLEAR_DATA causes all intermediate state to be overwritten with 0's.
 //SK_CPU_LENDIAN allows 32 bit <=> 8 bit conversions without copies (if alligned).
 //SK_CPU_FAST_UNALIGNED_ACCESS allows 32 bit <=> 8 bit conversions without copies if SK_CPU_LENDIAN.
 
 class SkMD5 : SkWStream {
 public:
     SkMD5();
 
     /** Processes input, adding it to the digest.
      *  Note that this treats the buffer as a series of uint8_t values.
      */
     virtual bool write(const void* buffer, size_t size) SK_OVERRIDE {
         update(reinterpret_cast<const uint8_t*>(buffer), size);
         return true;
     }
 
     /** Processes input, adding it to the digest. Calling this after finish is undefined. */
     void update(const uint8_t* input, size_t length);
 
-    struct Digest {
-        uint8_t data[16];
-    };
-
     /** Computes and returns the digest. */
-    void finish(Digest& digest);
+    void finish(SkHashDigest& digest);

[bungeman-skia, 2013/04/15 19:19:56]

I see no reason for this change, and I would prefer not to burden the
implementation with a malloc and extra complexity in the case where the size is
already known. The actual content of this change shows no use case in which this
change is actually useful.

SkMD5 and SkSHA1 already implement SkWStream so there is already a common
interface for writing to the hashes (and even better no one knows they are
hashes). At creation of a hash, you have to know which one you're going to
create, so you can reserve the memory (and know the size) at that time. Then
just pass the pointer to that memory to finish and create the
SkData/SkHashDigest around that. This also alleviates the 'extra copy' issue. In
fact I see no reason at the moment to have the extra SkHashDigest type; it seems
it's possible to just use SkData directly?

[epoger, 2013/04/15 19:32:41]

I meant this change as a stepping-stone to making SkBitmapHasher's API
completely unaware of which hash implementation is used by the implementation. 
Thus, callers to SkBitmapHasher could receive the benefits of new hash
implementations without changing any of their code.

I will go ahead and complete that work within this same CL, and send it back for
further review... then perhaps you can help me figure out if there is a
similarly clean way of doing it without a common SkHashDigest class.  Will you
be in the office on Wednesday?  If so, maybe we can "hash" it out in person...

 
 private:
     // number of bytes, modulo 2^64
     uint64_t byteCount;
 
     // state (ABCD)
     uint32_t state[4];
 
     // input buffer
     uint8_t buffer[64];
 };
 
 #endif