13303 - Gratuitous use of strings for storing booleans in registry

Status: VERIFIED FIXED

(Core Graveyard :: Profile: BackEnd, defect, P3)

Description

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

The profile manager is using strings in the registry to store single bits of
information, such as the migration state of a profile.

nsProfile::GetProfileDir has a good example:

  // Get the value of entry "migrated" to check the nature of the profile
  m_reg->GetString( newKey, "migrated", &isMigrated);

(isMigrated is never subsequently freed, as with a few other registry-returned
strings in that function and others.)

If you were to use integers for "migrated", you'd be able to avoid the memory
management headaches and get a performance win to boot.

To close this bug, you should:
- ensure that you properly free all registry-returned strings
- audit for excessive strdups (see 13298 for an example)
- decide if you're going to switch to GetInt for the boolean attributes.  (If
not, please just note why not in this bug.)

Thanks.


Why not use an int

Comment 1

[selmer (gone)]

I don't see any functional reason to store this as a string in the registry.

Comment 2

[racham]

I will change the migration status flag to an int and take care of other
comments. Thanks. Changing status to assigned.

Comment 3

[leger]

Putting on [Perf] radar.

Comment 4

[selmer (gone)]

These bugs are not critical for beta 1, moving out.

Comment 5

[leger]

Bulk add of "perf" to new keyword field.  This will replace the [PERF] we were
using in the Status Summary field.

Comment 6

[leger]

Moving all Profile Manager bugs to new Profile Manager Backend component.
Profile Manager component to be deleted.

Comment 7

[racham]

Moving this to M20.

Comment 8

[racham]

Doing a mass reassign to Conrad Carlen.

Conrad is going address all current and upcoming profile manager issues. Please
do not hesitate to involve me in any of the issues.

Comment 9

[Conrad Carlen (not reading bugmail)]

With some work I did on nsProfileAccess.cpp recently, most of this has been
fixed. The booleans were stored as strings in the registry but, worse, they were
kept as strings on being internalized. There were many, many unicode string
comparisons being done to test what should be only a single bit of data. My
changes read the string once, disposed of it, and stored it as a PRBool. I kept
it as a string in the registry itself to avoid compatibility problems.

Comment 10

[Grace Bush]

verified code fix