GNOME Bugzilla – Bug 653005
GMatchInfo and the lifetime of the matched stirng
Last modified: 2018-05-24 13:12:40 UTC
When creating a GMatchInfo using the g_regex_match*() functions, the matched string is not copied, so it needs to be kept alive as long as the match info is used. This is a problem when the string was created from other data just to be matched, and the match info is then passed around (e.g. passed out via public APIs), which makes it impossible to manage the string's lifecycle. (I have this problem in vte.) I can think of a few ways to solve this: 1) Add a G_REGEX_MATCH_TAKE_STRING flag to GRegexMatchFlags, that when passed to g_regex_match*() makes the match info own the string, and free it using g_free(). (The problem here is that it hardcodes the destroy notify to g_free().) 2) Add new g_regex_match_fuller() (since match_full is already taken) that takes an additional (data, destroy notify) pair. 3) Add qdata to GMatchInfo, so I can store the string there with an appropriate destroy notify. 3a) Add g_match_info_set_data(GMatchInfo*, gpointer, GDestroyNotify), since I really need just one pointer, not a whole family of qdatas. 3a) is the simplest solution; attached patch implements it.
Created attachment 190271 [details] [review] Add g_match_info_[sg]et_data The string passed to g_regex_match*() needs to live as long as the returned GMatchInfo is used. When passing the match info around, and the string was generated just to be matched, this makes managing the lifecycle of the string difficult. By adding g_match_info_set_data(), the string's lifetime can be tied to the lifetime of the match info. Bug #653005.
This is why we should make everything a GObject... It's weird that GMatchInfo doesn't even have a refcount.
GMatchInfo neither has a ref function nor a copy. How is it boxed then?
It doesn't have a boxed GType either. Do you think it should have one, and ref/unref funcs?
I understand that the gregex stuff is considered mostly-C-only because every other language has its own regex. But when we have vte API returning GRegex or match-info, it needs to be bindable, right?
I guess so, yes. The boxed type for GRegex was added way back in bug 445065, but strangely no mention was made of GMatchInfo then.
Filed that as bug 653248.
(In reply to comment #2) > This is why we should make everything a GObject... It's weird that GMatchInfo > doesn't even have a refcount. Yes, but that's impossible since gregex is in libglib and thus cannot be a gobject. At least it's now refcounted (from bug 653248). Any opinion from the glib maintainers on the patch here and/or on the different possibilities in comment 0 ?
Ping? Any chance of getting this into 2.32 ?
I'l try to have a look
I'm now leaning more towards 2), a g_regex_match_full variant perhaps called g_regex_match_take_string() (no need to expose a take-string non-full version as well, since this is kind of a specialised use case anyway).
-- 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/419.