[lrossi]

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.

[the_why_of_y]

Did you try to disable the slab allocator?

https://developer.gnome.org/glib/stable/glib-running.html#G_...

[lrossi]

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) */

This bug should actually be caught during compilation if we store the list in a GSList* typed variable instead of void*. You’d think: who does that?

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.

[baybal2]

You seem to know a lot about Glib. What did you do with it?

I looked to port Gtk to MCU, and then gave up. Too much C trickery, and hard to replace, heavy dependencirs.

For somebody who knew Qt, and Gtk since 2003, it looks like a miracle now how Qt got smaller, and faster than Gtk, and can even run on an MCU, and quite well!

Very big contribution to that was Qt's team willingness to undo the wheel reinvention, and willingness to throw out their hacky attempts to replicate new c++, and standard lib functionality.

The Glib+Gtk world, unlike Qt, still lives in ANSI C, and C99 era, and refuses to concede on reinventing functionality of modern standard libraries, language features, and compilers.

[lrossi]

I worked on some Linux apps in another life. I switched to Qt at some point. It was a breath of fresh air! Qt is very reliable and well documented. One can be very productive with it.

I think a lot of people have a bad opinion about it as they confuse it with KDE. While KDE does use Qt, the two projects are otherwise independent.

I’ve also looked inside the Qt code base a few times. It’s very tidy and quite easy to read. You can tell that their team is very experienced. I used to read their blog as well, they had a lot of good articles.

I really hope that they can continue to survive financially. Selling a mostly open source library is not very profitable.

[ldng]

The problem with Qt is The Company. They have a tendency to cater to their exclusive needs and not bothering much with Linux. A bit like Mozilla. Yet they're claiming to be fully cross-platform. They pushed 6 with regressions.

Qt is undoubtedly interesting but really have steering issues.

[pjmlp]

Here is the thing, GNU/Linux desktop developers aren't those who pays their bills, so they cater to the OS vendors and OEMs that actually pay them.

[baybal2]

> They pushed 6 with regressions.

Gtk pushes every minor version with regressions.

Qt looks quite good in comparison.

[the_why_of_y]

The Glib+Gtk world chose to limit itself to a C ABI, which makes it far easier to interop with other languages than C++ as used by Qt.

This is the case both for statically compiled as well as dynamically interpreted language implementations; the latter can use automatically generated bindings via gobject-introspection, which has no equivalent in the Qt world, where all language bindings are hand-crafted at great effort.

https://gi.readthedocs.io/en/latest/

It also means that the implementation behind the ABI can be replaced with a different language such as Rust, as has already been done with librsvg. On the other hand, Qt will forever be stuck with legacy C++ language, which appears designed to be nigh impossible to interop with.

And if you have a requirement to use C++, there is the gtkmm binding too, which doesn't require a separate language extension such as Qt's MOC to use.

https://www.gtk.org/docs/language-bindings/cpp/

[Asooka]

Qt can trivially offer a C ABI if they want. Glib can't be type safe no matter how hard they try. People don't seem to have any trouble making Qt bindings for languages like Go, Python, Java, all of which you could say strongly prefer interop with C. Part of the reason is that Qt is written in a way that avoids use of more exotic features and templates for most things. MOC could be replaced by template magic nowadays, but I don't see any value in doing so - you will just make compilation slower and bindings with other languages harder.

[baybal2]

Well, I mean they could've moved up to more recent standards well within the C world.

As of now, Glib doesn't even utilize much of C99.

[h_anna_h]

> g_list_free (slist); /* corruption: sizeof (GSList) != sizeof (GList) */

Catching this error at runtime would be extremely trivial. Just add a magic number on top of the GSList and GList structs.

[asveikau]

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

[pmiller2]

I don't know anything about this cache you're referring to, but, is it so pervasive within the library that you can't easily do a patch to remove it? Would such a patch be accepted by upstream? If you're opposed to using the environment variable, those would be my next thoughts if you wanted to get back the ability to use valgrind et al.

[ibotty]

You only need an environment variable. It is already implemented. They just did not try it.

[lrossi]

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]

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]

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.

[nn3]

At least for valgrind it's fairly easy to annotate custom mallocs in the source. Just someone needs to do that.

[inetknght]

> these days there is no reason to cache and reuse allocations.

No, you are wrong. Ideas like that are a big reason that apps get slower despite hardware getting faster.

[asveikau]

I think it becomes an application specific or domain specific thing.

For example, I've done some work with audio or video. Nobody working on that goes straight to malloc on every packet or frame. It'd just be asking for pain.

But a general purpose allocator doing its own free-list on the assumption that libc is going to suck? I think that's outdated. If you do want to support it, I think it's better to allow the caller to replace the allocator through a function pointer, rather than just do it by default in a library.

[TingPing]

glib does not always use one, the default is normal malloc and it provides another allocator api as an option.

[asveikau]

Yes, I figured that out from other posts on this thread (including one where I looked at g_malloc source).

I think libstc++ on the other hand does or did have such a cache as an always-on thing though. So not unheard of.

[stretchcat]

Isn't the right way of doing this to use a different implementation of malloc, rather than wrapping malloc with your own meta-malloc?

[inetknght]

> Isn't the right way of doing this to use a different implementation of malloc, rather than wrapping malloc with your own meta-malloc?

Yup [0].

There's even other complete libraries like tcmalloc [1] and jemalloc [2].

[0] https://stackoverflow.com/a/262481/1111557

[1] https://github.com/google/tcmalloc

[2] https://github.com/jemalloc/jemalloc

[saagarjha]

One reason I can think of wrapping malloc is that C is more likely to give you that than whatever OS-specific API you are going to use to get memory from the kernel (if you even have one!).