New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 922697 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , iOS , Chrome , Mac
Pri: 3
Type: Bug



Sign in to add a comment

UKM client id generation code mixes Uint64 and Int64

Project Member Reported by asvitk...@chromium.org, Jan 16 (6 days ago)

Issue description

UKM client id generation code mixes Uint64 and Int64.

Relevant code:

    client_id = base::RandUint64();
  pref_service->SetInt64(prefs::kUkmClientId, client_id);

https://cs.chromium.org/chromium/src/components/ukm/ukm_service.cc?rcl=f3463c78b77bc4cefd8e748c4f47a2324515ad47&l=34

So we're generating and storing it in memory as a uint64_t but when we store it in prefs, we store it as Int64. This is confusing for no good reason and I guess compiler is silently ignoring the signed conversions.

Ideally, we should use SetUint64 on pref_service, but now that would require migrating prefs. We could instead make the rest of the code uint int64 at least.
 

Comment 1 by asvitk...@chromium.org, Jan 16 (6 days ago)

Although the proto format is fixed64 which is unsigned. 

Comment 2 by asvitk...@chromium.org, Jan 16 (6 days ago)

One thing we *could* do without migrating to a new pref is change the type of the pref to a string and do our own processing of it, and save it back as unsigned. Then after some milestones where things are migrated, change the type of the pref to the proper uint64.

Sign in to add a comment