Discussion :

[Stéphane le calme]

Glibc, la bibliothèque GNU C, passe en version 2.25
et apporte de nombreuses nouveautés fonctionnelles

Siddhesh Poyarekar a annoncé la disponibilité de la version 2.25 de la bibliothèque GNU C. Il a rappelé qu’elle est utilisée comme LA bibliothèque C sur les systèmes GNU, GNU/Linux ainsi que d’autres systèmes qui se servent de Linux comme noyau.

Parmi les nouveautés qui accompagnent cette version, Poyarekar a noté :

Le support de la macro __STDC_WANT_LIB_EXT2__, de ISO / IEC TR 24731-2: 2010, pour permettre des déclarations de fonctions depuis ce TR. Notez que toutes les fonctions de ce TR ne sont pas prises en charge par la bibliothèque GNU C.

Le support de la macro __STDC_WANT_IEC_60559_BFP_EXT__, de l'ISO / CEI TS 18661-1: 2014, pour permettre des déclarations de fonctions et de macros de cette TS. Notez que toutes les fonctionnalités de cette TS ne sont pas prises en charge par la bibliothèque GNU C.

Les sélections de macros _REENTRANT et _THREAD_SAFE sont désormais traitées comme des synonymes de compatibilité pour _POSIX_C_SOURCE = 199506L. Étant donné que la bibliothèque GNU C utilise par défaut une version beaucoup plus récente de POSIX, cela ne touchera que les programmes qui demandent spécifiquement un ancien mode de conformité. Par exemple, un programme compilé avec -std = c89 -D_REENTRANT verra un changement dans les déclarations visibles, mais un programme compilé uniquement avec -D_REENTRANT ou -std = c99 -D_POSIX_C_SOURCE = 200809L -D_REENTRANT, ne le sera pas.

L'inclusion de <sys / sysmacros.h> par <sys / types.h> est obsolète. Cela signifie que dans une future version, les macros "majeur", "mineur" et "Makedev" ne seront disponibles que depuis <sys / sysmacros.h>.

De nouvelles fonctionnalités <fenv.h> de TS 18661-1: 2014 sont ajoutées à libm : les fonctions fesetexs ept, fetestexceptflag, fegetmode et fesetmode, le type femode_t et les macros FE_DFL_MODE et FE_SNANS_ALWAYS_SIGNAL.

Les macros de type entier de TS 18661-1: 2014 sont ajoutés à <limits.h> : notamment CHAR_WIDTH, SCHAR_WIDTH, UCHAR_WIDTH, SHRT_WIDTH, USHRT_WIDTH, INT_WIDTH, UINT_WIDTH, LONG_WIDTH, ULONG_WIDTH, LLONG_esIDTH, ULLONG_WIDTH; Et à <stdint.h>: INT8_WIDTH, UINT8_WIDTH, INT16_WIDTH, UINT16_WIDTH, INT32_WIDTH, UINT32_WIDTH, INT64_WIDTH, UINT64_WIDTH, INT_LEAST8_WIDTH, UINT_LEAST8_WIDTH, INT_LEAST16_WIDTH, UINT_LEAST16_WIDTH, INT_LEAST32_WIDTH, UINT_LEAST32_WIDTH, INT_LEAST64_WIDTH, UINT_LEAST64_WIDTH, INT_FAST8_WIDTH, UINT_FAST8_WIDTH, INT_FAST16_WIDTH, UINT_FAST16_WIDTH, INT_FAST32_WIDTH, UINT_FAST32_WIDTH, INT_FAST64_WIDTH, UINT_FAST64_WIDTH, INTPTR_WIDTH, UINTPTR_WIDTH, INTMAX_WIDTH, UINTMAX_WIDTH, PTRDIFF_WIDTH, SIG_ATOMIC_WIDTH, SIZE_WIDTH, WCHAR_WIDTH, WINT_WIDTH.

Sur x86_64, lors de la compilation avec -mfpmath = 387 ou -mfpmath = sse + 387, les types float_t et double_t sont maintenant définis à long double au lieu de float et double. Ces options ne sont pas les valeurs par défaut et n’affectent pas l'ABI de toutes les bibliothèques qui font partie de la bibliothèque GNU C, mais elle peut affecter l'ABI des autres bibliothèques qui utilisent ces types dans leurs interfaces si elles sont compilées ou utilisées avec ces options.

Les fonctions malloc_get_state et malloc_set_state ont été supprimées. Les binaires déjà existants qui se lient dynamiquement à ces fonctions vont obtenir une implémentation cachée dans laquelle malloc_get_state va figurer. Selon Poyarekar, ces fonctions sont utilisées uniquement par GNU Emacs et ce changement ne va pas affecter négativement les exécutables Emacs déjà conçus.

Des améliorations ont aussi été apportées du côté de la sécurité.

télécharger glibc 2.25

Source : liste de diffusion GNU

[Gugelhupf]

A quand une implémentation du standard C11 threads.h ?

[Matt_Houston]

Je pense que les points suivants relèguent l'implémentation de cette interface dans la glibc à la saint glin-glin :

• threads.h et pthreads c'est bonnet blanc et blanc-bonnet sans compter qu'à peu près partout où la glibc est disponible, pthreads l'est aussi ;
• threads.h est optionnel au sein de la norme.

Il est également possible d'opter pour musl, qui elle implémente cette interface (ça ne doit pas être le point décisif, c'est un plus).

[Aurelien.Regat-Barrel]

Apparemment ils ont pas pu intégrer dans cette version une optimisation de malloc assez significative (20% de gain grâce à un cache au niveau de chaque thread):
https://sourceware.org/ml/libc-alpha.../msg00524.html

Ca sera pour la 2.26 à priori...

A quand une implémentation du standard C11 threads.h ?

Si c'est important pour toi, tu peux démarrer une contribution en ce sens !

[picodev]

A quand une implémentation du standard C11 threads.h ?

Tu peux passer à musl musl C11 conformance.
gcc la supporte depuis la série 6 : GCC 6 Changes (Linux).

[Gugelhupf]

@Matt_Houston, threads.h et pthread ce n'est pas blanc bonnet et bonnet blanc, pthread est l'implémentation Posix (qui fonctionne très bien sous Linux mais pas forcément ailleurs), threads.h est l'interface standard C. Pour avoir fait du GCC (MinGW) sous Windows, toutes les fonctionnalités ne sont pas implémentés (ex: inet_pton).

@Aurelien.Regat-Barrel, en effet, je pourrais (j'ai déjà une librairie crossplatform qui part en cet état d'esprit sens pour les sockets). Mais bon comme cela a été dit plus haut, musl et Pelles l'ont fait, donc je ne vois pas pourquoi GCC ne l'a pas toujours fait en 2017.

@picodev, je pense que cela fait référence à C++11 (qui lui implémente déjà une interface standardisé pour les threads).

[picodev]

….

@picodev, je pense que cela fait référence à C++11 (qui lui implémente déjà une interface standardisé pour les threads).

Non, il s'agit bien de C11 et non C++11. musl est une inplémentation de libc et non de libstdc++.

[Gugelhupf]

Bonjour,

Je me suis amusé à implémenter la lib C11 threads pour les environnements Unix et Windows (lien repo github).
Voici le post de contribution à la communauté GCC GNU : https://gcc.gnu.org/ml/gcc/2017-02/msg00082.html

A+