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 743971 - RFC: new conventions for _clear() functions
RFC: new conventions for _clear() functions
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: general
unspecified
Other All
: Normal enhancement
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2015-02-04 09:31 UTC by Allison Karlitskaya (desrt)
Modified: 2018-05-24 17:24 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Allison Karlitskaya (desrt) 2015-02-04 09:31:47 UTC
I propose that we establish a convention that says that all _clear functions are idempotent.

Main argument: this is already the case for some _clear() functions: notably those on GVariantBuilder, GVariantDict, GQueue, etc.  For other types it's undefined.  We have an inconsistency.  We can't change the functions that are already defined to work, so if we want consistency, we need to change the undefined ones.

Open question is if we guarantee _clear() to also work (and do nothing) on zero-filled memory.  Often _clear() will function by resetting the memory in question to all-zeros so we will sometimes get this for free anyway, but it's not always the case.  Consistency would again suggest that we do this everywhere.

In addition to being an improvement in consistency it will also make _clear() functions nicer for use with g_auto().  As it stands, if you set up a g_auto() variable for a stack-allocated type with a _clear() function then you can get yourself into some pretty annoying situations.
Comment 1 GNOME Infrastructure Team 2018-05-24 17:24:47 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/987.