Profile_Metrics integration with Keystone

chrome/installer/util/google_update_settings.h

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef CHROME_INSTALLER_UTIL_GOOGLE_UPDATE_SETTINGS_H_
 #define CHROME_INSTALLER_UTIL_GOOGLE_UPDATE_SETTINGS_H_
 
 #include <string>
 
 #include "base/basictypes.h"
@@ skipping 200 matching lines @@
   // archive_type: tells whether this is incremental install or not.
   // install_return_code: if 0, means installation was successful.
   // value: current value of Google Update "ap" key.
   // Returns true if |value| is modified.
   static bool UpdateGoogleUpdateApKey(installer::ArchiveType archive_type,
                                       int install_return_code,
                                       installer::ChannelInfo* value);
 
   // This method updates the values that report how many profiles are in use
   // and how many of those are signed-in.
-  static void UpdateProfileCounts(int profiles_active, int profiles_signedin);
+  static void UpdateProfileCounts(size_t profiles_active,

[grt (UTC plus 2), 2015/02/21 00:08:47]

Why size_t?
http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Integer_Types

[Mike Lerman, 2015/02/23 16:12:12]

I went with size_t because that's what we tend to use in profiles when there's a
non-negative number, e.g. a count of profiles, an iterator over profiles, or an
index into the ProfileInfoCache. That link you mention notes that size_t is
acceptable to use.

mark@ prefers the parameter passed to Keystone be of an unsigned type, so I
wanted to be consistent to the windows side as well.

[grt (UTC plus 2), 2015/02/23 20:50:01]

That seems to run contrary to "In particular, do not use unsigned types to say a
number will never be negative." size_t is unambiguously correct when used to
index into a std container (e.g., iterating over a vector), but it's less clear
to me that "there will never be a negative number of profiles" is a good reason.
My take on the style guide is that int is the correct type for this.

Mark: why do you prefer an unsigned type for Keystone?

+                                  size_t profiles_signedin);
 
   // For system-level installs, we need to be able to communicate the results
   // of the Toast Experiments back to Google Update. The problem is just that
   // the experiment is run in the context of the user, which doesn't have
   // write access to the HKLM key that Google Update expects the results in.
   // However, when we are about to switch contexts from system to user, we can
   // duplicate the handle to the registry key and pass it (through handle
   // inheritance) to the newly created child process that is launched as the
   // user, allowing the child process to write to the key, with the
   // WriteGoogleUpdateSystemClientKey function below.
@@ skipping 81 matching lines @@
   // this will do nothing to |experiment_labels|. This will return true if the
   // label did not exist, or was successfully read.
   static bool ReadExperimentLabels(bool system_install,
                                    base::string16* experiment_labels);
 
  private:
   DISALLOW_IMPLICIT_CONSTRUCTORS(GoogleUpdateSettings);
 };
 
 #endif  // CHROME_INSTALLER_UTIL_GOOGLE_UPDATE_SETTINGS_H_