Cette version 2.11 est disponible pour ArchLinux, Linux From Scratch, Gentoo et Fedora 12. Alors qu'avant la glibc était gérée par CVS, cette version est la première à être publiée à partir du nouveau dépôt GIT. Par contre, le projet eglibc, variante de la glibc visant l'embarqué et utilisé dans Debian, continue à utiliser Subversion. Nouvelles fonctions
- execvpe() (commit) : exécuter un programme, similaire à execp(), mais permet de spécifier les variables d'environnement comme execve().
- pthread_sigqueue() (commit) : émettre un signal avec des données, similaire à sigqueue() mais pour un processus léger plutôt qu'un processus. Utilise le nouvel appel système rt_tgsigqueueinfo introduit dans Linux 2.6.31 par Thomas Gleixner.
- mkstemps() / mkstemps64() (commit) et mkostemps() / mkostemps64() (commit) : créer un fichier temporaire, similaires à mkstemp() / mkostemp() mais avec un suffixe.
Optimisations
- glibc 2.10 a introduit le type de symbole STT_GNU_IFUNC : il permet d'embarquer plusieurs versions d'une même fonction utilisant des jeux d'instructions différents (ex: i386 et SSE4.2). glibc 2.11 permet d'utiliser ce type de symbole sur PPC et avec les exécutables statiques.
- Justement, des versions optimisées pour x86_64 ont été écrites pour de nombreuses fonctions : strstr, strcasestr, memcmp, strcspn, strpbrk, strspn, strcpy, stpcpy, strncpy, strcmp (SSE2, SSE3, SSE4.2), strncmp (SSE2, SSE3, SSE4.2), strchr (SSE4.2), strrchr (SSE4.2), strlen et rawmemchr.
- Et pour x86 : strlen, strcspn, strspn, strpbrk, strstr, strcasestr.
- Les conversions iconv (jeux de caractères) ont été optimisées pour S390x.
- L'utilisation des variables conditionnelles avec des mutex PI (Priority Inheritance, héritage de priorité) est plus efficace grâce au support noyau de la remise en attente vers des futex PI. La documentation noyau, Futex Requeue PI, explique le problème et la solution implémentée. Le support NPTL a été ajouté pour x86-64.
Résolution de nom d'hôte (DNS)
- Ajout de la nouvelle option DNS « single-request-reopen » pour les résolutions DNS optimisées en environnement défectueux. Si deux requêtes depuis le même port ne sont pas gérées correctement, ferme la socket et en ouvre une nouvelle avant d'envoyer la 2e requête. Activer cette option dans /etc/resolv.conf évite que chaque processus ait besoin de redécouvrir la nécessité de l'activer.
- Une nouvelle option de résolution DNS a été introduite (commit) pour activer l'utilisation de DNSSEC : RES_USE_DNSSEC.
Divers
- Nouvelles locales : ps_AF (Pachtou) et my_MM (Birman).
- Une nouvelle version de la fonction longjmp() a été ajoutée : elle échoue si une stack frame non initialisée serait créée.
- Support des instructions FMA (Fused Multiply ADD) du jeu d'instructions AVX (Advanced Vector Extensions) sur x86_64.
- Support des instructions AVX (pour x86_64) pour l'audit dans l'éditeur de liens dynamique ld.so.
- Une nouvelle option pour les symboles a été introduite : STB_GNU_UNIQUE. Elle garantit que l'éditeur de liens dynamique utilisera toujours la même définition pour tous les symboles ayant le même nom et ce lien.
Aller plus loin
- Page d'accueil FSF officielle de la glibc (20 clics)
- GLIBC, the GNU C Library (site développeur) (17 clics)
- Wiki communautaire de la glibc (7 clics)
# AVX?
Posté par Narishma Jahar . Évalué à 3.
[^] # Re: AVX?
Posté par patrick_g (site web personnel) . Évalué à 6.
[^] # Re: AVX?
Posté par Aurélien Jarno (site web personnel) . Évalué à 6.
# Humm...
Posté par monde_de_merde . Évalué à 4.
En tant qu'end user de base, juste intéressé par sa petite personne, je me demande si cela va m'apporter quelque chose (en dehors du fait que je pourrai être birman ou pachtoune, il est vrai). On pourrai s'y attendre puisqu'après tout, la bibliothèque standard, est tellement à la base d'un système linux, qu'elle est partout finalement. Un changement (optimisation ?) à ce niveau pourrait avoir des conséquences sur l'ensemble du système (se dit-il avec son intellect limité par une vague compréhension de tout ça).
Merci néanmoins pour la nouvelle :)
[^] # Re: Humm...
Posté par JoeltheLion (site web personnel) . Évalué à 3.
D'ailleurs c'est énormément de travail, et on peut penser ce qu'on veut de M. Drepper, la glibc avance à grand pas!
[^] # Re: Humm...
Posté par Victor STINNER (site web personnel) . Évalué à 7.
Le support DNSSEC va améliorer la sécurité de DNS, ce qui va empêcher pas mal des attaques récentes voir futures (ex: le nom Dan Kaminsky vous dit quelque chose ?). Les serveurs racines vont d'ailleurs tous passer supporter DNSSEC d'ici 2010 (les domaines .se ou .org le supportent déjà).
http://www.bortzmeyer.org/signature-racine.html
Pour les instrutions AVX : ça permet de préparer l'arrivée des prochains processeurs AMD et Intel. Ils n'existent même pas qu'ils sont déjà supportés par Linux !
[^] # Re: Humm...
Posté par lasher . Évalué à 4.
[^] # Re: Humm...
Posté par Antoine . Évalué à 5.
Sauf Python et tous les langages ayant une représentation des chaînes de caractères pas totalement pourrie.
Optimiser strlen(), c'est quand même le symptôme assez triste que les performances du système peuvent être dépendantes de choix de conception dommageables. Les calculs les plus rapides sont ceux qu'on n'a pas besoin d'effectuer.
Je n'ai pas trop compris ces histoires de « variables conditionnelles avec des mutex PI », mais je pense qu'au final ça va améliorer la réactivité des processus utilisant beaucoup de processus légers
Ça dépend, je pense que la plupart des gens n'utilisent pas les options de priorité des mutex POSIX (que je ne connais pas d'ailleurs, je sais juste que ça existe). Ceci dit optimiser les variables de conditions c'est sympa, ça va peut-être rendre le nouveau GIL encore plus efficace ;)
[^] # Re: Humm...
Posté par Kerro . Évalué à 4.
Existe-t-il une bibliothèque de substitution ?
A tout hasard, qui préfixe les chaînes avec leur longueur.
[^] # Re: Humm...
Posté par Victor STINNER (site web personnel) . Évalué à 7.
Non, il en existe plusieurs : http://www.and.org/vstr/comparison
[^] # Re: Humm...
Posté par Victor STINNER (site web personnel) . Évalué à 10.
> antoine: Sauf Python et tous les langages ayant une représentation
> antoine: des chaînes de caractères pas totalement pourrie.
Ah bon ? Tiens, regardons à quel point strlen() n'est pas utilisé dans CPython :
$ grep strlen $(find -name "*.c")|wc -l340
avec des occurences dans des fichiers assez courants : Parser/{grammar,parsetok,tokenizer}.c, Objects/{bytearray,class,complex,file,float,int,long,string,type,unicode}object.c, Python/{ast,bltmodule,codecs,compile,import,pythonrun,traceback}.c, et j'en passe (la liste est longue).
[^] # Re: Humm...
Posté par Antoine . Évalué à 2.
Tu es assez bien placé pour savoir que dans Python les chaînes de caractères ne sont pas représentées à la manière C en interne, sauf rares exceptions.
[^] # Re: Humm...
Posté par beagf (site web personnel) . Évalué à 8.
Le C est un langage bas niveau qui te laisse le choix de la manière dont tu code tes chaines de caractère, rien ne t'empeche d'utiliser une structure telle que :
struct string {size_t length;
char data[];
}
qui est du C tout aussi standard que les chaine terminé par nul. Et tu trouvera plein de bibliothèques qui te le proposent avec beaucoup de variantes dans les représentations.
C'est toute la puissance du C, tu n'est pas limité par un modèle, tu fais ce que tu veux. C'est aussi là, sa plus grande faiblesse, car, à donner trop de libertées, les gens font n'importe quoi.
Si ton programme nécessite d'avoir souvent accès à la longueur de la chaine, une représentation qui la concerve de manière explicite est parfaitement adapté. Mais si ton programme ce contente de faire des parcours de chaine relativement petites mais en grand nombre, le marqueur de fin est plus adapté, car le surcout est réduit.
Pour te paraphraser, la mémoire la moins gachée est celle qui est vraiment utilisée, donc si tu n'as que très rarrement besoin de la longueur d'une chaine, autant ne pas la stocker et la calculer juste une fois de temps en temps.
Le principal soucis est le design de la lib standard du C, elle à le cul entre deux chaise :
- d'un côté ils l'on voulut minimaliste et comptait sur tous les bibliothèques disponibles autour pour fournir l'éssentiel ;
- de l'autre, ils ont quand même mits dedans d'un fonctions qui sont trivialement codable en C pour gérer les chaines d'une manière qui n'est corecte que dans certains cas.
Ça à deux conséquences :
- puisque les bases sont disponibles, la convention adoptée par ces bases est utilisée trop souvent, et n'importe comment, plutot que d'aller chercher une bonne lib adaptée au programme ;
- puisque seule les bases sont disponibles, les programmeur recodent à chaque fois pleins de fonctions manquantes et multiplient les risques de bugs.
[^] # Re: Humm...
Posté par Thomas Douillard . Évalué à 4.
Du coup, pour des raisons "d'interopérabilité" la plupart des autres bibilothèques ont fait pareil, ça évite d'avoir à caster des chaînes dans des représentations incompatibles, ce qui est pas top non plus et chiant si tu fait interagir plusieurs bibliothèques.
[^] # Re: Humm...
Posté par beagf (site web personnel) . Évalué à 5.
L'idée de base de bibliothèque standard était d'abstraire les quelques éléments spécifique au système qui ne font pas partit du langage, donc le minimum aurait suffit. Mais ils on quand même ajouté un peu plus histoire que l'on ne se retrouve pas trop nus. Résultat, il n'y a pas suffisament de fonction pour que l'on puisse ce passer de librairies mais il y en trop pour que ce ne soit vraiment qu'une couche bas niveau qui est à peu près tout le temps caché au programmeur.
Au final, on se retrouve dans une situation ou il y a suffisament de fonction pour que les programmeurs préfèrent recoder le peu qu'il manque et faire avec les problème de la stdlib, et donc aucune lib un peu plus touffue n'a réussie à s'imposer. Les deux son liés :
- pas de lib de bonne qualitée et répandue --> on fait avec ce qu'il y a et on recode le reste
- on fait avec et on recode --> les libs qui éxiste n'attirent pas assez de monde et se répandent peu
Le problème ce situe à l'origine et à mon avis on ne pourra rien y changer. Je suis le premier à faire avec la stdlib et à recoder pour la simple raison que actuellement, écrire un code en ansi/C est ce qui ce fait de plus portable. La quasi totalités des système éxistant disposent d'un compilateur ansi/C.
Le problème c'est que à peu près toutes les libs éxistante pas trop pourries reposent sur des extention du compilateur ou des éléments spécifiques à la platforme, donc on perd la portabilité. Mon choix est vite fait, j'ai ma petite collection perso de fonction et structure de données, et je repique dedans ce dont j'ai besoin.
Si seulement ils avait choisit de faire une lib complète ou pas de lib du tout au moment de la standardisation...
[^] # Re: Humm...
Posté par Thomas Douillard . Évalué à 4.
Qt c'est du C++ et a une API riche, ça ne passe pas si mal question portabilité.
En utilisant un langage interprété le problème de portabilité est aussi différent plus ou moins contourné, etc.
Je rajoute que le problème de la portabilité a aussi évolué depuis l'époque ou on parlait de portabilité entre Unices.
[^] # Re: Humm...
Posté par beagf (site web personnel) . Évalué à 3.
Pour moi, il y a deux niveaux de portabilité. Le premier, celui auquel on pence le plus souvent consiste à dire qu'un programme est portable si on peut le faire tourner sur pas mal de platformes courantes que le commun des mortels utilise courrament et consciament. Donc en gros sur des ordinateurs au sens madame michu du terme avec un OS au sens au moins 1% de geek en a déjà entendu le nom.
Dans ce cas là, java est portable tout comme du C++ et je pense Qt ou la GLib. De même pas mal de langage de scripts vont entrer dans cette catégorie.
Le deuxième, celui auquel je faisait référence ici, concerne un bien plus grand nombre de machine et d'OS puisqu'il englobe tous les systèmes capable d'exécuter un programme, même les petits micro controleur ou autre. Ça concerne peut-être moins de monde ici, mais de manière globale ça concerne énormément de monde...
Dans ce cas la être portable ça eut dire être compilable sur un max de platformes très hétérogènes. Et pour ces platformes, en général un compilateur ansi/C est la première chose qui soit disponible pour compiler du code en dehors de l'assembleur ou d'un langage spécifique à la platforme.
Donc, la grande majorité du temps, un code portable dans ce sens c'est un code en ansi/C et la seule chose que ce code peut utiliser c'est des bibliothèques elles-aussi en ansi/C.
C'est ça qui à poussé les auteurs du langage Lua, par exemple, à le coder en ansi/C pur. Ils ont conçu le langage pour leur besoin à la base et les sytsème sur lesquels il était utilisé était très hétérogène, il n'avait donc pas trop le choix.
Le revert de la médaille c'est que c'est aussi un langage relativement pauvre en librairies fournies de base, beaucoup de chose sont soit impossible en c pur, soit tros complexe à réimplémenter et la aussi laissées au soins de lib externe qui ne sont plus forcément portable.
À mon avis il y a surtout de moins en moins de nouveaux projets qui commencent en C. Déja pour faire une interface graphique t'es obligé de rajouter une bibliothèque, genre glib ou Qt.
beaucoup de projets n'ont pas besoin d'interface graphique et ce sont en plus ceux qui sont le plus souvent codé en C...
Beaucoup de programme sont d'ailleur codé de cette manière, un coeur qui fait le gros du boulot codé en C ou dans un autre langage suffisament portable pour la tâche en utilisant le moins de lib non portables possible. (pas toujours évident)
Et à côter une interface graphique qui appelle l'autre code portable sous la forme d'un programme ou d'une lib.
Coder une interface graphique en C n'a pour moi que peu d'interet car il y a des langage ou c'est beaucoup plus simple, bien moins sujet au bugs et vu que l'interface graphique impose déjà des contraintes sur la portabilité autant faire au plus simple.
[^] # Re: Humm...
Posté par Antoine . Évalué à 3.
A partir du moment où une convention de représentation est choisie, il faut aussi générer et traiter les chaînes représentées selon cette convention, donc des fonctions de gestion adaptées. Fort logiquement, la stdlib a donc fourni des fonctions de gestion adaptées à la convention utilisée par les différents appels système.
L'idée de base de bibliothèque standard était d'abstraire les quelques éléments spécifique au système qui ne font pas partit du langage, donc le minimum aurait suffit.
Cela me semble bizarre comme explication. Le C a été conçu pour écrire Unix, la motivation principale de la stdlib était donc probablement de faciliter l'écriture des outils système.
(le C n'a pas été un exercice académique de création d'un langage idéal ou désincarné comme l'ont été d'autres langages)
[^] # Re: Humm...
Posté par beagf (site web personnel) . Évalué à 2.
Si tu te contente de faire une bibliothèque minimaliste qui ne propose que le minimum pour pouvoir travailer avec l'OS, tu n'en a pas besoin. L'idée c'est que les fondation c'est un langage qui permet d'exprimer tout ce qui est calculatoire, et une bibliothèque qui abstrait un minimum les appels système afin que ce soit portable.
Avec ça tu as une base minimaliste mais relativement portable ; et la dessus tu construit une vrai biliotheque de plus haut niveau.
Dans cette bibliothèque tu peut très bien fournir deux ou trois conventions diffrents pour les chaine de caractères si tu veux que l'utilisateur puisse choisir et aucun d'elles n'est forcée d'utiliser la convention du système qui est en dessous. Tu le dis toi-même dans un message au dessus, en interne, la représentation des chaines en python n'a rien à voir avec des chaine terminées par 0.
Cela me semble bizarre comme explication. Le C a été conçu pour écrire Unix, la motivation principale de la stdlib était donc probablement de faciliter l'écriture des outils système.
(le C n'a pas été un exercice académique de création d'un langage idéal ou désincarné comme l'ont été d'autres langages)
Les origines du C sont bien entendu liés à la création d'Unix, mais le C à pas mal évolué et est passé par plusieurs standardisations. Actuellement on en est au C99, mais le standard le plus connu reste celui que l'on appelle l'ansi/C qui date de 89. Et ces version du C sont différentes sur bien des points du C d'origine.
Au niveau du langage en lui-même, le C89 avait éssayer de rester le plus compatible possible avec les versions les plus utilisée à l'époque (qui était déjà bien différentes des premières version du C) en gardant certains structures mais en les indiquant comme non recomandée. Les prototypes des fonctions en son un exemple typique.
Pour la librairie par contre, si certaines chose on été gardé et si certaines convention sont les même, il y a eu énormément de changement, notament pour des raison de portabilité. Ils ont éssayer de trouver un dénominateur commun à toutes les librairies qui éxistait alors et normalement ils devaient faire les choses proprement... Le soucis est qu'ils ont préféré faire des compromis plutôt que d'aller au font des chose en la nétoyant au maximum quitte à standardiser une bibliothèque plus haut niveau à côté.
[^] # Re: Humm...
Posté par Antoine . Évalué à 3.
Non, ça c'est ta vision idyllique du langage C. En pratique le langage n'exprime pas tout ce qui est calculatoire, et c'est bien pour ça qu'on a notamment des fonctions de manipulation de chaînes (manipuler des chaînes, c'est aussi du calcul) dans la bibliothèque standard.
Les origines du C sont bien entendu liés à la création d'Unix, mais le C à pas mal évolué et est passé par plusieurs standardisations
Oui, enfin c'est hors-sujet là. La représentation des chaînes était là dès le C original, elle ne date pas de la standardisation, et elle n'a pas changé avec cette dernière.
Dans cette bibliothèque tu peut très bien fournir deux ou trois conventions diffrents pour les chaine de caractères si tu veux que l'utilisateur puisse choisir et aucun d'elles n'est forcée d'utiliser la convention du système qui est en dessous
On a bien compris.
[^] # Re: Humm...
Posté par beagf (site web personnel) . Évalué à 1.
J'ai un peu de mal à comprendre ce que tu dis là. Tu dis que le langage n'exprime pas tout ce qui est calculatoire et que donc ils ont mit dans la stdlib les fonctions de manipulations de chaines pour palier à ce problème.
Le truc c'est que, comme tu le dis, la manipulation de chaine c'est purement calculatoire, et je te met au défi de me trouver une seule fonction de manipulation de chaine dans la stdlib qui ne peut pas être codé en C pure sans la stdlib.
Sur les 22 fonctions définies par string.h dans le standard, les sul soucis que tu vas avoir sont :
- strcoll et strxfrm qui sont liée à la gestion des locales, mais avec les primitive définie dans locale.h qui contient des fonction plus bas-niveau il n'y a plus de problèmes.
- strerror qui est une fonction systeme plus qu'une fonction de manipulation de chaine puisqu'elle sert à traduire un code d'erreur système en un message d'erreur.
Toutes les autres sont triviales à coder en C pur et j'irais même plus loin, presque toutes les implémentations de la stdlib en on une version en C pur en plus d'éventuelles version en assembleur optimisé car c'est bien plus portable.
Seule les vrai fonctions non calculatoire qui sont des appels systèmes ne peuvent être codée en C pure et nécéssite un petit bout d'assembleur. Et celles là mérittent vraiment leur place dans une lib bas-niveau.
Oui, enfin c'est hors-sujet là. La représentation des chaînes était là dès le C original, elle ne date pas de la standardisation, et elle n'a pas changé avec cette dernière.
Ce n'est pas hors-sujet du tout. Ce qui est utiliser actuellement c'est la version standard et pas la version de base. La norme à changé beaucoup de choses et les gens ce sont adaptés, à part dans de vieux codes on ne voit plus les anciennes version des prototypes de fonctions.
Donc si la norme à pus changer ce genre de choses elle aurait très bien pus changer la stdlib afin que celle-ci n'incite plus les dev à utiliser cette convention.
Il faut bien voir que cete convention c'est imposée et perdure encore aujourd'hui par ce que c'est la manière la plus simple de gérer les chaines de caractère de façon portable car si tu veux une autre gestion il te faut soit tout recoder à la main, soit utiliser une lib qui n'a pas pus se déveloper suffisament et être largement diffuser car une solution simple et pas trop muvaise éxistait.
Le comité de normalisation était la justement pour virer toutes les merdes des différentes versions du C, et s'il ont réussit sur certains points, ce n'est pas le cas pour la stdlib ou ils en ont encore trop laissé.
[^] # Re: Humm...
Posté par Antoine . Évalué à 3.
Ben oui, C est Turing-complete, merci du renseignement.
La norme à changé beaucoup de choses et les gens ce sont adaptés,
Heu, tu es bouché ou quoi ?
On parle de la gestion de chaînes de caractères et la norme n'a pas changé cet aspect du langage. Y a un truc compliqué à comprendre ?
presque toutes les implémentations de la stdlib en on une version en C pur en plus d'éventuelles version en assembleur optimisé car c'est bien plus portable.
Ah oui, optimiser strlen() en assembleur pour que le O(n) ressemble de loin à du O(1). T'as remarqué que c'était précisément le sujet de la discussion ? :-)
[^] # Re: Humm...
Posté par beagf (site web personnel) . Évalué à 1.
Ben oui, C est Turing-complete, merci du renseignement.
On tourne en rond, c'est le fait que le C soit Turing-complet qui fait que la gstion des chaines n'a rien à faire dans la stdlib. Par contre les primitives d'ouverture de fichiers ou de gestion des signaux par exemple, que le C soit Turing-Complet ou pas, tu ne peut pas le faire sans l'aide d'une bibliothèque bas-niveau.
Ce sont des primitives qui sont la pour abstraire le système, qui sont indispensable et qui on leur place dans la stdlib, au contraire de la gestion des chaines.
On parle de la gestion de chaînes de caractères et la norme n'a pas changé cet aspect du langage. Y a un truc compliqué à comprendre ?
Relis ce que j'ai écrit et tu verra que je n'ai jamais dis que la norme avais changé la gestion des chaine de caractères et c'est bien ce que je lui reproche et que je répette depuis plusieurs commentaires.
La norme pouvais le changer tout comme et à changé d'autres choses tout aussi importantes. Et le truc c'est que les gens on adopté la norme, et on changer leurs habitudes pour tout ce que la norme avait changer, donc, on en serait pas la si la norme avait changé la gestion des caractères.
Ah oui, optimiser strlen() en assembleur pour que le O(n) ressemble de loin à du O(1). T'as remarqué que c'était précisément le sujet de la discussion ? :-)
Et ? Ma remarque était juste la pour dire que ces fonctions ne sont pas des primitives bas-niveau mais déjà des fonctions plus haut niveau, la preuve étant que l'on trouve partout des versions en C avant d'en avoir des version en assembleur.
À moins que ta remarque ne soit pour me convaincre que les chaines terminées par 0 c'est nul car il faut des optimisations de fou pour avoir des perfs qui ressemblent vaguement à une autre implémentation. Parce que si c'est ça, je désespère que tu n'ais toujours pas compris que je suis d'accord là-dessus.
[^] # Re: Humm...
Posté par Antoine . Évalué à 3.
Heu... on est au 21ème siècle, c'est un peu ridicule de considérer un langage sans tenir compte de sa bibliothèque standard. On peut bien sûr réécrire un runtime différent depuis zéro, mais ce n'est certainement pas l'usage favorisé par l'écosystème.
C'est aussi là, sa plus grande faiblesse, car, à donner trop de libertées, les gens font n'importe quoi.
Là le problème ce n'est pas que les gens (en général) font n'importe quoi, c'est que c'est la bibliothèque standard qui fait n'importe quoi depuis le début et qui encourage le reste des développeurs à s'appuyer là-dessus (ainsi que sur les autres couches optionnelles qui sont venues s'ajouter à la dite bibliothèque standard).
[^] # Re: Humm...
Posté par beagf (site web personnel) . Évalué à 2.
Le probème ici c'est que justement la bibliothèque standard du C n'est pas vraiment ce qu'on appelle un runtime au 21 siècle. Elle propose à peu près rien comme fonctions par rapport à ce que l'on attend maintenant d'un runtime.
Donc le runtime du C c'est plus d'autre bibliothèques haut niveau et bien plus complètes. Donc dans ce cas la stdlib c'est juste une couche très bas niveau pour astraire le minimum du système et donc il y a dedans beaucoup de fonctions qui n'on rien à y faire.
Elle à donc bien le cul entre de chaise, pas vraiment un runtime et pas vraiment une bibliothèque minimaliste.
Là le problème ce n'est pas que les gens (en général) font n'importe quoi, c'est que c'est la bibliothèque standard qui fait n'importe quoi depuis le début et qui encourage le reste des développeurs à s'appuyer là-dessus (ainsi que sur les autres couches optionnelles qui sont venues s'ajouter à la dite bibliothèque standard).
On est d'accord sur le fait que la stdlib fait n'importe quoi depuis le début ; par contre je ne suis pas sur que l'on soit d'accord sur le n'importe quoi en question ;-)
Pour moi il n'y a aucun problème pour qu'elle gère les chaines de caractère en les terminant pas un zero (revenons au débat initial) par contre, il y a un gros problème quand elle commence à proposer des fonctions qui ne devrait pas être de son ressort et qui utilisent cette convention aussi alors que de manière générale c'est rarement la meilleure.
Mais il y a de la faute des utilisateurs eux aussi. Tout le monde sait qu'il y a beaucoup de cas ou ce n'est pas optimal, qu'il y a moyen de faire mieux et même que des libs existent pour faire mieux. Mais une grosse majorité des utilisateurs continue de suivre cette convention.
[^] # Re: Humm...
Posté par lasher . Évalué à 2.
Ça franchement ce n'est pas grave, vu le nombre de bibliothèques externes de qualité qui ont été produites depuis. Ensuite, l'intérêt de la libC, c'est que le compilateur a le droit de considérer que toutes ses fonctions sont magiques. Par exemple, un bête code du genre :
for (i=0;i<N;++i) dst[i] = src[i];peut être remplacé légalement par le compilateur en
memcpy(dst,src,N*sizeof(*dst));. Bref, les fonctions de la libc ne sont pas de simples fonctions, elles font partie de la norme et peuvent être manipulées de façon très bizarre par le compilateur s'il décide que ça en vaut la peine ...Donc les fonctions de manipulation de chaîne n'y échappent pas, et si un compilateur assez futé [1] s'aperçoit qu'il peut simplifier du code de manip de chaîne fait avec les fonctions str*, il ne va pas se gêner pour le faire.
[1] Ce n'est pas toujours évident cependant, bien entendu. Et je ne suis pas certain que les compilos fassent grand chose en général.
[^] # Re: Humm...
Posté par beagf (site web personnel) . Évalué à 2.
Et, pour ce qui est des bibliothèques externes, tu en as éffectivement de grandes quantité, et certaines de très bonnes qualité. Le problème c'est qu'elle ne sont pas si répandue que ça... La stdlib, tu peut être sur qu'elle disponible avec à peu près tous les compilateurs, ces bibliothèque c'est beaucoup moins sur.
C'est un cercle vicieux : la stdlib est disponible partout avec les bases ce qui n'est pas le cas des lib, donc on utilise la stdlib. Mais comme on utilise principalement la stdlib, ça vaut pas le coup de porter ces bibliothèque sur tous les systèmes...
[^] # Re: Humm...
Posté par lasher . Évalué à 2.
Oui et non. Là j'ai donné un exemple de code où le compilateur finit par appeler du code déjà optimisé (ici, memcpy). Mais par exemple, il est possible d'imaginer que le compilateur reconnaît des patterns déjà bien définis (par ex, strlen(toto), strncat(dst,toto,...), etc), et que du coup le compilateur joue un peu avec tous ces paramètres là où il ne le ferait pas d'habitude, car les fonctions de la libc sont magiques. Donc même si en toute logique, « on ne sait pas » ce qui peut se passer dans une fonction du point de vue du compilateur, dans le cas des fonctions de la libc, ce n'est pas le cas, et le compilo peut réellement faire des choses bizarres/intelligentes (suivant le point de vue).
Concernant la disponibilité des bibliothèques externes, je ne suis pas d'accord. la glibc par exemple fournit énormément de fonctions en plus de ce que propose la libc-tout-court. GTK est portée à peu près partout. Après tu peux me dire que ces bibliothèques ne sont pas d'assez bonne qualité pour toi (rapport empreinte mémoire/performance, par exemple), mais c'est un autre débat. Idem pour SDL.
[^] # Re: Humm...
Posté par beagf (site web personnel) . Évalué à 2.
J'ai expliqué ce qu'est la portabilité dans un message plus haut. Le C n'est pas portable au sens ou la majorité des gens l'entend, c'est-à-dire qu'il tourne sur la majorité des combinaison d'OS et de hardware que l'on trouve chez la plupart des gens ou même dans sur des serveur de calcul, mais du code en C pure pourra aussi compiler pour à peu près toutes les architectures et OS existants.
Un compilateur C est en général une des premières choses portée sur un nouvell OS ou un nouvelle architecture.
Dans ce contexte, la GLibc est déjà moins portable tout comme GTK ou la SDL. Ces lib sont faites pour être bien plus haut niveau que ce que l'on attendrait d'un bon runtime en C qui reste portable.
Ma vision des couches de bibliothèques idéale du C serait plus la suivante. Une stdlib très basique qui ne contient que ce qui concerne la communication basique avec le système. Ensuite une bibliothèque qui n'utilise que le langage et la stdlib et qui fournit une couche plus haut niveau prenant en charge notament la gestion des chaines de caractères ou les entrées/sorties formatées.
Et au dessus de ça, des bibliothèques plus complexes qui font intervenir d'autres éléments du système non portables.
[^] # Re: Humm...
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Si, du sucre syntaxique : les "chaînes" entre guillemets.
[^] # Re: Humm...
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
C'est toute la faiblesse du C, personne n'est au courant qu'il existe des alternatives plus efficaces dans la plupart des cas…
Je fais encore ma défense des langages de haut niveau, mais des trucs cons comme remplacer des strings par des ropes personne ne le fait, alors que le gain (et la sécurité) sont là dans au moins la moitié des logiciels pondus en C.
Même Pascal avait des chaines de longueur préfixée…
[^] # Re: Humm...
Posté par lasher . Évalué à 2.
Préfixées oui, mais la taille de l'entier était d'un octet. Super pratique pour des chaînes trèèèèèèèèès longues. Cela dit, je suis d'accord avec toi, faire un bête
typedef struct string_s { char *str; unsigned len; } string_t;c'est quand même pas bien compliqué.
[^] # Re: Humm...
Posté par beagf (site web personnel) . Évalué à 2.
Je fais encore ma défense des langages de haut niveau, mais des trucs cons comme remplacer des strings par des ropes personne ne le fait, alors que le gain (et la sécurité) sont là dans au moins la moitié des logiciels pondus en C.
Le soucis c'est que tu as :
- un gain en perf : ce n'est pas toujours intéressant, il y a beaucoup de code ou la manipulations des chaines représente un pouillème du temps total ;
- un gain en sécurité : celui-ci est indéniable ;
- une dépendance de plus : donc des galères suppléméentaire quand tu déplois ton application ;
- une perte en portabilité : car la plupart de ces libs ne sont pas vraiment portable. Il n'y a pas besoin d'assembleur pour ne pas être portable, beaucoup d'entre elles suppose que les int sont sur 32bit ou bien en little-endian.
Donc dans beaucoup de cas, les gens trouvent que ça ne vaut pas le coup. Il n'y aurrait rien de base, les gens utiliserais forcement une lib, et celle-ci aurait surement fait plus d'éffort pour la simplicité et la portabilité.
Préfixées oui, mais la taille de l'entier était d'un octet. Super pratique pour des chaînes trèèèèèèèèès longues. Cela dit, je suis d'accord avec toi, faire un bête
typedef struct string_s { char *str; unsigned len; } string_t;Et pourtant ça peut êtrela pire des solutions... Si tes chaines sont toutes très petites le surcout en mémoire est important. Il suffit de regarder les chiffres sur la page ttp://www.and.org/ustr/ pour s'en convaincre. (très bonne lib soit dit en passant)
Le truc surtout c'est que recoder soit même une gestion des chaine c'est souvent s'exposer à encore plus de problèmes.
[^] # Re: Humm...
Posté par Vincent Danjean . Évalué à 2.
Ça dépend, je pense que la plupart des gens n'utilisent pas les options de priorité des mutex POSIX
Les histoires de « variables conditionnelles avec des mutex PI » ne vont pas améliorer les programmes avec beaucoup de threads mais ils vont améliorer les programmes qui utilisent à la fois des threads et des priorités. L'exemple le plus classique est jack (le système de son). Mais je pense que, maintenant que ces fonctionnalités (PI) sont dispo et vraiment utilisables (ce n'a pas été le cas jusqu'à très récemment), on risque de voir plus de programmes les utiliser et en profiter. Les programmes cibles sont ceux qui ont des tâches prioritaires à faire (maintenir une cadence d'affichage, de transfert, ...) ainsi que d'autres tâches moins prioritaires (gérer une interface graphique, ...)
[^] # Re: Humm...
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.