Il était une fois, dans l'antre des laboratoires Bell, alors appelés Bell Telephone Laboratories, la création d'un langage. Nous sommes en 1972 et deux petits gars, Dennis Ritchie, 31 ans et Ken Thompson, 29 ans, décident que les langages de l'époque ne conviennent pas pour le système d'exploitation qu'ils participent à construire, un certain OS nommé UNIX. Ainsi naquit le langage C, il y a 50 ans.
Sa documentation, symbolisée par le livre The C programming language, n'est parue qu'en 1978 mais la qualité reconnue de cette documentation a certainement participé à l'adoption du langage.
50 ans après, l'influence qu'a eu ce langage est aussi immense que difficile à mesurer. Si certains tentent de mesurer la popularité d'un langage comme l'index TIOBE, et que les résultats sont variables, tous s'accordent à placer le C parmi les langages les plus utilisés.
Bon anniversaire à toi ô langage C. Il ne me serait pas possible d'énumérer toutes tes qualités, cela serait trop long mais je te souhaite de continuer encore à me ravir. Notre douce union s'est faite bien après ta naissance mais ta constance rend les d-ifficultés charmantes. Tu es formidable !
# C'est pas faux
Posté par Benoît Sibaud (site web personnel) . Évalué à 10. Dernière modification le 28 février 2022 à 13:03.
automatiquement et structurellement, quoique de façon non restrictive, apprécions ce rappel et cette mise au po int : n'oublions jamais les apports du C, même l'été en short dans ton break ou en rando au milieu des statices, rappelles-toi que ce n'est pas un langage de zi goto ou même volatile. Je double la mise, l'oc case était trop belle, de rappeler que le C est une externalité positive de l'informatique.
(et je souhaite bon courage au suivant pour caser
defaultelsefloatinlineregisterreturnsignedsizeofswitchtypedefunsignedvoidwhileen français)[^] # Re: C'est pas faux
Posté par Toufou (site web personnel) . Évalué à 10.
Même s'il fait des fautes, elle se démène la communauté, et la flotte aura coulé sous les ponts, la classification (in Linne veritas) restera la même : le C reste au top. Régis, terminus : la roue tourne mais malgré les signes édifiants d'obsolescence, le C saille offensivement sur les stats, sa fumée et ses suies te chavirent, quelque soit les types de facilité que tu aies avec les autres langages.
Un signe de voie de garage ? Voili voilà : défi capillotracté relevé!
/me va prendre un aspro :o)
# Un langage qui avance, tranquillement, à son rythme
Posté par Babelouest (site web personnel) . Évalué à 10.
Le langage C est à la base standardisé par l'ANSI.
Depuis la première version mainstream du standard, la C89 (en 1989), d'autres versions lui ont succédé: C90, C95, C99, C11 et plus récemment C17.
Actuellement, la prochaine version est en cours de rédaction, la C2x qui sera probablement la C23.
La plupart du temps, les nouvelles versions du standard ne changent rien de fondamental, mais ajoutent des précisions, ou normalisent certaines façons de faire qui existent par ailleurs.
Par exemple le C23 va probablement inclure dans le standard les fonctions comme
strdupstrndupoumemcpy, ajouter les macros#elifdefet#elifndef, ou encore permettre d'initialiser à 0 une structure avec{}:J'imagine déjà les autres langages regarder ça et dire "Meh", mais moi je trouve ca cool de voir ce langage continuer son chemin à son rythme, sans écouter les railleries de ce qui ne le connaissent pas, ni dénigrer les autres langage.
Longue vie au C!
[^] # Re: Un langage qui avance, tranquillement, à son rythme
Posté par Maclag . Évalué à 3.
"Meh"
Comme ça, c'est fait!
Et pour moi c'est encore plus facile parce que je ne connais pas le C outre les cours obligatoires quand j'étais étudiant il y a plus de 20ans.
---------> [ ]
# Survivor
Posté par David Delassus (site web personnel) . Évalué à 10.
50 ans.
50 ans que chaque année un nouveau langage apparaît pour l'enterrer.
50 ans qu'il survit. Nay, que dis-je, 50 ans qu'il est en vie!
Un demi siècle, et toujours aucun signe de la retraite.
https://link-society.com - https://kubirds.com
[^] # Re: Survivor
Posté par groumly . Évalué à 1.
Le C à quand même perdu énormément d’attrait ces 30 dernières années.
Après 30 ans, Java/C++/.Net/python/ruby/JavaScript/swift/objc/kotlin ont finis par le repousser dans les 2 seuls domaines où il perdure, à savoir la programmation très bas niveau (kernel/drivers) et l’embarqué où le hardware est digne des années 80, et nécessite de grosses optimisations pour pouvoir exister.
Et même dans l’embarqué, il reste beaucoup de scénarios ou d’autres langages sont plus adaptés.
L’essentiel des outils unix, par exemple, reste en c parce que ça fait une montagne de code à porter. Mais si tu devais réécrire sudo ou autre outil de ce style, je suis pas convaincu que le C serait le language le plus adapté.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Survivor
Posté par gUI (Mastodon) . Évalué à 10. Dernière modification le 28 février 2022 à 18:39.
Je ne suis pas certain que ces langages aient "repoussé" le C. Le C est resté dans les domaines d'applications qui existaient avant ces langages. Ces langages sont arrivés pour combler de nouveaux besoins, pas pour remplacer le C.
C'est pas le hardware qui est digne des années 80, c'est le logiciel (et il n'y a rien de péjoratif à ça, c'est mon métier).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Survivor
Posté par barmic 🦦 . Évalué à 3.
Pas que loin de là. Il y a pleins de logiciels de bureau écrit en C gimp par exemple. Aujourd'hui je n'ai pas l'impression que c'est le langage de prédilection pour ce genre de logiciels.
Ce qui n'a pas était dit plus haut c'est que le C est la lingua franca des langages de programmation et bien des bibliothèques natives même si elles sont implémentées dans d'autres langages offrent une API C. Il n'y a pas d'autres raisons à ça que son statut. C'est très bien parce que ça signifie que la fragmentation une machine vient avec son langage n'a pas tenu, mais c'est aussi un nivellement.
Ce qui est dommage avec le C c'est juste la gestion de la mémoire très difficile et sa propension a permettre les buffer overflow par exemple.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Survivor
Posté par David Delassus (site web personnel) . Évalué à 10.
Encore cet argument…
C'est quand même dommage, l'assembleur il y a pas de gestion de mémoire non plus et pourtant 100% des langages compilés (Rust inclut) target ce langage.
Le langage C est un langage bas niveau, il te donne des armes puissantes et un contrôle total, pour que tu puisse optimiser au maximum et à tout les niveaux. Si tu choisis de te tirer une balle dans le pied, libre à toi, il est pas là pour te prendre par la main.
Quand tu fais un logiciel dans le langage hype X, tu utilises des tests unitaires, de l'analyse statique de code, et bien d'autres outils pour t'assurer de la qualité du code. Le C n'a pas attendu 50 ans pour avoir de tels outils dans son écosystème. Dans les années 80 ces outils existaient déjà. Et ils ont très certainement été l'inspiration pour les compilateurs d'aujourd'hui.
Bonjour les oeillères.
Oui, ce langage ne doit son succès qu'au fait que certaines libs offrent une API C.
Non effectivement, aujourd'hui la hype c'est TypeScript + React + Electron, et ainsi tu ouvres un chrome par application (cc Slack, Teams, Atom, VS Code, Lens, Spotify, …). Quel progrès, j'ai 24Go de RAM, 85% utilisés.
https://link-society.com - https://kubirds.com
[^] # Re: Survivor
Posté par barmic 🦦 . Évalué à 4.
Tu sors des poncifs.
Quand je parle de difficultés à gérer la mémoire c'est très simple à vérifier tout outillage qui existe il ne se passe pas plus de 3 ou 4 mois sans de nouvelles cve pointant des gestions de mémoires problématiques.
Quant à la question de l'assembleur elle n'a pas de sens. On parle entre langage turing complet, tu peux compiler les uns vers les autres. Mais si tu as prouvé certaines propriétés dans un, elles seront maintenues à travers ta compilation. Je n'ai pas dit qu'il est impossible de faire un programme C dénué de bug de mémoire, mais sa sémantique ne permet pas de s'en assurer.
Je ne vois pas comment on peut correctement utiliser un langage sans accepter de voir ses défauts (et ils en ont tous).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Survivor
Posté par David Delassus (site web personnel) . Évalué à 10.
Et c'est une bonne chose, cela veut dire que l'outillage pour les trouver/détecter s'améliore de plus en plus. Intégrer ce mécanisme au processus de release (via de la CI/CD par exemple) se fait de plus en plus, et avec le temps, de moins en moins de CVE seront détectées post-prod.
Si elle a du sens. Les garanties que t'offrent ton langage sont dues à l'implémentation faite par un humain. La traduction Rust -> ASM, ou C -> ASM, ou XXX -> ASM n'est pas automatique. C'est un humain qui l'a implémenté. Si l'implémentation est erronée, tes garanties sont remises en cause.
Pas au niveau du compilateur certes, mais le bound-checking et le tracking d'allocations, ça fait des décennies qu'on sait le faire à l'aide d'outil d'analyse statique de code. Regarde la suite de test de SQLite si tu veux un bon exemple.
Je ne dis pas que le C est un langage parfait, il a des défauts. Mais la gestion de la mémoire manuelle n'en n'est pas un, c'est une feature.
Je peux me casser un doigt avec un marteau, je dois abandonner l'idée de planter des clous ou j'apprend à m'en servir correctement ?
https://link-society.com - https://kubirds.com
[^] # Re: Survivor
Posté par David Demelier (site web personnel) . Évalué à 8.
Et à l'inverse le système d'exploitation le plus utilisé sur les serveurs au monde et dans la téléphonie mobile est écrit en C. Pour autant, pas de pannes majeures à ce que je sache.
Les boites à outils modernes comme LLVM fournissent une panoplie de “sanitizers” qui rendent le développement bien plus simple. La plupart des erreurs peuvent être déterminés pendant le cycle de développement. Pour ma part, j'ai déjà été sauvé à plusieurs reprises grâce à
-fsanitize=address. (Et pas qu'en C).git is great because linus did it, mercurial is better because he didn't
[^] # Re: Survivor
Posté par Anthony Jaguenaud . Évalué à 8.
Il faut juste apprendre à programmer…
J’ai appris à mes enfants, quand ils prennent le jouet d’un copain, à le rendre. Il faut juste faire pareil ;-)
--->[]
[^] # Re: Survivor
Posté par xcomcmdr . Évalué à 4.
Ou utilise Rust/autre langage moderne de son choix, et arrêter avec:
- l'introduction de failles de sécurités partout, car gérer la mémoire en C reste un art difficile,
- La vision éperonnée qui dit que si on arrive pas à faire du C qui prévoit toutes les erreurs et toutes les failles possibles du premier coup, c'est qu'on doit apprendre à programmer.
Non, le C a ses limites. Comme tout langage. Encore plus quand il a 50 ans.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Survivor
Posté par uso (site web personnel) . Évalué à 5.
C'est exactement a cause de ce genre de commentaire que j’apprends pas le Rust.
Le langage a l'air cool, mais les fan de Rust son tellement toxic…
Bon en vrais j'ai vraiment l'intention de me mettre plus sérieusement au Rust un de ces 4, mais me faire imposer un compilateur trop gros, avec une lib standard tout aussi bloated, ça me donne pas très envie.
Alors qu'en C, je peu faire des
tcc -run cool_program.cet je peu même allers modifier le code du compilo si je veux, puisque un bon langages, ne se définit uniquement par la capacité de ces développeurs à recoder un compilo pour leur propre langages.[^] # Re: Survivor
Posté par xcomcmdr . Évalué à 6. Dernière modification le 01 mars 2022 à 22:49.
Oh moi t'façon je suis plutôt C#.
J'ai un langage à VM dans lequel je peux sortir des pointeurs (ou des Span, qui sont une vue sans risque sur une zone mémoire) et du code unsafe si je veux.
Sauf que par défaut, j'en ai pas besoin.
Et si besoin de sortir de la VM et de ses "problèmes" de performance (hint: 10 fois sur 10, le problème c'est le code, pas la VM), y'a qu'à utiliser l'AOT avec NativeAOT.
En vrai j'ai essayé Rust, mais la syntaxe j'ai vraiment du mal.
Comme quoi s'inspirer du C, du C++, du Java, du Pascal, du VB, et du F# (et par extension, des langages fonctionnels) comme le fait C# bah c'est mieux (pour moi). :P
Ceci dit les avantages de Rust sont vraiment sympas.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Survivor
Posté par groumly . Évalué à 2.
Lire ca venant de quelqu'un dont la lib standard a été écrite sur un clavier n'ayant pas de voyelles et ne permet pas de savoir quelle taille fait une chaine en temps constant (ou sans risquer un accès out of bounds), c'est assez délicieux.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Survivor
Posté par uso (site web personnel) . Évalué à -8.
Va falloir des sources pour cette affirmation, après OSEF, les voyelles sont dans ASCII.
sizeof "non ?"
[^] # Re: Survivor
Posté par groumly . Évalué à 10.
Man humour. strcpy, strchr, strpbrk, sqrt, mbstowc.
Pour les sources, elles sont dispos un peu partout sur internet, grâce à un truc qui s’appelle le logiciel libre je crois.
Non, je crois pas non.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Survivor
Posté par uso (site web personnel) . Évalué à -5.
ok, j'ai pas la blague, mais je voie vraiment pas le rapport avec les voyelles (tu veut dire accent ) ?
sizeof permet de connaître la taille d'une string à temps constant, ce que tu peu pas connaître en C, c'est la taille d'un char *(et "hello" est un char [6]).
ceci dit sizeof c'est du C, pas une partie de la libc.
Après il n'y a aucun langages "haut niveau"(C inclue) qui permet de connaître le temps d'accès à n'importe quel variable non plus. (vu que ton int peu être dans ton cache L1,L2, t'a ram, ton disk dur si t'a du swap, pas allouée du tout vu que Linux alloue de la mémoire sur les page fault par default sur x86…)
Donc l'argument de "tu peu pas faire un opération pas optimisée sur une structure de donnée pas optimisée", bon…
[^] # Re: Survivor
Posté par Olivier Abad . Évalué à 6.
Non sizeof ne renvoie pas la taille de la chaine, juste la taille du tableau.
[^] # Re: Survivor
Posté par PR . Évalué à 3.
C’est un faux débat.
Tu ne peux PAS connaître la taille d’un texte sans l’avoir parcouru au moins une fois.
Sisi je t’assure. C’est même pas de l’informatique !
Vos langages qui le font à temps soit-disant constant, c’est du flan, du marketing. C’est juste qu’ils le recalculent à chaque modification de la chaîne… et pas juste quand y’a besoin.
Sinon en C :
Mort aux cons !
[^] # Re: Survivor
Posté par Fulgrim . Évalué à 2.
Magie magie, sauf que c'est faux:
man strlen:
The strlen() function returns the number of bytes in the string pointed to by s.
Et non, le nombre de bytes c'est différent de la taille d'une chaine
[^] # Re: Survivor
Posté par Olivier Abad . Évalué à 3.
Mais les programmeurs C ayant des claviers sans voyelles, ils n'utilisent pas non plus d'accents, et n'ont pas besoin de wchar_t !
Donc strlen renvoie bien la longueur de la chaîne, sur toutes les architectures où sizeof char est 1. Je n'en connais pas où ce n'est pas le cas, mais ça doit bien exister quelque part…
[^] # Re: Survivor
Posté par Fulgrim . Évalué à 5.
Si tu supposes qu'un char code un charactère, peut être… C'est faux avec tous les encodings communs comme utf-8, utf-16, utf-32, même pas besoin de sortir l'étonnant UTF-7 (si si, ça existe, j'en ai vu des fois, ça fait très bizarre). En utf-8, un charactère peut occuper entre 1 et 4 bytes, en utf-16 2 ou 4, en utf-32 toujours 4. Et je te parle même pas du fait qu'il y a plusieurs façon de représenter le même charactère qui vont avoir des tailles différentes…
La doc est d'ailleurs explicite, ça ne renvoit pas le nombre de char mais le nombre de bytes. Strlen ne renvoit pas la longueur d'une chaine mais la taille de sa représentation mémoire.
En pratique, si tu as besoin d'accéder et travailler sur le texte, les chaînes C sont inutilisables vu qu'il n'y a pas de notion d'encoding, impossible d'itérer charactère par charactère, de passer en lowercase/uppercase tout en te laissant l'impression que tu peux.
C'est ça entre autre qui donne une fausse impression de facilité, qu'il suffit de bien faire… mais faire du C ça doit aujourd'hui être vraiment un choix mûrement réfléchi parce que c'est un vrai champs de mines.
[^] # Re: Survivor
Posté par Olivier Abad . Évalué à 3.
Mon commentaire était juste une tentative maladroite d'humour. A ne pas prendre au pied de la lettre, si je peux me permettre cette expression sans qu'on me demande l'encodage de la lettre.
C'est fou ce que ce genre de débats peut provoquer d'agressivité, aussi bien chez les détracteurs que chez les défenseurs du C.
Je fais d'ailleurs partie de ces derniers, tout en reconnaissant ses défauts, sans me sentir personnellement agressé à la moindre critique.
[^] # Re: Survivor
Posté par uso (site web personnel) . Évalué à 3.
non le standard C, dit que char c'est toujours 1,
donc sizeof char, est inutile.
[^] # Re: Survivor
Posté par David Demelier (site web personnel) . Évalué à 5.
sizeof (char)renverra toujours 1, peu importe la machine et l'architecture. La différence c'est qu'il existe des machines ou uncharvaut 64 bits donc pour faire simple : un octet ne fait plus 8 bits mais 64.git is great because linus did it, mercurial is better because he didn't
[^] # Re: Survivor
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 6.
La longueur de TXT vu des années 70 à 90, avant le supra-vodou d'Unicode, quand on codait toujours chaque caractère sur un octet (car
strlenrenvoie le nombre d'octets …avant le\0terminal si on veut chipoter)Sinon, concernant le recalcul à la modification, les langages qui ont cette approche aiment aussi stocker l'information au début de la structure (et mettre à jour à chaque modif) mais le marketing interdit de dire qu'on triche…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Survivor
Posté par groumly . Évalué à 5.
Le mot clé ici est "au moins". Le probleme du C, c'est que tu doit parcourir la chaine a chaque fois. Et encore, avec des résultats variables en fonction de ton encodage.
Et c'est pas entièrement vrai. C'est vrai pour une chaine allouée de façon dynamique (un input stream, ou que sais je encore).
Le truc, c'est que dans ces cas, tu as du parcourir la chaine en premier lieu pour la construire, donc tu as deja la taille disponible plutot facilement. Idem pour la plupart des operations de manipulations de chaines: soit la nouvelle taille se calcule de façon trivial en temps constant (substring, concatenation, etc), soit tu as 99% de chances de t'être tape un scan de la chaine pour ta manipulation, et tu as donc ta nouvelle taille.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Survivor
Posté par David Demelier (site web personnel) . Évalué à 3.
Et
strlenne renvoie pas la taille d'une chaine non plus. c.f.strlen("ça va")git is great because linus did it, mercurial is better because he didn't
[^] # Re: Survivor
Posté par rewind (Mastodon) . Évalué à 6.
Pour une certaine définition de «taille», ça marche. Après, si on va sur Unicode, on a (au moins) quatre autre définitions de «taille», on prend laquelle ?
[^] # Re: Survivor
Posté par PR . Évalué à 2.
Tu crois qu’on doit leur dire pour \t, \r \n, \b et tous les caractères de contrôles C0+C1 qui sont pourtant ascii ? Ça risque de leur faire un choc.
Mort aux cons !
[^] # Re: Survivor
Posté par uso (site web personnel) . Évalué à 1.
bah la définition d'une string literal c'est
et les string literal sont des array. (source: https://www.iso-9899.info/n1570.html#6.4.5)
Donc oui, sizeof retourne la taille d'une array, mais ça retourne aussi la taille d'une string, et c'est calculé a la compilation.
Et strlen("ma chaine de character"); c'est juste un code pas optimisée pour 0 raison.
Bien sur si on utilise des variable on doit utiliser strlen, mais si on utilise des variable et que la calcule de la longueur est important, autant utiliser une struct qui contiens la longueur de la string.
[^] # Re: Survivor
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Vous dites la même chose sans vous comprendre, je pense :)
« string literal » est une suite (séquence) de « multibyte characters » ; et « sizeof » retourne bien la taille du caleçon au sens du nombre de « bytes » et c'est aussi la taille du tableau au sens « array of chars » ;) Mais ça ne retourne pas la taille au sens où on compte souvent l'utiliser : le nombre de caractères ;) Comme qui dirait, selon que tu parles de pointures italiennes ou française vous ne parlez pas des mêmes valeurs ; pareillement taille au sens ASCII-compatible ou au sens encodage multi-octets (qui en plus peut être fixe ou variable) c'est plus la même.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Survivor
Posté par Olivier Abad . Évalué à 2.
Effectivement.
Et puis, on a rarement des problèmes en calculant la taille d'un string literal.
Les problèmes surviennent plutôt avec des chaînes initialisées à l'exécution à partir d'une source de données qu'on ne contrôle pas. Là le sizeof ne s'applique pas puisqu'il est calculé à la compilation, et dans ce cas renverrait la taille d'un pointeur.
Seul strlen s'applique (ou une variante wide char comme wcslen qui renvoie bien le nombre de caractères, pas le nombre d'octets), et peut donc prendre du temps si la chaîne est très longue.
[^] # Re: Survivor
Posté par jyes . Évalué à 7.
Je trouve cette remarque étrange, en général, la taille dont on a besoin (en tout cas en C), c’est celle qui permet de stocker la quantité d’information associée. Le nombre de caractères, je suis certain que certains s’en servent mais je ne code pas traitement de texte tous les jours, et si l’envie m’en prenait, c’est effectivement le genre de programme que je ne commencerai pas en C.
[^] # Re: Survivor
Posté par barmic 🦦 . Évalué à 7.
Très caricatural.
grep '^...$'n'est pas un traitement de texte. C'est le travail d'une bibliothèque d'expression régulière ? Alorswc -c?Rien que pour afficher des données de manière tabulaire comme le fais
ls -l.https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Survivor
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Exactement ce que je me suis dit en lisant sa réponse, sachant que ces outils sont codés en C. D'ailleurs, petit fun fact : les implémentations GNU disent dans les manuels de certains outils (je pense notamment à
tretgrepmais y en a d'autres) que la prise en compte d'Unicode est incomplète ou boguée (notamment pour les équivalence de classes de caractères et collations,[[=foo=]]et[[.foo.]]voire même juste dans certains traitements de[[:foo:]]etc.) Autre chose marrante : les réécritures en Rust ne corrigent pas ces points non plus.“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Survivor
Posté par barmic 🦦 . Évalué à 3.
J'ai déjà eu le problème parce que toutes les implémentations de awk ne sont pas en mesure de gérer l'unicode et ma solution c'est toujours de sortir perl.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Survivor
Posté par groumly . Évalué à 5.
Oui, mais non, strlen ne marche pas sur de l'unicode.
Ensuite, utiliser un struct qui contient la longueur de la string, mais aussi faire gaffe a la tenir a jour. Ce qui devient tres compliqué quand tu travailles dans un langage ou tout le monde s'attends a ce que tu leur donne un
char *et ou les effets de bords sont legions.D'ou l'intérêt de la lib standard qui va plus loin que "t'as des octets pour manipuler tes données, de quoi tu te plains?".
Bref, je pense que dans cette discussion, tu illustres plutôt bien le commentaire "le c, c'est vachement plus compliqué que ce que certains pensent, et ca va plus que 'faut juste apprendre a programmer'".
Parce que dans ce thread, tu nous en a sorti quelques une des pas mal:
Pour revenir au sujet initial, entre un std lib "bloated" ou un programme incorrect qui me pête a la gueule parce que je lui ait envoye une chaine de caractères contenant 😊, je vais prendre la std lib bloated.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Survivor
Posté par uso (site web personnel) . Évalué à -5. Dernière modification le 02 mars 2022 à 22:21.
Bah oui, tu a dit qu'il n'y a aucun moyen de calculer a temps constant de calculer la longueur d'une string, c'est factuellement faux, bien que la technique ne marche pas tout le temps.
Effectivement j'ai pas parler de l'offset de 1, mais les 2 manières permettes de connaitre la longueur d'une string, chacune à leur avantages dans certaines conditions.
Bah oui, parce-que t'a pas beaucoup de programmes qui ont besoins de sortir de l'ASCII. (moi qui ne connais que le terminal n'en ai pas besoins)
sauf que si t'a pas de \0, t'a pas une string au sens C du terme, donc c'est HS. (si tu fait un memset dans t'a std::string en C++, peu être que ça va pas bien marcher non plus).
Après j'ai jamais dit que C est un langage sécure, j'ai dit que la seul choses qui permet de noter la qualité d'un langage, c'est la capacité de ces développeur à recoder un compilateur.
Ce sur quoi:
[^] # Re: Survivor
Posté par groumly . Évalué à 7.
LOL, elle est bonne celle la.
Ton terminal-que-tu-connais-que-ca, il fait de l'utf-8, tres probablement configuré comme ca par défaut par ta distro.
Les fichiers que tu manipules ont de tres grandes chances d'etre en utf-8 aussi (ou assimilé).
Ou tout simplement, les file paths.
Mais ouais, tout pour l'ASCII mec.
Ben ca depends comment tu vois les choses.
Vu que ta position c'est visiblement "Vu que C est parfait, tout probleme est 100% imputable a un idiot de programmeur qui sait pas écrire du code, donc C est parfait", oui, c'est sur. Ca fait un peu raisonnement circulaire, mais passons.
Mais surtout ca aide pas a résoudre des problemes concrets, style "j'ecrit du code qui reçoit un
char *d'une source que je ne maitrise pas forcement, comment je fait pour savoir quelle taille elle fait sans mettre tout mon process au tas?".Permettre a quelqu'un de ne pas segfaulter ou ne pas devenir la prochaine CVE qui fait les titres, c'est ca qui font que les std libs que tu decries sont soit disant "bloated": elles ont un comportement raisonnable et prévisible et apportent des solutions concretes a de reels problemes. Le fait que tu ne comprends visiblement pas ces problemes ne veut pas dire qu'elles sont "bloated". Ca veut juste dire que tu n'as absolument aucune idée de ce dont tu parles, et que tu écris tres probablement du code complètement cassé et dangereux.
roh, ben tu sais, vu ce que tu nous a sorti dans ce fil, je pense que tu peux y aller, ca serait pas la plus grosse.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Survivor
Posté par uso (site web personnel) . Évalué à -3.
non, m'a position c'est ça: https://nitter.eu/id_aa_carmack/status/1078092777429311488?lang=en
J'ai il me semble, pas parler de sécurité, ou de la complexité à éviter les bugs en C, j'ai juste parlé du standard C, pour être un petit con qui a raison, mais si j'ai raison dans des cas qui sont en pratique peu utilisable.
mais bon vu que tu passe de "strlen marche pas sur unicode" à "les terminaux sont en UTF-8" sur lesquels strlen marche donc ASCII, UTF-8 font pas grande différence vu que ls, curl, cat… eux utilise les function de la lib standard, je crois pas être le seul à avoir des arguments un peu bidon, limite malhonnête.
[^] # Re: Survivor
Posté par groumly . Évalué à 4.
https://linuxfr.org/nodes/127047/comments/1884890 pour la source.
Tant que tu te contentes de copier des buffers sans te poser la question de ce qu'il ya dedans, ca va probablement marcher.
Maintenant, demandes toi comment ca marche pour sed ou grep.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Survivor
Posté par uso (site web personnel) . Évalué à 0.
/me aurais du s’arrêter…
Mais j'ai regarder la: https://github.com/NetBSD/src/blob/trunk/usr.bin/grep/grep.c, et bah: des char, des strcasecmp, et des strlen.
[^] # Re: Survivor
Posté par groumly . Évalué à 3.
Yep, c’est soit du code cassé, soit y’a une normalisation Unicode qui se passe quelque part.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Survivor
Posté par groumly . Évalué à 5.
yep, leur code est cassé:
En l'occurence, c'est le grep de macOS, je suppose qu'il vient d'un des BSD avec peu de changements.
Rien de tout ca dans un langage a runtime bloaté, évidemment:
Me sort:
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Survivor
Posté par uso (site web personnel) . Évalué à -1.
Et est-ce que t'a vraiment envie d'avoir une conversions de string par default, a chaque comparaison, quand tu recode un compilateur, qui auras 10M lignes de code à recompiler le plus rapidement possible ?
que tu recode git et manipule des repository de plusieurs Millions de commits ?
que t'est sur de l'embarqué et que chaque instruction compte ?
En terme de perf, ça doit être magique.
Tout ça pour en revenir à mon assertion de base: Un bon langages ne se définit que par la capacité de ces développeurs à recoder un compilo, et tu viens de m'expliquer que C est mieux que go.
Bien sur, si tu choisie ton langages de programmation en ne fessant pas cette assertion, C n'est pas forcement mieux que go, mais qui ferais ça ?
[^] # Re: Survivor
Posté par groumly . Évalué à 2.
Est ce que t’as vraiment envie que tu compilateur ne puisse pas interpréter du texte correctement, et te balance une erreur de compilation qui n’existe pas a cause d’un manque de normalisation Unicode?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Survivor
Posté par uso (site web personnel) . Évalué à 0.
tu veut dire, est ce que PHP6 a étais abandonné, car tout le monde s'en fout du support de Unicode ?
[^] # Re: Survivor
Posté par groumly . Évalué à 4.
C’est moi, ou tu viens de sortir php dans une discussion sur les bons langages de programmation?
Après, je sais pas à quoi tu fais référence exactement que les mecs de php aient prit une décision à la con et n’ait pas réussi à fournir une implémentation correcte, ça serait pas la première fois (les mecs ont prit l’habitude de releaser avec des tests unitaires qui passent pas, alors on est plus à ça près), et que les mecs qui utilisent php ne comprennent rien à ce qu’il se passe non plus, ca serait pas la première fois non plus.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Survivor
Posté par uso (site web personnel) . Évalué à 1.
Exactement !
PHP 6 avais pour but de rajouter le support unicode dans le langages (exemples):
mais a était complétement abandonné parce-que:
Mais si ça a bien montrée une choses, c'est que même pour les langage les plus populaire, (et qui on le plus tendance a avoir du code en pas anglais)
bah avoir un gestion correct de unicode dans t'a VM/compilateur/interpréter est assez OSEF-tier.
Donc quand tu recode un compilo, avoir le '==' de swift est pas forcement un avantage.
[^] # Re: Survivor
Posté par groumly . Évalué à 4.
Ca montre surtout que les mecs de php sont des bras cassés, ce qui est pas franchement nouveau. Ils l’ont pas abandonné parce que personne en voulait, ils l’ont arrêté parce qu’ils n’ont pas réussi à l’implémenter, en grande partie parce qu’ils n’ont pas assez de gens sur les projets qui comprennent le problème.
Ça te surprend vraiment venant d’un langage qui considère que la date
0000-00-00est équivalente à1999-11-30, et ferme ça comme « not a bug, working as designed »?Pour le « personne ne voulait vraiment la feature », je te renvoie à https://wiki.php.net/ideas/php6/unicode
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Survivor
Posté par Jérôme FIX (site web personnel) . Évalué à 3.
Pas tout à fait exact, en réalité c'est -0001-11-30 et il y a une vraie logique derrière
C'est car tu peux ajouter ou retirer des jours, mois, années d'une date existante et PHP te recalcule les dates. Tu y vois une bug ou voudrait que cela ne soit pas possible, certains y voit une fonctionnalité.
Exemple : 2022-03-00 te donnera le dernier jour de février 2022
Même si ces chaînes de caractère en tant que date n'ont pas de sens
https://www.php.net/manual/en/datetime.formats.date.php
Mais ce n'est pas le sujet.
[^] # Re: Survivor
Posté par groumly . Évalué à 4.
Je comprends très bien que c’est censé être une feature.
Mais c’est juste absolument délirant comme feature.
Les dates sont déjà assez difficiles à gérer tel quel, rajouter des trucs genre « une date invalide est considérée comme valide via des pirouettes intellectuelles » ne va vraiment pas aider.
C’est du même niveau que de dire « bah, les divisions par 0, c’est pas pratique de gérer les erreurs, alors on va dire qu’une division par 0, ça fait 0 ».
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Survivor
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Les gens de MySQL aussi acceptent des dates invalides et c'est bien pratique des fois.
Non, la division par zéro est indéterminée parce-que plus ou moins l'infini selon qu'on approche par plus ou moins zéro… Après ce cas est bien spécifié, contrairement aux dates invalides (que la norme autorise d'ailleurs, faut juste que ce soit convenu entre les deux parties ce qu'on en fait)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Survivor
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 03 mars 2022 à 18:34.
PortgreSQL et Kotlin gèrent nativement Unicode, emoji comprises. Les autres langages à JVM peuvent ne pas gérer correctement les emojis pour une sombre histoire de simplification dans la gestion interne, qui était cohérente dans les années 1990 mais est devenue obsolète avec les emojis, qui sont les seuls caractères courants à ne pas être dans le plan de base d'Unicode.
Je serais curieux de savoir si ce support est une spécificité de PortgreSQL ou si d'autres SGBD fonctionnent ainsi.
PS :
La connaissance libre : https://zestedesavoir.com
[^] # Re: Survivor
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
À ma connaissance, c'est propre à PG ; les autres SGBD (aux dernières nouvelles) ont des contraintes assez traditionnelles sur les noms des entités.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Survivor
Posté par groumly . Évalué à 6.
C’est assez particulier comme vision quand même.
Une bonne voiture ne se définit que par la capacité des conducteurs de refaire l’injection.
Un bon avion ne se définit que par la capacité des pilotes de refaire l’avionique.
Un bon cpu ne se définit que par la capacité de refaire les transistors.
Un bon immeuble ne se définit que par la capacité des architectes de couler le béton.
Un bon ballon de foot ne se définit que par la capacité du footballeur de refaire le ballon.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Survivor
Posté par uso (site web personnel) . Évalué à -4.
Sur internet le 2nd dégrée marche mal, car il est compliquée de comprendre l’expression de gents a l'écrit.
Mais vu que le 3éme c'est l'inverse, le 3éme dégrée marche extrêmement bien, pour l'univers entier (sauf les personnes qui ont plusser ton explication 1er degrée)
1er dégrée: le C est effectivement difficile dans plein de cas, mais ça simplicité lui donne certain avantages dans tout ce qui est bas niveaux et a besoins de performances.
2éme dégrée: Oui le C, c'est trop bien, ca permet de coder cowsay en ascii sur arduino, LOL ooops segfault.
3éme dégrée: Un bon langages ne se définit que par la capacité de ces développeurs à recoder un compilo. (avec un essaye d'explication pour donner les vrais avantage de C, tout en ayant l'air 2nd dégrée).
Enfin c'est mon explication des dégrée de paroles, qui est donc universellement vrais (toutes personne en désaccord a tord, et n'utilise pas Arch Linux)
[^] # Re: Survivor
Posté par barmic 🦦 . Évalué à 3. Dernière modification le 03 mars 2022 à 07:06.
Je ne comprends pas ce que tu veux dire de quelle conversion tu parle ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Survivor
Posté par uso (site web personnel) . Évalué à 2.
Bah l’exemple avec grep:
on voie que en go, si tu fait un '==' entre 2 chaine unicode, qui représente le même character, mais on des octet différent(ici "\u{00e9}" et "\u{0065}\u{0301}"), go retourne true.
ce qui veut dire que le '==' de go, est plus complex qu'un comparaison octet à octet.
C'est surement très pratique dans plein d’application, mais si tu cherche de la perf, c'est moins performent.
[^] # Re: Survivor
Posté par Thomas Douillard . Évalué à 6.
Si tu veux une comparaison octet à octet il faut probablement pas utiliser le type « chaine de caractère » mais le type « tableau d’octets » ou quelque chose du genre.
https://www.admfactory.com/convert-char-array-to-string-in-golang/
Le problème du C c’est qu’on confond habituellement allègrement les deux.
[^] # Re: Survivor
Posté par PR . Évalué à 7. Dernière modification le 03 mars 2022 à 11:18.
C’est surtout que ça compare pas deux caractères (le point de code au sens Unicode est ce qui se rapproche le plus de la notion usuelle de caractère), mais deux rendus supposément identiques.
Le problème c’est que ça n’a rien :
1/ de prédictible
2/ d’universel
Savoir si deux caractères (ie. point de code) sont et/ou doivent être identiques en rendu (ie. glyphe), c’est un problème très complexe (ça va dépendre du moteur de rendu de l’utilisateur en particulier, mais aussi de considérations sémantiques et donc de la langue…). Et avoir foutu ça comme comportement par défaut d’un langage de programmation, c’est juste une immense connerie. Ça fait faussement croire à une facilité, une feature, pour le développeur, mais ça porte en soit des effets de bords difficilement maîtrisables.
Un langage bien conçu, aurait dû garder == (ie. la comparaison de base) comme une égalité d’encodage (même pas un égalité de point de code!), c’est-à-dire une comparaison bit-à-bit au final ET proposer en lib standard des outils de comparaison plus évolués :
1. Comparaison de point de code : ce qui oblige à connaître l’encodage du texte comparé, ce que le == n’indique pas du tout — nécessairement il admet implicitement un encodage, mais lequel ?
2. Comparaison de glyphes (ce qui oblige en plus à avoir des tables de caractères “qui se ressemblent”, avec tout le flou que ça induit)
PS : un point de vocabulaire rapide. Unicode, c’est une norme d’identification des caractères : elle attribue (entre autres, mais pas que) un point de code à chaque caractère. Un encodage unicode (utf-X par exemple) ça va être une norme qui établie une correspondance entre un point de code et une valeur en mémoire informatique (l’encodage ne couvre pas nécessairement tout unicode, par exemple UCS-2, et du coup je dirais que l’ascii est un encodage unicode, si je voulais troller). Le glyphe est la représentation graphique du dit caractère, lui-même très différent de la représentation finale qui va être constitué d’une lettre et d’un ou plusieurs signes diacritiques (par exemple). Il n’y a pas de correspondance 1 à 1 entre glyphe, point de code et encodage (même en ascii car
&c’est un et ligaturé à la base, qui est devenu caractère autonome par évolution de l’usage…). De plus un caractère ne se définit pas seulement par sa représentation graphique, mais aussi par son comportement dans une phrase (ligature, césure, etc.). Et depuis le début on ne parle que d’alphabets latins… là on parle du cas archi-ultra-méga simple (même unicode est criticable selon certains linguistes).PPS : si vous voulez coder propre, portable, soyez générique, ne rendez pas votre code dépendant d’un système d’encodage / de codification de caractères particulier, faites le moins d’hypothèse possible sur les données que vous traitez (y compris hypothèses implicites / cachées). Donc autant que faire se peut considérez du texte comme un simple paquet de bytes en étant totalement agnostique vis-à-vis de sa représentation interne. Je travaille dans un domaine où il n’est pas extraordinaire de trouver que même l’ascii est trop large et où on stocke que des majuscules (pas d’ambivalence entre majuscule et minuscule : ah ouai tiens d’ailleurs tu compares comment majuscule et minuscule ? Si c’est en début de phrase c’est le même caractère ? Si c’est pour un nom propre c’est plus le même ? Et si c’est un nom propre en début de phrase ? Ton == il doit faire une analyse sémantique pour savoir, où il met juste sous le tapis le problème ?)
Mort aux cons !
[^] # Re: Survivor
Posté par groumly . Évalué à 5.
Je suis d’accord, la normalisation a rien à faire dans un langage de programmation, c’est pour ça qu’elle est définie au niveau d’unicode lui même.
Swift se contente d’implémenter la spec.
https://unicode.org/reports/tr15/
Comment diable veut tu espérer comparer des chaînes si tu ne connais pas leur encodage? En l’occurrence, l’encodage est capturé à la source, quand tu construit la chaîne.
Les opérations d’égalité et autres manipulations se font ensuite de normalisée, vu que tout le monde est sur le même pied, via
String. Tu peux recevoir une chaîne en UTF8, une autre en utf32 et une troisième en iso 8859-15, et les concatener ensemble, String sait comment faire vu que string connaît et comprend chacun des encodages. Ta chaîne sera correcte sémantiquement et techniquement, au niveau du buffer qui back la struct.L’égalité par défaut va marcher au niveau sémantique, si tu veux comparer les
char *, tu peux aussi, cf le code au dessus.Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Survivor
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 03 mars 2022 à 16:50.
Il me semble que c'est bien une comparaison de points de code qui est faite, et non de glyphes (information qui n'est pas accessible à ce niveau là). Et me semble aussi (faudra que je me replonge dans les specs et docs pour être sûr) que ça tient bien compte du type (i.e. de la famille) d'encodage (UCS-2, UCS-4, UTF-8, UTF-7, ASCII) et des caractérisations Unicode (majuscule/minuscule du même, blanc, chassant, etc.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Survivor
Posté par groumly . Évalué à 2.
Plusieurs choses. Déjà c’est du Swift, pas du go. Les mecs de go ont pas de voyelles sur leur clavier non plus.
Ensuite, oui, == est souvent plus cher en Swift qu’un ==, mais pas pour les raisons que tu cites. C’est une égalité de valeur, pas de référence. Swift utilise === pour l’égalité de références.
Pour finir, la normalisation n’est pas appliquée à chaque égalité, mais a la constructiom, quand tu vas devoir itérer ta chaîne pour les raisons au dessus. J’ai pas les détails de l’implémentation, mais l’essentiel de ce que tu vois ici est appliqué de façon paresseuse. Tu le payes (presque) pas tant que tu l’utilises pas. Encore que, je suppute que utf8CString est simplement le buffer qui back la chaîne, ce qui me fait penser que même la normalisation est appliquée de façon paresseuse en fait.
Et oui, les mecs du runtime ont passé beaucoup de temps à peaufiner leur api string pour éviter que ça soit « bloated », c’est pour ça qu’on s’est tapé un changement d’api à mi chemin. Ça tourne sur des montres, donc bon, ils s’en sortent pas trop mal quand même.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Survivor
Posté par fearan . Évalué à 3.
Sous linux la différence de perf entre un
grep -R 'chaine sans accent'
et
LANG=C grep -R 'chaine sans accent'
est sans appel…
mais oui si y'a des accents, faut se farcir la perte de perf, mais même comme ça, on peut avoir des résultat incomplet, le o cyrillique ne matchant pas le o latin…
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Survivor
Posté par uso (site web personnel) . Évalué à 1.
eh, sauf que c'est pas exactement ce que fait le '==' en swift.
La perte de perf dont je parle, est du à la normalisation pour faire en sorte que "\u{00e9}" == "\u{0065}\u{0301}" en swift.
et vu que grep a l'air d'utiliser des comparaison octée a octée (avec netbsd, mais surement pareil sous GNU), bah grep devrais être plus rapide que le code swift de groumly.
Mais de la comparaison octée a octée peu étre utiliser pour de l'UTF8.
"\u{00e9}" == "\u{00e9}" va marché, mais pas "\u{00e9}" == "\u{0065}\u{0301}".
Parce-que tu peu gérer les emoji et autre dans un compilo en gérant UTF-8 avec peu de perte de perf, le problème c'est si t'essaye de faire en sorte de gérer tout les encodage d'unicode.
En gros groumly dit que un languages devrais avoir dans ça lib standard des super string, et je dit qu'en C on veut des string réaliste.
Bref tu préfère Goldorak ou Gundam quoi ? (parceque Goldorak super Robots, et Gundam Real Robots (et bien sur la bonne réponse c'est Ideon))
[^] # Re: Survivor
Posté par groumly . Évalué à 4.
C’est pas si compliqué que ça.
Soit tu travaille des byte streams sans te poser la question des encodages et de la semantique des bytes, et Swift te donne cette possibilité, C aussi d’ailleurs.
Soit tu travailles sur des chaînes de caractères et t’es un peu obligé de prendre en compte la normalisation Unicode si tu veux émettre du code correct. Swift te donne cette possibilité. C aussi d’ailleurs, mais tu vas avoir beaucoup plus de boulot à faire.
C’est surtout ça qui m’ennuie dans ton commentaire, considérer qu’une String est juste un tableau d’octets. C’était vaguement vrai en 1977, mais ça fait plus de 20 ans que ça n’est plus le cas.
La question est surtout est ce que ton code est correct? Parce qu’aller très vite pour donner la mauvaise réponse, c’est facile, je peux le faire moi aussi: 42, temps constant, je suis le plus rapide de la planète.
Ok, j’exagère un peu. Plus sérieusement, un lookup qui foire dans une hash map pour des raisons d’encodage de la clé, c’est quand même super ballot. Idem pour une recherche dans un index full text, ou un sed qui rate une substitution.
T’imputes aussi une perte de performance à cette normalisation sans avoir la moindre idée du coût réel de cette normalisation.
Est ce que Swift est « plus lent » que du C? Oui, très probablement.
Dans quelle proportion est il plus lent? Ça depend du contexte.
Est ce que cette lenteur est causée par la normalisation? Probablement pas, en tout cas certainement pas au niveau que tu penses.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Survivor
Posté par fearan . Évalué à 3.
ou limiter les entrées à du ASCII tout bête. ça évite les attaques par glyphe similaires, évite d'avoir un truc insaisissable sur une disposition courante; tout dépend de la cible; (par contre si faut saisir des noms de personnes, pas le choix vaut mieux passer à un encodage large)
Non la question est qu'est qu'une comparaison correcte : est-ce que le o cyrillique doit être == à un o latin? De même pour tous les glyphes communs. Comme dit plus haut la réponse est loin d'être évidente.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Survivor
Posté par groumly . Évalué à 7.
Euh ouais, mais non la. La normalisation gère des situations sémantiquement identiques, pas de glyphes qui se ressemble suffisamment dans certaines polices.
L’exemple de base, c’est un e compose avec un accent vs un é.
Passer du cyrillique à un alphabet latin ne fait partie d’aucune normalisation, c’est comparer des choux et des carottes. Unicode fournit une liste de caractères sujet à confusion, si t’as besoin de vérifier ce genre de choses: http://www.unicode.org/Public/security/revision-05/intentional.txt
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Survivor
Posté par fearan . Évalué à 1.
Passer du cyrillique à un alphabet latin ne fait partie d’aucune normalisation, c’est comparer des choux et des carottes.
Cool lorsque mon programme pantera parce que qu'un petit malin s'est permit d'user d'alphabet non courant, je saurais qu'en théorie j'ai juste!
Normaliser les entrée externe c'est une base (passer en ascii standard (voir 7 bits) est une normalisation, mais c'est loin d'être suffisant; le choix de la normalisation est aussi important, et le filtrage (validation) des entrés est bien plus importante que la normalisation;
et parfois on ne veut pas de normalisation grep sur un fichier binaire n'a pas à interpréter la source.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Survivor
Posté par groumly . Évalué à 8.
Unicode dit que l’existence de 2 formes pour é est un artefact d’encodage, inévitable vu le domaine, mais que les 2 encodages représentent exactement la même chose. Un peu comme un int casté en bool va traiter 1 et 2 comme étant la même chose (true).
Le but d’unicode, c’est précisément de découpler la représentation binaire du texte de sa semantique, pour que le code puisse opérer au niveau semantique. D’ailleurs, je dit texte, mais c’est même pas vrai, c’est juste un raccourci, Unicode gère plus que du texte, c’est le but.
Tout comme le but de if (myInt) est de découpler la représentation binaire de la semantique, et dans ce context 1 et 2 sont égaux.
Donc je te renvoie au commentaire au dessus.
Si tu traites un flux d’octets, oui, la normalisation est incorrecte et n’a pas de sens.
Si tu traites une chaîne Unicode, le standard dit que les 2 formes de é sont équivalentes et représentent la même chose, et ton code est cassé s’il ne fait pas ça. Je te rassure, il y’a énormément de code cassé sur ce sujet, Unicode est très loin d’être simple à gérer. Ce qui est justement ce qui me fait hurler quand je lit les commentaires d’uso.
Juste parce que tu peux traiter la String comme un flux d’octets et t’en sortir dans 98% des cas ne veut pas dire que c’est correct. Le problème du C, c’est précisément de dire « un octet et un char sont la même chose, d’ailleurs on a même pas de type pour représenter un octet, utilisé juste un char ». Ça marchait bien en 77 vu les contraintes, mais le monde a un peu évolué depuis.
comment tu normalises 😒 en ascii?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Survivor
Posté par uso (site web personnel) . Évalué à -1.
Si j'ai donnée l’impression de dire que en C c'est facil de lire de l'unicode, pardon, c’était pas le but. (et encore y'a les wchar_t)
Ce que j'ai essayé de dire, c'est quand tu travaille sur un projet qui a un vrais besoins de perf tel que tcc,git,grep,quickjs,linux… Mieux vaut un truck cassée qui marche la plupart du temps, que d'avoir un truck qui marche tout le temps, mais qui casse ton CPU de temps en temps.
[^] # Re: Survivor
Posté par groumly . Évalué à 7.
Dernier commentaire de ma part sur le sujet, parce qu’on commence à tourner en rond, je recopie juste ce que j’ai écrit plus haut:
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Survivor
Posté par PR . Évalué à 1.
Par simple curiosité ça donne quoi avec ff (point de code 66) et ff (point de code FB00) ?
Du coup pour toi entre ' ' (20) et ' ' (A0) aucune différence ?
Mort aux cons !
[^] # Re: Survivor
Posté par PR . Évalué à 1.
Pour le petit effet kisskool, j’ai eu une césure pile sur le f ligaturé de “différence” chez moi. Mon moteur de rendu (firefox—cairo?—harfbuzz?/linux) applique systématiquement la ligature, même sur la césure, tellement bien qu’il coupe un bout du premier f pour le coller sur la ligne suivante…
Mort aux cons !
[^] # Re: Survivor
Posté par groumly . Évalué à 6.
j'oubliais celle la:
Tu joues au plus con la, tu pinailles, et t'as quand meme tord au final.
J'ai dit "une chaine", pas "une literal identifiée comme telle par le compilateur". Ce genre de raccourcis de comprehension va te poser des problemes en c, vu la precision du langage de la spec.
T'avais tres bien compris le sens de ma remarque. Tu noteras aussi que calculer la taille d'une chaine compile time constant, c'est pas particulièrement utile.
Nope, nope, nope.
Ta methode te permet de connaitre la longueur d'une chaine ascii, et uniquement une chaine ascii. "Une string" n'est pas une chaine ascii.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Survivor
Posté par uso (site web personnel) . Évalué à -2. Dernière modification le 02 mars 2022 à 23:40.
Oui, mais une chaine ASCII est une string :p
Pour arréter le troll, c'est plutôt bien l'esprit de C, si t'a une string literal, tu utilise sizeof, si t'a chaine ascii(void UTF-8 dans certains cas) tu prend strlen, et si t'a de l'unicode, voila wcslen.
Et si tu veut un méthode qui gère tout, tu va galérer, mais si t'est bien avec ton programme qui a tout en static (un genre de sl (le train)?), bah tes sizeof seront très bien, et pas besoins de plus.
[^] # Re: Survivor
Posté par aiolos . Évalué à 7.
Ben, on est sur un thread qui parle de ta remarque
Quand à :
Dans strcpy, strchr, strpbrk, sqrt, mbstowc, tu as combien de voyelles ?
[^] # Re: Survivor
Posté par uso (site web personnel) . Évalué à 3.
C'est vrais, âpres dire "c'est pas dans la lib standard" alors que c'est dans le langage, c'est pas ouf comme argument.
Ok, j'avais vraiment rater la blague, merci pour l'explication.
[^] # Re: Survivor
Posté par jmiven . Évalué à 5.
C'est bien beau de renvoyer au manuel, mais comment fais-tu pour lancer
man humouravec un clavier sans voyelles ?C'st vrmnt d l mvs fo, ls vnt n o sr lr clvr !
[^] # Re: Survivor
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Tant qu'on a les chiffres et certains symboles ça devrait le faire
(par contre, je ne vois pas de contournement avec les builtins pour lesquels je ne peux pas utiliser l'astuce du globbing)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Survivor
Posté par Thomas Douillard . Évalué à 5.
https://godbolt.org/z/oYfbed344
[^] # Re: Survivor
Posté par uso (site web personnel) . Évalué à -3.
https://godbolt.org/z/c6hnG31YM
On va pas refaire le débats sur sizeof, ça marche dans certains cas, pas d'autres, et ça dépend de t'a définition de "c'est quoi la taille d'une string ?"
[^] # Re: Survivor
Posté par Thomas Douillard . Évalué à 3.
En résumé, ça marche pas sauf dans des cas tellement triviaux qu’un compilateur un peu malin pourrait faire l’optimisation lui même.
[^] # Re: Survivor
Posté par uso (site web personnel) . Évalué à -1.
https://godbolt.org/z/1rqGvn8sv
Ça permet de faire de la manipulation de string, sans passer par de l'allocation dynamique.
mais je doute pas qu'un compilo aurais pu remplacer des malloc par du code static, Oh wait, tu sais comment marche un compilo ?
[^] # Re: Survivor
Posté par Thomas Douillard . Évalué à 5.
Si tu travailles qu’avec des constantes et des chaines de formatages dont tu connais à l’avance la taille finale, là tu nous fais un genre de boucle avec dedans
ben … il y a pas de raison particulière pour qu’un compilateur ne puisse pas calculer les tailles par lui même.
[^] # Re: Survivor
Posté par uso (site web personnel) . Évalué à 0. Dernière modification le 03 mars 2022 à 11:38.
ok, remplace le printf par un open, SDL_LoadBMP, Mix_LoadMUS…
genre t'a un dossier avec des assets, ou tu suit des pattern de nommages.
l’intérêt c'est comment j'utilise memcpy (plus opti que strcpy BTW)
Crée un buffer dans la mémoire automatique qui auras la taille exact de plusieurs strings.
pouvoir modifier la taille des strings dans mes defines sans avoir peur d'overflow.
[^] # Re: Survivor
Posté par Thomas Douillard . Évalué à 3. Dernière modification le 03 mars 2022 à 12:08.
Ça change rien, tu calcules ton nom de fichier/ressource avec un snprintf et c’est pareil. Ça nécessite que le compilo ait une certaine connaissance de la sémantique des chaine de formatage, donc que ça fasse partie de la spec ou que le compilo prenne des initiative. C’est plus ou moins le cas en rust ou c’est une macro https://doc.rust-lang.org/std/fmt/ et les implémentations typesafe dans divers langages dont C++
[^] # Re: Survivor
Posté par uso (site web personnel) . Évalué à 2.
sauf que sprintf a pour 1er argument un buffer, si tu utilise un buffer static avec un taille fix (et donc snprintf), tu peu pas savoir si ton buffer seras assez gros, si tu fait des malloc, c'est plus lourd et tu doit free, sinon tu fait des sizeof, t'a ton buffer qui a la bonne taille, et pas besoins du 'n' dans sprintf, puisque ton buffer auras la bonne taille.
[^] # Re: Survivor
Posté par Anthony Jaguenaud . Évalué à 2.
En vérifiant le retour de
snprintf, tu peux savoir s’il y avait assez de place… Obligatoire, dès que tu as en entrée des données que tu ne maitrises pas.[^] # Re: Survivor
Posté par uso (site web personnel) . Évalué à 0.
Effectivement, je voulais dire, tu peu pas savoir si snprintf va fail(avant de l'appeler).
le truck, c'est que si tu met une taille impartial à ton buffer(genre 1024), même avec des donnée en entrée que tu maitrises(genre des strings literal), t'est pas a l'écart qu'un gent modifie t'a string, et dépasse ton buffer.
Pour gérer ça que sizeof sur une string littéral, peu être bien pratique de temps à autre.
[^] # Re: Survivor
Posté par Thomas Douillard . Évalué à 3.
Par curiosité j’ai été voir comment c’est implémenté en Rust, et c’est essentiellement un « compiler built-in ») https://doc.rust-lang.org/src/core/macros/mod.rs.html#858-861 donc le compilo fait tout ce qu’il veut et à tout ce qu’il faut pour faire l’optim.
[^] # Re: Survivor
Posté par David Demelier (site web personnel) . Évalué à 10.
Exactement. De toute façon c'est assez simple, il y a la règle de Rust : à chaque fois qu'une discussion commence sur le C ou le C++ elle finira toujours par aboutir sur Rust.
Ce dont les gens ont tendance à oublier avec le C :
Longue vie au C.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Survivor
Posté par xcomcmdr . Évalué à 0.
C'est logique, vu que son but est de remplacer le C.
Aussi, rien qu'évoquer Rust est toxique maintenant ?
Vous êtes aisément vexés. Va falloir se calmer.
C'est vraiment dommage que Rust dépende d'un seul acteur et n'ai pas de norme ISO, c'est bien vrai.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Survivor
Posté par uso (site web personnel) . Évalué à 3.
C'est vrais que je suis un peu partie vite, âpres, avoir quelqu'un qui viens te dire, "fait du Rust" dans chaque conversation qui parle de C, c'est une peu lourd.
Une peu comme si a chaque fois que tu évoque C# quelqu'un te tombe dessus parce-que "Grenieunieu Microsoft c'est mal".
Ou comme si dans caques conversation qui parle de Distro (GNU ?)Linux, y'a un con qui viens te parler d'Arch (GNU ?)Linux.
Dalleur, est ce que vous saviez que j'utilise Arch (GNU ?)Linux, et que ça marche vraiment très bien ?
[^] # Re: Survivor
Posté par aiolos . Évalué à 3.
Parce que ce n'est pas le cas ?
[^] # Re: Survivor
Posté par David Demelier (site web personnel) . Évalué à 6.
Non, tu n'as pas évoqué Rust. Tu as dit « Ou utilise Rust/autre langage moderne de son choix ». Ce n'est pas tout à fait la même chose.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Survivor
Posté par xcomcmdr . Évalué à 1.
Quoi ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Survivor
Posté par barmic 🦦 . Évalué à 5.
Mozilla n'a plus aucun rapport avec rust.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Survivor
Posté par Moonz . Évalué à 3.
Et au lieu de te braquer dès que tu lis ça, tu pourrais te demander s’il n’y a pas une bonne raison. Toute mode n’est pas infondée, et Rust n’est pas spécialement poussé par des gens qui parlent pure théorie sans avoir aucune ligne de code à leur actif. Juge la communauté Rust par sa production technique, pas par de vagues affects ("j'aime pas les dépendances" "ils sont trop prosélytes"), et tu verras aisément que ce n’est pas que du vent.
Je veux dire, tu as le droit de ne pas aimer Rust, mais si tu veux critiquer, ce serait bien de le faire après avoir jugé sérieusement, pas avant.
0 dépendances nécessaires pour un hello world, la lib standard suffit. Comme dans presque tous les languages existants.
Rien dans C ou C++ ne t’empêche d'importer 12000 dépendances, rien dans Rust ne t'oblige à importer des dépendances.
Et c’est une fausse comparaison. En C/C++ tu listes tes dépendances directes, et c’est la responsabilité de l’utilisateur de s’assurer que l’arbre entier de dépendances est installé sur la machine et accessible par le compilateur (généralement la distrib s’en charge). Cargo.lock liste explicitement les dépendances transitives et se charge de les récupérer. La responsabilité est déplacée mais la quantité de travail est la même.
Tu as aussi le fait que étant donné que les gens comme toi n’aiment pas "avoir 50 dépendances parce que c’est du bloat" (et aussi pour des raisons historiques), en C/C++ on préfère faire une lib qui fait 50 trucs vaguement liés plutôt que 50 libs qui font 1 truc. Regarde par exemple les fonctionnalités fournies par boost (C++) ou glib (C) et cherche l’équivalent Rust : ce sera split en de nombreuses crates.
[^] # Re: Survivor
Posté par rewind (Mastodon) . Évalué à 4.
C'est vrai que boost, c'est un gros truc monolithique, c'est d'ailleurs bien ce qu'on lui reproche… oh wait!
[^] # Re: Survivor
Posté par David Demelier (site web personnel) . Évalué à 4.
Hmm ouais. Sauf qu'une fois j'ai voulu utiliser un seul module "header-only" et j'ai du me trimballer MPL, System et d'autres modules transitifs. Et System lui n'est pas header-only, donc ceux qui disent que cette bibliothèque est header-only et modulaires vendent du vent.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Survivor
Posté par rewind (Mastodon) . Évalué à 8.
Boost n'a jamais prétendu être une bibliothèque header-only. Il n'y a pas que
systemqui a besoin d'une bibliothèque compilé (il y a aussiprogram_options,filesystem,regex,locale,serializationet sans doute d'autres).Ensuite, si, c'est modulaire, justement. Mais le problème vient du fait qu'il y a beaucoup de dépendances entre ces modules. En cherchant, on trouve sur le net le graphe de dépendances et c'est juste un enfer, ce qui fait que quand on tire une des bibliothèque de haut niveau, on tire la moitié des autres (mais après, c'est ce que promeut Moonz avec les crates de Rust).
Chacun des deux systèmes (ultra-modulaire, ou largement monolithique) a ses avantages et ses inconvénients. Vu npm ou les crates ou boost, je ne suis pas sûr de vraiment préférer le système ultra-modulaire.
[^] # Re: Survivor
Posté par kowalsky . Évalué à 4.
Sauf que les jouets, tu ne te rend pas compte par hasard que tu en as emprunté 1.000.000.000 parce que tu as demandé à "tant que je suis la, tu me prêtes un jouet ?"
[^] # Re: Survivor
Posté par David Delassus (site web personnel) . Évalué à 8.
SQLite n'est ni un kernel, ni un driver, ni de l'embarqué, ni un hardware digne des années 80, et il a même pas la moitié de l'âge du langage C (22 ans).
https://sqlite.org/whyc.html
CPython par exemple, c'est pas un kernel, pas un driver, pas de l'embarqué, etc… Il existe PyPy pourtant, après tout Python n'est qu'une spec.
Ou alors Lua.
Ou alors tout le domaine de la finance qui a besoin de performance à la nanoseconde près.
C'est effectivement l'observation qu'on peut faire si on détourne le regard sur ce qu'apporte le C depuis maintenant 50 ans.
https://link-society.com - https://kubirds.com
[^] # Re: Survivor
Posté par groumly . Évalué à -1.
ok, super, t'as trouvé des softs écrits en C.
Je peux te sortir swiftc ou clang ou hotspot, tous écrits en C++, ca fera pas avancer le chimilimili.
CPython a presque 30 ans, Pypy a l'air de poursuivre le travail de Psyco qui remonte au debut des annees 2000, et Lua a lui aussi 30 ans.
C'est le genre de code qui rentre dans "la montagne de code a porter" dont je parlais.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Survivor
Posté par David Delassus (site web personnel) . Évalué à 8. Dernière modification le 28 février 2022 à 23:45.
Tu dis initialement que le C n'est plus utilisé que pour les kernel/drivers et l'embarqué. Je te cite des exemples pour contredire ta mésinformation. Si la vérité t'offense, c'est pas grave.
Pourquoi vouloir réécrire des choses qui fonctionnent bien, qui sont testées intensivement, juste parce que "un nouveau langage hype est apparu" ?
SQLite ne sera jamais réécrit en Rust par exemple. CPython non plus. Lua non plus. If it's not broken, don't fix it.
Une réécriture complète est un travail monstre, fastidieux et long pour arriver au même niveau fonctionnel. Personne dans son bon sens ne s'attèlera à une telle tâche, à part les prosélytes du langage hype X ou Y.
Surtout si il faut le faire tout les 5 ans à chaque fois qu'un nouveau langage sort avec comme argument "le langage XXX c'est le mal, il faut tout migrer vers YYY".
Pour ceux qui ont envie de rire un coup : https://github.com/ansuz/RIIR/issues
https://link-society.com - https://kubirds.com
[^] # Re: Survivor
Posté par groumly . Évalué à 7.
Pourquoi, oui, en effet? Je me rappelle pas avoir dit qu'il fallait le faire.
Mais que si il fallait le faire, C ne serait pas le language le plus adapté.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Survivor
Posté par Moonz . Évalué à 2.
[^] # Re: Survivor
Posté par rewind (Mastodon) . Évalué à 10.
Autant tout recopier, c'est assez instructif :
[^] # Re: Survivor
Posté par Philippe F (site web personnel) . Évalué à 7.
De façon intéressante, les nouveaux qui sont censés enterrer l'ancien n'y arrivent pas complètement, et surtout, lui doive beaucoup. Pour nommer ceux que tu as cités et je connais, une grande partie de leur syntaxe est héritée du C : Java, C++, .Net, Python, Javascript. Comme dit Rafiki à Simba dans le roi lyon à propos de son père: "il vit en toi!". Le C vit aussi dans tous ces langages qui lui sont apparentés.
[^] # Re: Survivor
Posté par David Demelier (site web personnel) . Évalué à 10.
Elles sont tirés de ton chapeau personnel ces statistiques ?
Il y a des projets récents en C, y compris dans le jeu vidéo et dans le reverse engineering. Faut juste se renseigner.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Survivor
Posté par PR . Évalué à 10.
Il l’est. Fondamentalement les outils Unix, le shell, et le C ont été pensé de concert pour fournir un environnement intégré (il y a souvent bijectivité entre les appels shell et les appels C). C’est sous Unix que le C révèle sa puissance (donc pas de bloatware, E/S au format texte, en ligne et facilement parsable, minimalisme, généricitié, orthogonalité, transparence).
À titre d’exemple, je suis en train d’écrire quelques petits utilitaires, dont rsu en ~1 journée à temps plein (un genre d’opposé à sudo : il diminue les privilèges d’un processus — j’espère bien pouvoir publier ma petite collection sur linuxfr un de ces jours) :
C’est tout riquiqui
Même pas en rêve je fais ça dans un autre langage… Et à la base j’ai juste des connaissances de base du C (je montre pas le code d’ailleurs… y’a même des goto à l’ancienne) et je me suis lancé après lecture de The Art of UNIX Programming, avec à mon chevet The Linux Programming Interface,
man 3p ...est devenu mon ami aussi.Mais par exemple parser /etc/group. En C ça se fait très bien, parce que c’est un bête fichier tabulé (de fait mon code se résume à un strstr puis strtol pour avoir l’uid/gid de l’utilisateur, et pour des choses plus complexes l’approche traditionnelle est de passer par lex/yacc). En mode moderne, on aurait sorti un bazooka json-over-xml-over-transparentNetwork-over-sqldatabase avec minimum trois couches d’abstraction (j’exagère ?) pour storer le bousin…
La programmation en C d’outils pur Unix est plutôt agréable. C’est beaucoup de lecture, peu d’écriture. Ça peut être frustrant de ne pas pisser de la ligne de code, mais au final le résultat est là quand on prend bien le pli Unix.
Perso j’apprécie énormément cette manière de bosser. Le truc, c’est que c’est peu compatible avec un travail en entreprise dans l’ambiance ultra-autoritaire actuelle, il faut bien le dire, parce que cette semaine on a rien produit parce que lecture de n00 pages de doc mini… Non il faut juste montrer qu’on a pissé du code ou autre pour satisfaire la hiérarchie, il vaut mieux écrire 1000 lignes de codes qui seront caduques dans 6 mois plutôt que 100 lignes qui dureront 30 ans.
Le seul truc un peu relou, ce sont les tests de retours des fonctions (absence de mécanismes d’exceptions).
Pour ma part j’apprécie la rigueur de la documentation et la stabilité du bousin. Une méthode de travail qui manque à beaucoup (traumatisé par le passage de python 2 à 3 et par des collègues dont les bidouilles dégueulasses et non documentées se transforment en autant de peau de banane pour les autres…).
Et puis si le C est toujours là, c’est parce qu’en vrai, on n’a rien inventé de bien nouveau depuis en informatique… conceptuellement parlant. Les soit-disante innovations sont souvent des solutions à des problèmes que les ingénieurs se sont créés eux-mêmes (je te vois http1, 2, 3, je te vois…).
Mort aux cons !
[^] # Re: Survivor
Posté par groumly . Évalué à 3.
Franchement, ce genre de pics sans queue ni têtes n'apportent rien au débat, et tendent plutot a fermer le débat, en plus de te faire passer pour un idiot aigri.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Survivor
Posté par PR . Évalué à 2. Dernière modification le 01 mars 2022 à 19:05.
Oui, moi aussi je t’emmerde (un blasé du monde du travail et tout particulièrement de l’informatique).
Mais ne t’inquiète pas pour moi. Avec presque 10 ans d’expérience dans le milieu j’ai appris à en tirer parti. Et avec le télétravail je peux te dire que c’est un vrai put*** de bonheur absolu.
Oserais-je ? Oui. Vive le Covid!
Plus de présentéisme à la con.
Je peux ENFIN écrire mes 100 lignes de code le matin (lol en ce moment c’est plutôt 3 à la semaine, mais passons) en 1h et passer le reste de ma journée à… ben je sais pas la semaine dernière j’étais absorbé par la programmation bas niveau (donc pas du C), notamment les appels système, apprendre à faire un hello world en assembleur (et comprendre toute la logique derrière…), comprendre comment un programme est exécuté par le kernel comment il communique avec, ce que c’est le MMU, les ring CPU, etc.
Ça fait un +1 an que c’est comme ça. Je pensais vraiment me faire virer (je suis presta et je ne tiens pas à rester vu que je me fais chier grave), mais ces cons de clients veulent me garder !
Mais on s’écarte du sujet…
Mort aux cons !
[^] # Re: Survivor
Posté par PR . Évalué à 1.
Au passage, dans mon commentaire initial:
s,/etc/group,/etc/passwd,g
Mort aux cons !
[^] # Re: Survivor
Posté par Claude SIMON (site web personnel) . Évalué à 5.
Moi aussi c'est ce qui m'embêtait le plus avec le C, mais, grâce à la bibliothèque setjmp, je pouvais gérer les erreurs via un mécanisme d'exceptions proche de celui du C++… Ceci dit, cela nécessite de créer une surcouche à la bibliothèque standard si on veut pleinement profiter de ce mécanisme.
Pour ma part, comme j'ai rapidement délaissé les bibliothèques standards au profit des bibliothèques systèmes, je passais de toute manière par des bibliothèques maisons qui prenaient en charge de manière transparente la portabilité de mes programmes (merci le préprocesseur !), et j'y avais bien entendu inclus ce mécanisme d'exceptions.
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
[^] # Re: Survivor
Posté par David Demelier (site web personnel) . Évalué à 5.
C'est pas joli setjmp/longjmp. Comme disent certains “Exceptions are, in essence, sophisticated GOTO statements”.
Loin de moi l'idée de penser que les exceptions sont mauvaises, mais ça n'a pas sa place dans ce langage aussi bas niveau qu'est le C. En C++ par exemple, un simple
std::cout << "hello\n"peut lever une exception ce qui signifie que dans les programmes très critiques il faut absolument lire la documentation de chaque fonction qu'on utilise. Mais aussi, si j'utilise une bibliothèque qui ne documente pas bien les exceptions qu'elle peut lever (car elle en oublie d'une couche plus bas niveau) je risque tout simplement de planter mon programme car j'arriverai dans la gestion de l'exception peut-être là où je ne le souhaite pas. Alors devons nous protéger tous les appels de chaque fonction ?On dit aussi que les exceptions sont performantes. Ce n'est pas le cas. Une fois on a réduit drastiquement les performances d'une boucle de notre application qui était écrite de cette manière :
En
Certes une erreur d'étourderie. Mais si la fonction
something()fait aussi des try-catch à tout va, les performances sont encore une fois impactées.Pour ma part j'ai utilisé une seule fois setjmp/longjmp dans mon application (un jeu vidéo). L'idée est de faire un mécanisme de « panic » : s'il arrive quelque chose d'irrécupérable (carte corrompu, image manquante, …) au lieu de crasher l'application à la sauvage, j'affiche quelque chose à l'écran avant de quitter (un peu comme un BSOD). Mais c'est la seule utilisation viable que j'en ai.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Survivor
Posté par HL . Évalué à 3.
Je n'ai jamais entendu dire ça, même plutôt le contraire. Tu aurais une source ?
Pour le premier bloc de code, les performances sont réduites parce qu'on entre plusieurs fois dans le catch pendant la boucle ou la simple incorporation d'un bloc try/catch dans le code de la boucle suffit à ralentir l'exécution ?
(Vraies questions.)
[^] # Valve fait du C
Posté par uso (site web personnel) . Évalué à 4.
Et pourtant, valve viens de sortie Aujourd'hui son devkit pour la steam deck… En C. (bon pour la partie server, le client est en Python)
https://www.gamingonlinux.com/2022/03/valve-open-sources-steamos-devkit-client-for-steam-deck/
https://gitlab.steamos.cloud/devkit/steamos-devkit-service
[^] # Re: Valve fait du C
Posté par David Delassus (site web personnel) . Évalué à 4.
Ça ne m'étonne pas. Dans le monde du gamedev tu retrouvera beaucoup :
Godot est développé en C++ et introduit GDScript (qui ressemble a Python), et gagne en popularité. Donc charger une DLL pour étendre les fonctionnalités de l'engine n'est pas très complexe. Pareil pour GameMaker Studio.
Donc avoir un SDK en C, c'est s'assurer de pouvoir intégrer à toutes ces engines de manière assez simple.
Pourquoi le C est plus simple à intégrer que le C++ ? C'est une question d'ABI. En C++ tu as ce qu'on appelle le name mangling, donc tu peux pas juste naïvement faire un
dlopen/dlsym.https://link-society.com - https://kubirds.com
# Effeuillage de marguerite
Posté par Crag . Évalué à 10. Dernière modification le 28 février 2022 à 16:28.
J'aime beaucoup l'entrée de Brian Westley pour l'IOCCC de 1990.
Il s'agit d'une correspondance entre deux personnes écrite en C.
(char*)lie aime (char)lotte mais malheureusement leurs types sont incompatibles.
Il faudra passer le nombre de pétales au programme.
Source : https://www.cise.ufl.edu/~manuel/obfuscate/westley.hint
[^] # Re: Effeuillage de marguerite
Posté par nico4nicolas . Évalué à 4.
Il sera préférable de faire un impair.
# Encenser le C? Non!
Posté par reno . Évalué à 5.
Je préfère le C au C++ pour ce qui est du temps réel (le C++ 'cache' trop de choses) mais ça ne veut pas dire que j'aime le C..
Conversion implicite stupides.. Chaînes terminées par des zéros == attention aux algorithme quadratiques!
2 languages au lieu d'un: le preprocesseur et le normal..
Cast non-greppable..
Trop d'UB qui ne servent à rien: par exemple l'ordre d'évaluation des paramètres d'une fonction..
Etc.
Après Ada existe depuis longtemps sans avoir percé pour autant.. Il commence à y avoir d'autres nouvelles alternatives (DasBetterC, Zig, V, Odin..) mais leur nombre peut aussi créer un problème pour remplacer le C..
[^] # Re: Encenser le C? Non!
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 9.
Quelques exemples ?
Et en quoi est-ce un défaut ? La compilation conditionnelle est un des points forts du C, et permet de faire quantité de choses que d'autres langages auront du mal à faire. Ah, bien sûr, il faut savoir s'en servir…
Mmmmm, là, il faut que je creuse un peu, mais ça ne m'a jamais posé de souci.
En quoi est-ce inutile de préciser comment fonctionne le langage, et ce qu'il ne faut pas faire ? D'autre part, je me suis laissé dire que les UBs facilitent bien l'écriture des compilateurs. Ah, bien sûr, il faut en connaitre la liste…
Je pense que si, il a bien percé, mais dans des domaines dont la visibilité est très faible. On a rarement l'occasion de faire tourner chez soi un régulateur d'attitude d'avion de ligne, il faut juste monter dedans et espérer que ça marche.
Des langages marginaux, sur lequel il y a peu d'expérience, peu de littérature, mais ils sont à la mode ?
OK, je ne suis pas très objectif, ayant commencé le C vers 1986, ce qui biaise un peu mon jugement.
En ce moment, je découvre le Fortran moderne, c'est cool, mais il y aurait pas mal de choses à en dire aussi, ce n'est pas aussi simple que l'on croit, et les UBs semblent aussi présents, mais mal documenté, à toi de les découvrir :)
[^] # Re: Encenser le C? Non!
Posté par reno . Évalué à 7.
Le + célèbre: https://news.ycombinator.com/item?id=26296339
D'un point de vue + générique les algorithmes quadratiques sont très 'vicieux': assez rapide sur un petit jeu de donnée utilisé pour les tests unitaires mais en production ça peut déraper vite.
Il y a même un site web sur le sujet: https://accidentallyquadratic.tumblr.com/
Complexité additionnelle non nécessaire: d'autre langages tel que D, Zig, Jai utilisent le même langage au runtime et a la compilation (permettant entre autre la compilation conditionnelle bien sûr) avec juste un mot clef pour indiquer que le code correspondant doit être évalué a la compilation (comptime en Zig, je ne me souviens plus pour les autres).
Et bien tu as + de chance que moi.. Un 'XXX_cast' a la C++ ou ' as ' comme Rust(je crois) c'est beaucoup plus facile a chercher qu'une paire de parenthèse et comme un mauvais cast peut créer des tas de problèmes bien difficile a résoudre, ça n'est pas un détail!
J'ai commencé le C en 1992, j'apprécie ses points forts par rapport a d'autre langage, mais c'est un langage quasi-statique qui n'a jamais pu se débarrasser de ses nombreux problèmes..
Dommage qu'il n'ai pas pu évoluer (enfin après quand on voit le b… de l'évolution du C++..).
[^] # Re: Encenser le C? Non!
Posté par gUI (Mastodon) . Évalué à 7.
Je ne connaissais pas c'est très intéressant , merci pour le lien. Cela dit j'ai du mal à attaquer le langage lui-même qui est simple (pour pas dire simpliste), et justement ce style de "bug" est censé être facile à anticiper (
strlensur des chaînes de plusieurs Mo…).Au passage je suis allé voir le code de strlen dans la libc. C'est amusant de voir tout de même l'optimisation 32/64 bits qui a été faite (et pas une simple boucle
charparchar).Le C restant bas niveau il implique une connaissance de l'architecture de la machine, et du fonctionnement en général d'un ordinateur. Ça peut être un avantage ou un inconvénient selon les situations, mais c'est une propriété fondamentale du langage qu'on ne peut ignorer.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Encenser le C? Non!
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Eh oui, un langage d'assemblage de haut niveau …mais que les gens veulent utiliser comme du Pascal (i.e. avec des gardes fours) et venir se plaindre. C est un langage très bien mais qui n'est pas pour s'abstraire du matériel sous-jacent et autres considérations. Ses avantages sont aussi ses inconvénients : c'est un langage à double tranchant en plus d'être le plus tranchant dans son domaine.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Encenser le C? Non!
Posté par reno . Évalué à 5.
Tout les autres langages sont passés a une paire de pointeur ou a entier+pointeur pour les chaines, n'ajoutant le '\0' a la fin que si nécessaire pour la compatibilité avec le C, il doit y avoir une raison..
Et strlen en temps constant pour un cout mémoire ultra-faible est une très bonne raison!
[^] # Re: Encenser le C? Non!
Posté par gUI (Mastodon) . Évalué à 9. Dernière modification le 01 mars 2022 à 17:48.
En fait c'est surtout que le type
stringn'existe pas. Faut déjà en prendre bien conscience.En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Encenser le C? Non!
Posté par PR . Évalué à 2.
Et de fait rien n’empêche d’en faire l’implémentation la plus adaptée à son cas d’usage.
Mort aux cons !
[^] # Re: Encenser le C? Non!
Posté par Thomas Douillard . Évalué à 10.
Le C, réinventeur de roue depuis 1972 (je sors)
[^] # Re: Encenser le C? Non!
Posté par reno . Évalué à 1.
ça n'est pas vrai, un char* terminé par un '\0' ça ne s'appelle peut être pas une string en C mais les librairie la traite comme en étant une.
A l'époque des mémoires minuscules, c'était une bonne structure de donnée pour une chaine, mais ça n'est plus le cas depuis longtemps et pourtant le "C" (le langage mais surtout la librairie standard) n'a pas réussi a évoluer..
[^] # Re: Encenser le C? Non!
Posté par gUI (Mastodon) . Évalué à 10.
Perso je trouve que c'est l'inverse. Tu as peu d'assurances de comportement, si tu t'y tiens, tu seras peinard au lieu de tenter des trucs chelou qui optimisent soi-disant le code (ou la vie du codeur). Quand je vois les exemples d'UB c'est à chaque fois du code qui à la base est incompréhensible.
Pour moi le C reste de l'ASM de haut niveau et il faut vraiment s'y tenir. À chaque ligne une instruction (ok, le
i++reste une exception acceptable).Mais quand je vois des appels de fonctions qui eux-même castent des pointeurs pré-incrémentés… ouais non, c'est indéterminé et c'est tant mieux. Qu'ils séparent clairement les lignes, qu'ils utilisent des variables intermédiaires et l'ordre des instructions sera parfaitement connu. Surtout que avec les compilateurs actuels, ça ne changera sûrement rien au code final.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Encenser le C? Non!
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Est-ce encore vrai? Le code assembleur généré ressemble de moins en moins au C, le C n'a pas de construction correspondant aux instructions "modernes" (SIMD)…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Encenser le C? Non!
Posté par 2PetitsVerres . Évalué à 6. Dernière modification le 01 mars 2022 à 14:42.
Le code m'a plutôt l'air compréhensible, pourtant il y a bien un UB pour certaines valeurs de a et b (25% du domaine d'appel possible, je dirais, au pif)
Le choix de ce qu'il faut faire en cas d'overflow et l'écriture d'un code correct sans UB est laissé en exercice au lecteur :-)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Encenser le C? Non!
Posté par gUI (Mastodon) . Évalué à 2.
C'est vrai que l'overflow en général est en UB, et là j'avoue on peut le regretter (surtout que spécifier que tu tombes sur un modulo n'était pas très dur, et il me semble que c'est ce que fait à peu près tout le monde).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Encenser le C? Non!
Posté par David Delassus (site web personnel) . Évalué à 4.
Sauf que la, le comportement dépend du set d'instruction du CPU. Tu dis "tomber sur un modulo" parce que tu as l'habitude de l'instruction
adddes x86.C'est un undefined behavior justement parce que l'on peut imaginer créer un compilo pour target un CPU qui fait les choses différemment.
Le C te permet de maîtriser tout les aspects de ton programme, depuis la conception jusqu'à l'exécution.
Le undefined behavior n'est pas un bug. C'est une mise en garde au développeur pour lui communiquer qu'il est censé savoir ce qu'il fait.
https://link-society.com - https://kubirds.com
[^] # Re: Encenser le C? Non!
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Tu m'as devancé :-) Oui, en général sont bien définis des choses qui sont quasiment sûres d'être présentes partout ; sinon on dépend des spécifications du processeur ciblé…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Encenser le C? Non!
Posté par 2PetitsVerres . Évalué à 7.
Non, un programme avec un UB n'est pas un programme valide. Le développeur ne peut pas "savoir ce qu'il fait". Il n'a aucune garantie que la prochaine version de son compilateur fasse la même chose. Il n'a aucune garantie que le changement d'une option de son compilateur continuera à faire un programme qui a le même résultat. Il ne faut pas avoir d'UB en se disant "je sais ce que je fais".
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Encenser le C? Non!
Posté par David Delassus (site web personnel) . Évalué à -5.
Lorsque l'on dépend d'un undefined behavior, on lit la spec du compilo avant de le mettre à jour.
On lit la spec du compilo avant de faire joujou avec ce qui fonctionne.
C'est le principe même des Undefined Behavior.
Quand tu programme en C, tu programme en C + Compilo + CPU. C'est pour ça que tu as les mots clés volatile / register / etc… pour contrôler le comportement du compilo dans ton code.
Le C est un langage bas niveau, c'est de l'ASM avec une syntaxe moins dégueulasse. Si tu fais de l'ASM sans lire la doc de ton CPU, ton programme est certain de ne pas être valide. C'est pareil en C, que tu évite les undefined behavior ou non.
A ce moment là, le simple fait d'utiliser int rend ton programme invalide, car sa taille change selon le CPU.
https://link-society.com - https://kubirds.com
[^] # Re: Encenser le C? Non!
Posté par Krunch (site web personnel) . Évalué à 10. Dernière modification le 01 mars 2022 à 19:41.
Heu. Peut-être que toi tu fais ça mais je t'assure qu'il y a plein de gens (possiblement la majorité) qui programment en C dont l'intention c'est d'être indépendant du compilateur et du CPU. C'était un des attraits du C à la base : la portabilité.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Encenser le C? Non!
Posté par David Delassus (site web personnel) . Évalué à 1.
Et donc dans ce cas la, tu évites les undefined behavior comme j'ai dit plus haut.
Dépendre des undefined behavior ne rend pas ton programme invalide, il le rend pas portable, c'est tout.
https://link-society.com - https://kubirds.com
[^] # Re: Encenser le C? Non!
Posté par Fulgrim . Évalué à 7.
Écrire 10 lignes de C sans UB, ça demande un talent et un temps dont peu de personnes disposent. Tout langage est un compromis entre pleins de facteurs, vitesse d'exécution, compétences disponibles, coût d'implémentation, interfaçage, vitesse d'écriture, limitation des bugs, outillage, historique, envie et pleins d'autres… Le C permet des choses formidables mais il amène de gros coûts, qui se résolvent très mal avec des yakas.
[^] # Re: Encenser le C? Non!
Posté par David Delassus (site web personnel) . Évalué à 1.
Et alors ?
Il faut arrêter de voir le C comme un langage haut niveau du même type que le C++ ou Python.
Aujourd'hui, si tu as besoin des performances du C, tu y vas tout en sachant qu'il y a des footguns, et tu mets les gardes fous en place pour t'empêcher de faire de la merde.
Coder en C, ce n'est pas avoir une épée de Damoclès au dessus de la tête en plein milieu d'un champ de mine. C'est le cas si tu code sur libopenssl ou un kernel. Mais un segfault dans gimp ? Osef total, bug tracker + fix à la prochaine release.
https://link-society.com - https://kubirds.com
[^] # Re: Encenser le C? Non!
Posté par Krunch (site web personnel) . Évalué à 7.
Moi j'aime bien pouvoir ouvrir des images dans Gimp sans me faire pwner comme même.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Encenser le C? Non!
Posté par David Delassus (site web personnel) . Évalué à -5.
Comment tu peux te faire pwn avec un programme qui accède pas à internet ? Tout les échecs ne sont pas critique.
https://link-society.com - https://kubirds.com
[^] # Re: Encenser le C? Non!
Posté par fearan . Évalué à 10.
En filant une image qui va lui faire exécuter du code binaire stockée dans ladite image ?
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Encenser le C? Non!
Posté par Krunch (site web personnel) . Évalué à 5.
OK, merci tu confirmes que tu comprends pas grand chose au sujet et que j'ai rien raté.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Encenser le C? Non!
Posté par David Delassus (site web personnel) . Évalué à 0.
Il y a une différence entre :
Et
Oui, dans les 2 cas c'est des failles de sécurité. Non toutes les failles ne se valent pas en terme de criticité. Dans le cas de Gimp, soit c'est une nouvelle faille et dans ce cas tu rollback, soit c'est une ancienne et tu attends le fix.
Dans le cas d'un composant critique tel que OpenSSL ou la stack TCP du kernel, là, il y a urgence car des millions de personnes et des milliards de devices sont potentiellement en danger.
Il faut prendre en compte la taille du vecteur d'attaque quand tu évalue la criticité d'une faille. Non un buffer overflow dans Gimp qui permet l'exécution de code arbitraire n'est pas si grave. C'est pas comme si tu pouvais en faire un rootkit. L'attaque est difficile à industrialiser car il faut que tu puisse transmettre l'image vérolée à ta cible, et être sûr qu'il va l'ouvrir naïvement avec la bonne version de Gimp et que son anti-virus ne va pas détecter du code exécutable dans une image.
Mais oui, c'est vrai, je ne comprend rien au sujet, je suis un ignare, blah blah blah, dénigre autant que tu veux. Comportement très mature de ta part.
J'arrête de débattre avec des sourds, tchao.
https://link-society.com - https://kubirds.com
[^] # Re: Encenser le C? Non!
Posté par octane . Évalué à 8.
bin, un peu quand même?
Un rootkit, c'est la suite de "l'exécution de code arbitraire", donc bah si. Et comme aujourd'hui 99.9% des ordis sont connectés à internet, le rootkit va se connecter à son C&C et attendre les commandes.
un mail, et hop!
Pas forcément. La vuln existe peut-être depuis 45 versions de gimp et n'est pas corrigée. Il suffit que le code d'exploit soit compatible avec les versions vulnérables de gimp.
un AV? sous linux??? et "détecter du code exécutable dans une image" j'ai du mal à concevoir comment c'est possible. Selon l'encodage de l'image, tu peux avoir des suites d'octets qui peuvent ressembler fortement à de l'assembleur, mais après??
Ca, oui. Mais le rollback n'est pas toujours possible (rollback de gimp? quitte à ré-introduire des anciennes vulns patchées par la nouvelle version?), et attendre le fix, c'est quand même contrariant.
Même si dans les faits, ouais une vuln dans gimp, tout le monde s'en fiche. (ImageTragick c'était autre chose)
[^] # Re: Encenser le C? Non!
Posté par Krunch (site web personnel) . Évalué à 6.
Si tu dépends sciemment de comportements non-définis pour ton programme, tu n'écris pas du C dans le sens de la norme. Tu écris peut-être du C-linkdd mais pas du C90/C95/C99/C11/C17.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Encenser le C? Non!
Posté par David Delassus (site web personnel) . Évalué à -2.
Non, comme je l'ai dit précédemment, j'écris du C + Compilo + CPU. Par exemple :
Comme quoi, faut bien lire tout dans son ensemble pour comprendre un argument.
https://link-society.com - https://kubirds.com
[^] # Re: Encenser le C? Non!
Posté par xcomcmdr . Évalué à 6.
C'est plutôt C + Compilo + ABI, et OS + CPU à l'exécution, mais bon, on est pas à ça près.
Ca reste du C dépendant de comportements qui peuvent changer selon le compilo, pas portable.
C'est cool hein, mais je préfère éviter perso.
On peut tout faire sans dépendre d'UB.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Encenser le C? Non!
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 6.
Ce que beaucoup ne comprennent pas, c'est que le standard au début (89 et 90) n'
a fait qu'entériner un certain nombre de pratiques courantes (histoire que la no
rme de fait devienne un standard de référence pour de nouveaux entrants, et au p
assage graver dans le marbre une spécification qui n'existait pas vraiment… Les
créateurs ont écrit un ouvrage de référence et laissé une implémentation mais ja
mais écrit formellement les spécifications.) En aucun cas le standard n'a jamais
supposé une certaine architecture, contrairement à d'autres compilateurs… Ainsi
, Wikipedia en anglais rappelle clairement :
La portabilité du langage est en fait que c'est un macro assembleur (l'usage du C permet de ne pas avoir à se battre avec les différentes syntaxes d'assembleur pour la plupart des cas) dont le code de compilateur est assez petit et adaptable aux diverses plateformes. Si, avec les registres de ton CPU ton
intest de 20 bits et tonlongde 60 bits pas de souci. :-DAvec l'évolution, le standard met des barrières à minima…
C'est là par exemple une des barrières parce-qu'il ont estimé que c'est le minimum auquel on a pu descendre dans les années 80 (on ne parle pas des ALU qui peuvent être de 4 comme sur Saturn ou Zilog 80). Si un fondeur fait moins, il ne pourra pas utiliser le C standard (dont on a là une limite de portabilité) :-D
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Encenser le C? Non!
Posté par 2PetitsVerres . Évalué à 1.
Non, c'est simplement un implementation defined behaviour. Le standard impose de documenter la taille des entiers, et elle doit être cohérente. Un programme qui utilise un int est valide. Un programme dont un chemin d'exécution amènerait à un UB est un programme qui n'est pas un programme C valide.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Encenser le C? Non!
Posté par 2PetitsVerres . Évalué à 5.
"en général" non, l'overflow est défini dans le cas des entiers non signés. L'addition/soustraction des non signés est modulo UTYPE_MAX (j'avoue que je ne sais plus pour la multiplication :-) ), c'est uniquement les signés qui sont indéfinis.
De mémoire gcc (et surement d'autres) a une option pour forcer l'arithmétique "modulo" (ça n'existe pas vraiment en math pour les nombres signés, il me semble) pour les signés aussi, mais en fait personnellement dans ce que je fais, je n'ai la plupart du temps pas envie que (a+n) < a, pour un n positif. C'est plus souvent une erreur qu'un truc que je désire (je sais qu'en crypto, par exemple, c'est courant de vouloir que ça soit le cas)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # M'sieur m'sieur c'est quoi un algorithme quadratique ?
Posté par Toufou (site web personnel) . Évalué à 3. Dernière modification le 01 mars 2022 à 11:10.
Juste comme ça c'est quoi un algorithme quadratique ? Ça pique ma curiosité genre youpie un truc dont je n'ai jamais entendu parler !
En cherchant rapido je tombe sur de l'optimisation quadratique, du crible quadratique, du quadratic sorting algorithm, du O(n2) mais pas d'algorithme quadratique. Tu parles d'un de ces cas ou est-ce une approche particulière ne rentrant pas dans ces cases ?
Du coup aurais tu un exemple ou une doc sur ce qu'est un algorithme quadratique STP ?
Ma curiosité te remercie ! (mais je sens que je vais prendre un autre aspro à lire ta doc ,) )
Edit : de ce que je lis là : https://accidentallyquadratic.tumblr.com/ , tu parles d'O(n2), tu confirmes ?
[^] # Re: M'sieur m'sieur c'est quoi un algorithme quadratique ?
Posté par reno . Évalué à 9.
Un algorithme de complexité quadatrique O(n2), l'explication classique toute simple est le gars qui peint une bande routière en laissant le seau de peinture au début de la route: le premier jour il va vite, mais au fur et à mesure il va aller beaucoup moins vite forcément..
# Et pourtant les spécifications ne sont pas libre
Posté par abriotde . Évalué à 5. Dernière modification le 02 mars 2022 à 10:46.
Aussi incroyable que cela puisse paraître aujourd'hui, alors que n'importe quel language est sous spécifications libre (y compris dans les languages des Gafam), alors même qu'il est très prisé dans les projets open-source (que ses principaux compilateurs sont libre), les spécifications du C (et du C++) sont fermés et qui plus est très cher.
[^] # Re: Et pourtant les spécifications ne sont pas libre
Posté par rewind (Mastodon) . Évalué à 7.
Et paradoxalement, la plupart des langages avec des spécifications libres n'ont qu'une seule implémentation, là où C et C++ en ont des dizaines.
Concernant C++, la spécification finale n'est pas libre, mais la version bêta juste avant la spécification finale est disponible. Par exemple, pour C++20
[^] # Re: Et pourtant les spécifications ne sont pas libre
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 5.
Et en dehors du "la plupart", y a Ada… Enfin presque :)
Le manuel de référence Ada est libre d'accès mais pas libre au sens que l'on entend ici et plusieurs implémentations, libre et non libres coexistent à commencer par GNAT, le frontend Ada pour GCC qui existe en version libre et en version commerciale.
[^] # Re: Et pourtant les spécifications ne sont pas libre
Posté par claudex . Évalué à 4.
Il y a des dizaines d'implémentation de C17? Parce que j'ai l'impression que tous les gros passent à LLVM.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et pourtant les spécifications ne sont pas libre
Posté par uso (site web personnel) . Évalué à 2.
En implémentation complète tu doit avoir gcc, clang, icc ? et recement MSVC.
Après t'a pas mal de compilateur qui l’implémente partiellement, tcc (qui support _Generic, _Static_assert, union/struct anonyme), pcc (_Static_assert), mir (lui jamais testé) et surement plein que je connais pas ou oublie.
[^] # Re: Et pourtant les spécifications ne sont pas libre
Posté par claudex . Évalué à 4.
ICC est passé à LLVM si j'ai bien compris https://en.wikipedia.org/wiki/Intel_C%2B%2B_Compiler?wprov=sfla1
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et pourtant les spécifications ne sont pas libre
Posté par uso (site web personnel) . Évalué à 2.
Effectivement ils sont passée a LLVM en 2021, âpres leur ancien compilateur supportais aussi C11 il me semble.
Ceci dit l'implémentation de C, est pas dans LLVM, mais dans le front-end qui l'utilise, donc ICC et clang, ça reste 2 implémentations différents(en theory, ICC étais Close Source…).
sinon je suis aller voir la: https://developers.redhat.com/blog/2021/04/27/the-mir-c-interpreter-and-just-in-time-jit-compiler
et y'a une list de compilo que j'ai pas tester mais qui sont sensée gérer au moins partiellement C11:
https://github.com/rui314/chibicc
https://github.com/michaelforney/cproc
https://github.com/libfirm/cparser (qui comparer a ce que dit la description, a l'air d'au moins connaitre les mots clé de C11)
Un choses intéressante a savoir, c'est que un compilateur C11 est plus simple a codé qu'un compilateur C99, ça C11 a rendu beaucoup de choses de C99 optionnel. (c'est dalleur pour ça que MSVC ne gère pas C99).
Et C11 et C17, sont extrêmement similaire, vu que C17 c'est une version bugfix de C11.
[^] # Re: Et pourtant les spécifications ne sont pas libre
Posté par claudex . Évalué à 3.
Effectivement, j'ai fait un mauvais raccourcis. Mais, peut-on avoir deux front-end très différents pour le même langage et le même backend ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et pourtant les spécifications ne sont pas libre
Posté par uso (site web personnel) . Évalué à 2.
Dur a dire,
LLVM, comme GCC ont une Architecture très similaire qui ressemble grosso mode a:
[Front-end] -> [SSA Tree Form] -> [Back End]
Le Front-End, c'est ce qui convertie le Code C en SSA-Tree (LLVM-IR soue clang, GIMPLE soue GCC), c'est donc tout le parser.
Le Middle-end, qui utilise une SSA Tree form dans le cas de LLVM/GCC, c'est la partie qui va être optimisé.
Le back end prend la form SSA Tree et la convertie en binaire (bon sauf gcc, qui convertie les GIMPLE en RTL qui est une autre représentation intermédiaire).
Je suppose que le code entre 2 parser C qui target LLVM-IR peuvent avoir des architecture différents, mais en soie ça reste le même job.
Âpres ICC étant close source, c'est pas impossible qu'il ai modifier le middle-end et le back-end aussi.
[^] # Re: Et pourtant les spécifications ne sont pas libre
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
Tu parles de ceci ? http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Et pourtant les spécifications ne sont pas libre
Posté par Krunch (site web personnel) . Évalué à 2. Dernière modification le 04 mars 2022 à 17:20.
Techniquement c'est pas la spec, c'est un brouillon de spec (et je suis même pas sûr que quelle version de C). Le brouillon final est généralement suffisant pour la plupart des gens. Mais, comme toutes les specs ISO, ça reste pas libre dans le sens FSF.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Et pourtant les spécifications ne sont pas libre
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Tu as raison, c'est pas la spec finale. et c'était C99 si j'ai bonne mémoire. Me semble aussi que les entreprises adhérentes ont accès gratuitement aux specs (mais bon l'adhésion n'étant pas bonbon, c'est une compensation ou privilège de membres que je comprends.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.