On Thu, 19 Oct 2017 11:11:13 +0200
Kamil Cholewiński <harry6...@gmail.com> wrote:
Dear Kamil,
> > - Arg a = {.v = text };
> > + char *trimed = g_strstrip(g_strdup(text));
> > + Arg a = {.v = trimed };
>
> Doesn't this leak memory via strdup on every paste? Or does Gobject do
> some automagic ref counting or whatnot?
sorry for the GitHub-links, but I investigated this further and found
no better public source of the GNOME glib.
g_strdup() is defined here[0], which itself makes a call to g_new()[1],
which itself is an alias for the internal macro _G_NEW with a parameter
to call g_malloc_n()[2], which makes an overflow check (fair enough, it
corresponds to reallocarray()), and then calls g_malloc()[3].
As a small fun part, there's also a function g_malloc0_n() just below
g_malloc_n() which does exactly the same (the code is identical).
I think they created g_malloc0_n() to be a "safe" interface while
keeping g_malloc_n() for "performance" reasons, but then later on
noticed that it might be smart to do the check anyway, having two
identical functions and bloating the API unnecessarily.
Alright, we are now at g_malloc(), and as we can see in line 94 it's
just malloc() with some GNOME-vomit around it.
TL;DR: g_strdup() == strdup()
Reading this code is a real pain. It's like diving into a fractal,
where every function decomposes into even smaller parts, and on each
level, everything looks the same.
With best regards
Laslo Hunhold
[0]: https://github.com/GNOME/glib/blob/master/glib/gstrfuncs.c#L344
[1]: https://github.com/GNOME/glib/blob/master/glib/gmem.h#L245
[2]: https://github.com/GNOME/glib/blob/master/glib/gmem.c#L310
[3]: https://github.com/GNOME/glib/blob/master/glib/gmem.c#L78
--
Laslo Hunhold <d...@frign.de>
