Libvirt: Adoption of GLib library to replace GNULIB and home grown code
1–10 of 66 posts
Re: Libvirt: Adoption of GLib library to replace GNULIB and home grown code
#2> These problems are common to many applications / libraries that are written in C and thus there are a number of libraries that attempt to provide a high level “standard library”. The GLib library is one such effort from the GNOME project developers that has long been appealing.
I've been a fan of glib for some time, other than glib and apache libapr, what other "high level standard libraries" for C should I know about?
Re: Libvirt: Adoption of GLib library to replace GNULIB and home grown code
#3Glib is OK except for the fact that it has a memory cache on top of that of malloc. This prevents tools like asan or valgrind from detecting memory related bugs. It caused my team a lot of grief, to the point that we regretted the choice of using glib in the first place.
I am not sure why there is a memory cache in the first place. Malloc may have been slow in the 90s, but these days there is no reason to cache and reuse allocations.
It’s also a major security risk, since it nullifies hardening measures from the standard library, as we have seen with openssl/heartbleed recently.
Re: Libvirt: Adoption of GLib library to replace GNULIB and home grown code
#4> These problems are common to many applications / libraries that are written in C and thus there are a number of libraries that attempt to provide a high level “standard library”. The GLib library is one such effort from the GNOME project developers that has long been appealing. I've been a fan of glib for some time, other than glib and apache libapr, what other "high level standard libraries" for C should I know ab…
If your C umbrella includes C++, Qt has a number of (non-GUI) high-level libraries that can be useful for applications.
Re: Libvirt: Adoption of GLib library to replace GNULIB and home grown code
#5Glib is OK except for the fact that it has a memory cache on top of that of malloc. This prevents tools like asan or valgrind from detecting memory related bugs. It caused my team a lot of grief, to the point that we regretted the choice of using glib in the first place. I am not sure why there is a memory cache in the first place. Malloc may have been slow in the 90s, but these days there is no reason to cache and r…
Another problem is that there is no type checking in the containers. So you have to cast everything to/from void pointers, even for basic structures like lists and arrays. This makes it easy to introduce tricky bugs.
Re: Libvirt: Adoption of GLib library to replace GNULIB and home grown code
#6Glib is OK except for the fact that it has a memory cache on top of that of malloc. This prevents tools like asan or valgrind from detecting memory related bugs. It caused my team a lot of grief, to the point that we regretted the choice of using glib in the first place. I am not sure why there is a memory cache in the first place. Malloc may have been slow in the 90s, but these days there is no reason to cache and r…
Curious for some details. On what layer does that caching occur?
I immediately thought g_malloc but it seems to call directly to libc: https://github.com/GNOME/glib/blob/master/glib/gmem.c
Re: Libvirt: Adoption of GLib library to replace GNULIB and home grown code
#7> These problems are common to many applications / libraries that are written in C and thus there are a number of libraries that attempt to provide a high level “standard library”. The GLib library is one such effort from the GNOME project developers that has long been appealing. I've been a fan of glib for some time, other than glib and apache libapr, what other "high level standard libraries" for C should I know ab…
I can't offer extra recommendations, but just wanted to offer full agreement.
GLib is the awesome standard library I get to use everywhere thanks to gobject-introspection. From work projects in Vala, window manager¹, image viewer², video player³. It is especially useful with lua configurable projects, given the sparsity of the language itself.
² https://github.com/muennich/sxiv - my user configs are lua & lgi, extended with gexiv2 also via gobject-introspection.
Re: Libvirt: Adoption of GLib library to replace GNULIB and home grown code
#8Glib is OK except for the fact that it has a memory cache on top of that of malloc. This prevents tools like asan or valgrind from detecting memory related bugs. It caused my team a lot of grief, to the point that we regretted the choice of using glib in the first place. I am not sure why there is a memory cache in the first place. Malloc may have been slow in the 90s, but these days there is no reason to cache and r…
Did you try to disable the slab allocator?
https://developer.gnome.org/glib/stable/glib-running.html#G_...
Re: Libvirt: Adoption of GLib library to replace GNULIB and home grown code
#9Glib is OK except for the fact that it has a memory cache on top of that of malloc. This prevents tools like asan or valgrind from detecting memory related bugs. It caused my team a lot of grief, to the point that we regretted the choice of using glib in the first place. I am not sure why there is a memory cache in the first place. Malloc may have been slow in the 90s, but these days there is no reason to cache and r…
Did you try to disable the slab allocator? https://developer.gnome.org/glib/stable/glib-running.html#G_...
I am aware of that environment variable. The problem is that I think almost nobody is using it, so it could come with a risk of introducing more bugs.
By the way, the example shown in the documentation page that you link to seems ridiculous:
void *slist = g_slist_alloc (); /* void* gives up type-safety */
g_list_free (slist); /* corruption: sizeof (GSList) != sizeof (GList) */
Except that this is what you actually end up doing when using any kind of nested glib containers. Elements are always void*, so you have to cast them correctly. So for non-trivial applications, it’s very easy to make mistakes, since you lose the type checking support of the compiler.
C is already a tricky language. Removing the type checker makes it even worse.
Re: Libvirt: Adoption of GLib library to replace GNULIB and home grown code
#10> These problems are common to many applications / libraries that are written in C and thus there are a number of libraries that attempt to provide a high level “standard library”. The GLib library is one such effort from the GNOME project developers that has long been appealing. I've been a fan of glib for some time, other than glib and apache libapr, what other "high level standard libraries" for C should I know ab…
If your C umbrella includes C++, Qt has a number of (non-GUI) high-level libraries that can be useful for applications.
Qt is more like gtk rather than glib. Although it does come with a fantastic core library.
But if you can move to C++, the standard library already offers great replacements for most glib features. Glib exists mostly because the C standard library is lacking in many aspects.