6 ms·

Libvirt: Adoption of GLib library to replace GNULIB and home grown code

79 points by adgnaf 6y ago

marktangotango 6y ago
> 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?
- loeg 6y ago
  If your C umbrella includes C++, Qt has a number of (non-GUI) high-level libraries that can be useful for applications.
  - lrossi 6y ago
    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.
    - PaulDavisThe1st 6y ago
      That's only partially true. You'd really something like boost to cover a lot of things that glib provides for C. glib covers many, many things that are outside of the scope of both the C++ and C standard libraries.
    - loeg 6y ago
      In the same way that using glib does not mean you are forced to use Gtk, you can use pieces of Qt without pulling in the GUI library. That's why I mentioned "non-GUI" explicitly. https://en.wikipedia.org/wiki/Qt_(software)#Qt_modules https://en.wikipedia.org/wiki/Qt_(software)#Qt_modules E.g., Core, Network, SQL do not require the GUI components.
  - ognarb 6y ago
    There is QtCore that is more similar in scope to glib and only containers, json and a few more useful stuff. It's a sort of alternate C++ standard library. Personally I wonder why people would choose today using C and Glib over C++ for system programming. I could understand why not Rust but for having to deal with glib in the past its so much of a pain.
    - lrossi 6y ago
      That’s exactly what I am thinking as well. Using C++ in moderation, without getting too crazy with classes, multiple inheritance, lambdas and other such things, works very well if you want to port a legacy C code base. For a new project, there are many choices: rust, go etc.
      - pjmlp 6y ago
        That is mostly how I use C++ nowadays, for writing native libraries to be called from Java/.NET, or GPGPU stuff.
    - loeg 6y ago
      As a mostly C and sometimes Rust programmer, I don't know why I'd ever reach for C++ instead of Rust these days. If I'm going to take on the mental complexity of these big languages, I'd rather have Rust's safety properties. (Not to mention, superior, portable, single-vendor standard library features — something C++ struggled with for a long time and probably still struggles with.)
  - PaulDavisThe1st 6y ago
    Even the Qt folks accepted, though, that for run/event-loop integration between glib and Qt code, it was Qt that provided a way to use the glib event loop not vice versa (because Qt doesn't offer a sufficiently hook-able event loop abstraction).
- JNRowe 6y ago
  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://awesomewm.org/ https://awesomewm.org/ ² https://github.com/muennich/sxiv https://github.com/muennich/sxiv - my user configs are lua & lgi, extended with gexiv2 also via gobject-introspection. ³ https://mpv.io/ https://mpv.io/
  - stretchcat 6y ago
    Incidentally, mpv is extensible enough to replicate sxiv's features with the right configuration and scripts. I like to think of mpv as the emacs of multimedia.
    - h_anna_h 6y ago
      mpv eats a lot of memory even when you use it to just view images.
- saurik 6y ago
  https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSPR https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NS... > Netscape Portable Runtime (NSPR) provides a platform-neutral API for system level and libc-like functions. The API is used in the Mozilla clients, many of Red Hat's and Oracle's server applications, and other software offerings.
- tyingq 6y ago
  Qlibc: http://wolkykim.github.io/qlibc/ http://wolkykim.github.io/qlibc/
lrossi 6y ago
Glib 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.
- lrossi 6y ago
  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.
  - wahern 6y ago
    The BSDs basically solved this problem decades ago: <sys/queue.h> and <sys/tree.h> provide type-safe core data structures sufficient for most C application needs. The amount of wheel reinvention and dependency complexity outside the BSD universe blows my mind. (Though, FreeBSD projects do have a greater tendency to complicate things, perhaps owing to the stronger corporate-induced feature chasing.) The only real universal sore spot IME has been arrays and vectors. But nobody seems to pitch glib as a way to get a fast and ergonomic FIFO buffer. There are many other areas without simple, go-to solutions, but then that's the nature of C programming. Most of the C programmers I interact with are multi-language programmers, as opposed to many C++, Java, etc engineers who lean toward single-language, monolithic approaches. I can understand using glib for GUI applications, considering it's already a requirement for Gtk, and because of the OOP emphasis in GUI programming. But IMNSHO, in most other areas the right reasons for selecting C as your implementation language are mutually exclusive with the need for cookie-cutter, void-pointer heavy data structure implementations a la glib. EDIT: Removed outdated discussion of systemd + glib.
  - attractivechaos 6y ago
    In addition, using void pointers harms performance as this strategy often incurs additional heap allocations, hurts memory locality and prevents compiler optimization. Personally, I avoid glib like a plague.
qalmakka 6y ago
I think that 3/4 of their issues would probably be solved by a well thought use of modern C++. I've seen too many C projects (including some of mine) starting by swearing out C++ for one reason or another and then ending out reimplementing half of it using macros or poorly written hashmap implementations taken from somewhere. Glib2 is one excellent example of how people have been shunning C++ due to its complexity, while on the other hand implementing overly complex libraries to mitigate the fact it's too barebones, which is oxymoronic to me. Either you say C is better because its simplicity and you keep stuff simple, or you are just being a zealot for the sake of it. Basically everything I can put my hands on supports C++, I've been running massive applications on embedded microcontrollers and it works as fine as C. If you don't like some features, just write C-style C++, use the C ABI and #include <> all the containers you need.
- jononor 6y ago
  Agreed in general on using C++ over C, or C-style C++ in constrained environments. One thing that is nice about using C though is that it is quite easy (compared to C++) to expose to other languages. Glib, and most libraries built on it like GTK, GStreamer, etc can be used in languages such as Python, JavaScript et.c.. And a lot of development of applications and tools has been moving to such languages over say C++. So C is still useful for low-level libraries, due to being the lowest common denominator. Though arguably one could today write the library core in a better language like Rust maybe, and expose a C API/ABI from that. Rsvg is growing into an example of that.
  - pjmlp 6y ago
    I look forward to it eventually to grow into OS vendors SDKs, at very least those that provide llvm based toolchains. Until then C++ will do.
    - jononor 6y ago
      Do you mean glib? It is in every server and desktop Linux distro, including those with commercial support from RedHat, Canonical and SUSE. For embedded Linux devices glib is included in Ubuntu Core from Canonical, as well as Wind River Linux from Intel. The GStreamer SDK includes glib and is supported by Fluendo and Collabora on Android, Windows and Mac.
h_anna_h 6y ago
I sure love gvoid and gint. I also love my program crashing instead of returning an error when I use glib lists and its internal malloc invocation fails.
ibotty 6y ago
This article is nearly a year old. Is there any news on the progress?

79 points by adgnaf 6y ago

> 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?

loeg 6y ago
If your C umbrella includes C++, Qt has a number of (non-GUI) high-level libraries that can be useful for applications.
- lrossi 6y ago
  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.
  - PaulDavisThe1st 6y ago
    That's only partially true. You'd really something like boost to cover a lot of things that glib provides for C. glib covers many, many things that are outside of the scope of both the C++ and C standard libraries.
  - loeg 6y ago
    In the same way that using glib does not mean you are forced to use Gtk, you can use pieces of Qt without pulling in the GUI library. That's why I mentioned "non-GUI" explicitly. https://en.wikipedia.org/wiki/Qt_(software)#Qt_modules https://en.wikipedia.org/wiki/Qt_(software)#Qt_modules E.g., Core, Network, SQL do not require the GUI components.
- ognarb 6y ago
  There is QtCore that is more similar in scope to glib and only containers, json and a few more useful stuff. It's a sort of alternate C++ standard library. Personally I wonder why people would choose today using C and Glib over C++ for system programming. I could understand why not Rust but for having to deal with glib in the past its so much of a pain.
  - lrossi 6y ago
    That’s exactly what I am thinking as well. Using C++ in moderation, without getting too crazy with classes, multiple inheritance, lambdas and other such things, works very well if you want to port a legacy C code base. For a new project, there are many choices: rust, go etc.
    - pjmlp 6y ago
      That is mostly how I use C++ nowadays, for writing native libraries to be called from Java/.NET, or GPGPU stuff.
  - loeg 6y ago
    As a mostly C and sometimes Rust programmer, I don't know why I'd ever reach for C++ instead of Rust these days. If I'm going to take on the mental complexity of these big languages, I'd rather have Rust's safety properties. (Not to mention, superior, portable, single-vendor standard library features — something C++ struggled with for a long time and probably still struggles with.)
- PaulDavisThe1st 6y ago
  Even the Qt folks accepted, though, that for run/event-loop integration between glib and Qt code, it was Qt that provided a way to use the glib event loop not vice versa (because Qt doesn't offer a sufficiently hook-able event loop abstraction).
JNRowe 6y ago
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://awesomewm.org/ https://awesomewm.org/ ² https://github.com/muennich/sxiv https://github.com/muennich/sxiv - my user configs are lua & lgi, extended with gexiv2 also via gobject-introspection. ³ https://mpv.io/ https://mpv.io/
- stretchcat 6y ago
  Incidentally, mpv is extensible enough to replicate sxiv's features with the right configuration and scripts. I like to think of mpv as the emacs of multimedia.
  - h_anna_h 6y ago
    mpv eats a lot of memory even when you use it to just view images.
saurik 6y ago
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSPR https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NS... > Netscape Portable Runtime (NSPR) provides a platform-neutral API for system level and libc-like functions. The API is used in the Mozilla clients, many of Red Hat's and Oracle's server applications, and other software offerings.
tyingq 6y ago
Qlibc: http://wolkykim.github.io/qlibc/ http://wolkykim.github.io/qlibc/

lrossi 6y ago

Glib 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.

lrossi 6y ago
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.
- wahern 6y ago
  The BSDs basically solved this problem decades ago: <sys/queue.h> and <sys/tree.h> provide type-safe core data structures sufficient for most C application needs. The amount of wheel reinvention and dependency complexity outside the BSD universe blows my mind. (Though, FreeBSD projects do have a greater tendency to complicate things, perhaps owing to the stronger corporate-induced feature chasing.) The only real universal sore spot IME has been arrays and vectors. But nobody seems to pitch glib as a way to get a fast and ergonomic FIFO buffer. There are many other areas without simple, go-to solutions, but then that's the nature of C programming. Most of the C programmers I interact with are multi-language programmers, as opposed to many C++, Java, etc engineers who lean toward single-language, monolithic approaches. I can understand using glib for GUI applications, considering it's already a requirement for Gtk, and because of the OOP emphasis in GUI programming. But IMNSHO, in most other areas the right reasons for selecting C as your implementation language are mutually exclusive with the need for cookie-cutter, void-pointer heavy data structure implementations a la glib. EDIT: Removed outdated discussion of systemd + glib.
- attractivechaos 6y ago
  In addition, using void pointers harms performance as this strategy often incurs additional heap allocations, hurts memory locality and prevents compiler optimization. Personally, I avoid glib like a plague.

qalmakka 6y ago

I think that 3/4 of their issues would probably be solved by a well thought use of modern C++. I've seen too many C projects (including some of mine) starting by swearing out C++ for one reason or another and then ending out reimplementing half of it using macros or poorly written hashmap implementations taken from somewhere. Glib2 is one excellent example of how people have been shunning C++ due to its complexity, while on the other hand implementing overly complex libraries to mitigate the fact it's too barebones, which is oxymoronic to me. Either you say C is better because its simplicity and you keep stuff simple, or you are just being a zealot for the sake of it. Basically everything I can put my hands on supports C++, I've been running massive applications on embedded microcontrollers and it works as fine as C. If you don't like some features, just write C-style C++, use the C ABI and #include <> all the containers you need.

jononor 6y ago
Agreed in general on using C++ over C, or C-style C++ in constrained environments. One thing that is nice about using C though is that it is quite easy (compared to C++) to expose to other languages. Glib, and most libraries built on it like GTK, GStreamer, etc can be used in languages such as Python, JavaScript et.c.. And a lot of development of applications and tools has been moving to such languages over say C++. So C is still useful for low-level libraries, due to being the lowest common denominator. Though arguably one could today write the library core in a better language like Rust maybe, and expose a C API/ABI from that. Rsvg is growing into an example of that.
- pjmlp 6y ago
  I look forward to it eventually to grow into OS vendors SDKs, at very least those that provide llvm based toolchains. Until then C++ will do.
  - jononor 6y ago
    Do you mean glib? It is in every server and desktop Linux distro, including those with commercial support from RedHat, Canonical and SUSE. For embedded Linux devices glib is included in Ubuntu Core from Canonical, as well as Wind River Linux from Intel. The GStreamer SDK includes glib and is supported by Fluendo and Collabora on Android, Windows and Mac.

h_anna_h 6y ago

I sure love gvoid and gint. I also love my program crashing instead of returning an error when I use glib lists and its internal malloc invocation fails.

ibotty 6y ago

This article is nearly a year old. Is there any news on the progress?