Fix valgrind issue in SkBase64Test.cpp

tests/SkBase64Test.cpp

 /*
  * Copyright 2014 Google Inc.
  *
  * Use of this source code is governed by a BSD-style license that can be
  * found in the LICENSE file.
  */
 
 #include "SkBase64.h"
 
 #include "Test.h"
 
 DEF_TEST(SkBase64Test, reporter) {
     char all[256];
-    for (int index = 0; index < 256; index++) {
+    for (int index = 0; index < 256; ++index) {

[tfarina, 2014/02/01 15:46:21]

does pre-increment makes any difference here, or was this a pure-cosmetic
change?

[robertphillips, 2014/02/01 15:50:24]

In this case it doesn't make any performance difference and is more of a style
thing. For actual class based iterators pre vs. post increment/decrement could
make a difference.

         all[index] = (signed char) (index + 1);
     }
 
-    for (int offset = 0; offset < 6; offset++) {
+    for (int offset = 0; offset < 6; ++offset) {
         size_t length = 256 - offset;
         size_t encodeLength = SkBase64::Encode(all + offset, length, NULL);
         SkAutoTMalloc<char> src(encodeLength + 1);
         SkBase64::Encode(all + offset, length, src.get());
+        src[encodeLength] = '\0';

[tfarina, 2014/02/01 15:46:21]

looks like I removed this when I used SkAutoMalloc (which does not have
operator[]) and forgot to add it back when I switched to SkAutoTMalloc.

[robertphillips, 2014/02/01 15:50:24]

Yep - np. The recent noise on the valgrind bot hid this yesterday.

         SkBase64 tryMe;
         tryMe.decode(src.get(), encodeLength);
         REPORTER_ASSERT(reporter, (strcmp((const char*) (all + offset), tryMe.getData()) == 0));
         delete[] tryMe.getData();
     }
 }