lib-c Interpretationen

Man könnte genau so gut fragen:

Wie sieht Gott aus?

und würde ähnlich viele unterschiedlichen Antworten erhalten, wie es Implementierungsunterschiede der C Systembibliotheken gibt.

Und damit meine ich nicht Windows versus Linux. Nein, es reicht schon Linux-Distros zu vergleichen oder POSIX ins Spiel zu bringen.

Nachdem DOS und Windows 3.x damit gescheitert waren, MS-Header und die WinAPI als dominante C-Programm-Basis zu verbreiten, wurde in NT und Win9x die C-Runtime als Kompatibilitätsschicht eingeführt, damit auch Microsoft Programme malloc() nutzen und nicht wie vorher üblich zB.: LocalAlloc()

Der Hass der Unixianer war groß, weil obwohl vieles “irgendwie” lief, gab es immer Unterschiede bei den Locales, oder wenn __int64 vorkam und printf() ein paar Flags mehr oder weniger verstand.

Die großen bekannten Linux-Distributionen wie Debian und SuSE nutzen meines Wissens immer schon brav die GNU GLIB-C und so war für mich deren Implementierung quasi “der Standard”.

Doch seit meiner Beschäftigung mit BSD, stelle ich immer wieder fest, dass die Behauptung, die C-Lib Implementierungen seien alle zu POSIX kompatibel und fügen nur ein paar Erweiterungen hinzu, stelle ich fest, dass dann doch noch immer ein bisschen Interpretationsspielraum zwischen Theorie und Praxis liegt.

Kleinere Distros wie Alpine Linux nutzen z.B. die musl-libc, die sich ob ihrer Einfachheit als sehr “schnell” behauptet. Dass es dort dann keinen (oder nicht immer) einen Header namens <sys/sysctl.h> gibt, weil diese Funktion schon wo anders eingebunden wird, ist zwar lästig, aber per

#include <features.h>
#if defined(__GLIBC__)
#  include <sys/sysctl.h>
#endif

schnell umgangen.

Doch dann lese ich die Seite über die funktionellen Unterschiede zwischen GLIB-C und MUSL-LIBC und finde doch tatsächlich die Aussage, dass dlclose() per NO-OP implementiert ist, also genau gar nichts macht.

Echt jetzt? Man kann Bibliotheken generell nicht “entladen”?
Meine Plugins sind keine Plugins mehr? Waaaas?

Ja, damit hätte ich nicht gerechnet. So sehr ich “schlanke” Funktionen schätze, aber eine OS-Kernfunktionalität einfach still und heimlich entfernen … das geht eigentlich gar nicht.

Der Kernel könnte natürlich alles notwendige, doch wenn die C-Lib nicht will, ist eben Hopfen und Malz verloren …

Fazit

Nun, ich weiß nicht, ob das jetzt “gut” oder “schlecht” ist, dass wirklich jeder offen kritisierte Designfehler in kommerzieller Software von manchen OSS Implementierungen zum “coolen Feature” erhoben wird.

Das dynamische Laden und Entladen von Implementierungen in Shared-Libraries sollte jedenfalls ein “Feature” im GATE Microservice Host werden. Jetzt weiß ich zumindest, dass wegen Alpine Linux das Thema Prozess-Isolation eine höhere Priorität bekommen wird … bzw. die Architektur beeinflussen wird.

Denn offenbar sind im verallgemeinerten Sinn ausschließlich nur Kindprozesse unter Linux dazu fähig eine Plugin- und “Plugout” Infrastruktur aufzubauen.

Innerlich bin ich jetzt enttäuscht darüber, dass Implementierungen einen so krassen Unterschied aufweisen können und sich vom dokumentierten Standard derart unterscheiden.

Naja … aber so ist das eben im Leben eines Entwicklers:

Man lernt mit Schmerzen zu leben.