After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 339307 - cookies aren't necessarily unique
cookies aren't necessarily unique
Status: RESOLVED FIXED
Product: gnome-power-manager
Classification: Deprecated
Component: gnome-power-manager
SVN TRUNK
Other Linux
: Normal normal
: ---
Assigned To: GNOME Power Manager Maintainer(s)
GNOME Power Manager Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2006-04-21 14:36 UTC by William Jon McCann
Modified: 2006-04-21 19:29 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description William Jon McCann 2006-04-21 14:36:13 UTC
There is the teensiest chance that the cookies won't be unique simply by using a random number.  Very remote but possible and might cause unreproducable problems.

Here's how I've done it in g-s:

static guint32
generate_cookie ()
{
        guint32 cookie;

        cookie = (guint32)g_random_int_range (1, G_MAXINT32);

        return cookie;
}

static guint32
listener_generate_unique_key (GSListener *listener,
                              int         entry_type)
{
        guint32     cookie;
        GHashTable *hash;

        hash = get_hash_for_entry_type (listener, entry_type);

        do {
                cookie = generate_cookie ();
        } while (g_hash_table_lookup (hash, &cookie) != NULL);

        return cookie;
}

The difference is that I'm using a hash table to store the inhibit data and you use a list.
Comment 1 Richard Hughes 2006-04-21 14:43:51 UTC
I think I would rather keep it as a list for now, but I do see your point. Should I just check for the generated number in my existing list after I get the int_range?
Comment 2 William Jon McCann 2006-04-21 14:50:06 UTC
That'd work.  Just replace g_hash_table_lookup with a g_list_find_custom or something.
Comment 3 William Jon McCann 2006-04-21 14:54:50 UTC
Oh, it is probably good to leave zero as a reserved value for the cookie is not set.  And why do you only go up to 10240 ?

	data->cookie = g_random_int_range (0, 10240);

I've made the cookie unsigned so it is always positive, reserved zero, and made it go up to G_MAXINT32 which is within the limit of both gint and guint.  What do you think?
Comment 4 Richard Hughes 2006-04-21 15:08:22 UTC
(In reply to comment #3)
> Oh, it is probably good to leave zero as a reserved value for the cookie is not set.  And why do you only go up to 10240 ?

A random big number :-)

> I've made the cookie unsigned so it is always positive, reserved zero, and made it go up to G_MAXINT32 which is within the limit of both gint and guint.  What do you think?

Sounds good to me.

So, general rule of cookie:

* not zero
* between 1 and G_MAXINT32
* unique

I can live with that :-)

I'll make the required changes tonight.

Thanks.

Comment 5 Richard Hughes 2006-04-21 19:29:16 UTC
2006-04-21  Richard Hughes  <richard@hughsie.com>
 * src/gpm-inhibit.{c|h} (gpm_inhibit_generate_cookie): Make sure the cookie we generate is really unique. Fixes bug #339307.
 (gpm_inhibit_find_cookie, gpm_inhibit_cookie_compare_func): Create these functions so we can easily find data in the list from another cookie.