Le C poste-il problème ? - Page 1

Uther a souhaité poursuivre une discussion dérivée dans un nouveau sujet. La discussion initiale a eu lieu dans le sujet topics/196681-c-zero-le-c-a-godzil/2#post-39 tandis que la discussion dérivée continue dans le sujet topics/196742-le-c-poste-il-probleme où les messages en rapport ont été copiés.

c'est exactement ça le C, liberté et contrôle, fonce dans l'arbre si tu veux :- D

Liberté oui, contrôle pas vraiment. Une particularité du C, c'est justement qu'on ne contrôle plus rien quand on déclenche un comportement indéfini. Une voiture qui fonce dans l'arbre, on sait comment ça va se finir. Un comportement indéfini peut aussi bien être sans conséquence visible et passer inaperçu que potentiellement catastrophique.

donc vous ne faites aucune confiance aux devs

avec la culture du moindre risque on va donc sur le même principe interdire par exemple toutes les voitures non autonomes ?

C'est pas ne pas faire confiance aux dev que d'être conscient de leur limites et de celles des technologies qu'ils emploient.

certes ça peut arriver à tout le monde mais taper une case trop loin sur un pointeur c'est généralement un truc de stagiaire ...

avoir un langage plus blindé accrédite encore plus le fait de coder en permanence les choses pour avant hier au lieu de prendre le temps nécessaire

Hum viens dire ça quand tu reçois un report de SEGA que ton jeu crash sans vraiment savoir où / pourquoi et après combien de temps, et que t'es 1-2 mois avant la release commerciale. Ptet qu'il y avait un stagiaire dans l'équipe (ça ne devrait pas exister dans cette industrie ?) ou un Yuji Naka qui a fini un red bull* de trop avant de s'affaler sur le sofa de l'entrée du bureau.

*Enfin un リボビタンD.

prendre en exemple une période ou tout était écrit en ASM pour défendre Rust est improbable :- D

je dis juste que c'est un classique, devant donc être l'objet d'une attention particulière d'un dev aguerri, on connaît les pièges ..

est ce que ça mérite une obligation de changer de langage car "ça peut arriver" ? pas à mes yeux.

Je ne sais pas ce que tu code, mais certains UB du C/C++ sont facile a declancher et ce n'est pas qu'une question d'experience.

Le C est vraiment traitre sur le sujet.

Et c'est aussi tres vite fait d'avoir du code qui marche marche marche jusqua ce qu'un bug traitre apparaisse et quand tu as des millions de lignes a regarder, c'est pas forcement si simple.

Perso, même si comme tous les développeurs je fais du code parfait et sans le moindre bug, je ne crache jamais sur les aides automatiques de ce type

Oui, parce qu'on n'est jamais à l'abri de devoir une fois bosser avec des gens moins bons que soi

robinHood (./5255) :
certes ça peut arriver à tout le monde mais taper une case trop loin sur un pointeur c'est généralement un truc de stagiaire ...
avoir un langage plus blindé accrédite encore plus le fait de coder en permanence les choses pour avant hier au lieu de prendre le temps nécessaire

Il n'y a malheureusement pas que les stagiaires qui déclenchent des UB. Ca arrive tous les jours à des gens très compétents.
Il ne faut pas croire que le développeur C est une espèce mythique qui a toujours le temps de faire bien les choses alors que les autres non. Les contraintes de temps alloué à la qualité dépendent du besoin perçu sur le sujet par les responsables, pas du langage utilisé par le développeur. Alors si le langage peut l'aider au passage, c'est toujours bon a prendre
Pour rester dans le domaine automobile, on sait bien que mettre ta ceinture de sécurité ne fait pas de toi un plus mauvais conducteur, parce que tu te sentirais mieux protégé, au contraire.

robinHood (./5258) :
je dis juste que c'est un classique, devant donc être l'objet d'une attention particulière d'un dev aguerri, on connaît les pièges ..

On peut connaître le piège et quand même tomber dedans, s'il est particulièrement bien caché ou si on manque exceptionnellement d'attention, ce qui peut arriver à tout le monde même aux meilleurs. Le nombre de faille de sécurité qui sont découvertes tous les jours, y compris dans des logiciels sérieux niveau sécurité, en est la preuve éclatante.

robinHood (./5258) :
est ce que ça mérite une obligation de changer de langage car "ça peut arriver" ? pas à mes yeux.

Personne ne dit qu'il faut absolument réécrire tout le C existant en urgence.
Juste qu'il faut bien être conscient des risques et surtout ne pas dire : "Nous on est bons, ça ne nous concerne pas."

> Il n'y a malheureusement pas que les stagiaires qui déclenchent des UB. Ca arrive tous les jours à des gens très compétents.

mais c'est rare, non ce n'est pas tous les jours, "généralement" ton programme plante direct, et tu dois tester ton code
si c'est ultra planqué c'est aussi peut être que la structure n'est pas assez simple ou lisible

> Il ne faut pas croire que le développeur C est une espèce mythique qui a toujours le temps de faire bien les choses alors que les autres non. Les contraintes de temps alloué à la qualité dépendent du besoin perçu sur le sujet par les responsables, pas du langage utilisé par le développeur. Alors si le langage peut l'aider au passage, c'est toujours bon a prendre

non c'est l'inverse, ce n'est pas le C qui à plus de temps c'est l'autre qui en aura moins "le langage est safe, donc bat lec code deux fois plus vite"

> On peut connaître le piège et quand même tomber dedans, s'il est particulièrement bien caché ou si on manque exceptionnellement d'attention, ce qui peut arriver à tout le monde même aux meilleurs. Le nombre de faille de sécurité qui sont découvertes tous les jours, y compris dans des logiciels sérieux niveau sécurité, en est la preuve éclatante.

oui, "c'est possible, ça arrive" et donc ?

la trisomie arrive => go le 100% éprouvette
planter ton c15 au bout de 8 ans arrive => go 100% voiture autonome
les dépassement de tampon arrivent => go interdire le C et tout réécrire

il n'y a jamais eu de fin du monde jusqu'ici, mais pour le coup ça a permis de hacker la plupart des consoles, téléphones, ou votre Ti

au contraire de ce que transpire vos réponses, je ne me prétend pas meilleur, loin de la
c'est juste qu'en réalité en voulant interdire les pointeurs vous attaquez frontalement ma méthode personnelle de dev (et vous enlevez le fun absolu)
généralement je n'utilise pas de for ni de variable intermédiaire, je calcule les adresses de fin et fais des while, partout, bref calculer la fin d'un buffer c'est mon quotidien
(tester mon code derrière est obligatoire et en profondeur (sans jamais avoir écrit un seul test unitaire, tout au printf, flagellez moi)) alors bien sur je dois en laisser passer, mais c'est rare, dois je alors donner la main à autre chose qui va wrapper mon code ? non.

on dirait que le langage est le graal et va vous éviter tous les bugs du monde, vous faites la révolution et foutez à la poubelle la référence absolue depuis 60 ans juste pour un buffer overflow de temps en temps

Il y en a aussi qui cherchent à rendre le C plus sûr, mais ça a un coût en performance que du Rust bien écrit - dont la spécification est plus explicite - n'a pas: .
Filip Jerzy Pizło est très bon dans son domaine.

robinHood (./5264) :
mais c'est rare, non ce n'est pas tous les jours, "généralement" ton programme plante direct, et tu dois tester ton code
si c'est ultra planqué c'est aussi peut être que la structure n'est pas assez simple ou lisible

Je ne voulais pas dire que ça arrive à tout le monde plusieurs fois par jours, mais que des failles de sécurité liées à ça sont découvertes tous les jours dans les logiciels les plus sérieux sur la sécurité, donc ça n'est clairement pas qu'une affaire de débutant.
Tu as peut être la chance de travailler sur du code simple, mais ça n'est malheureusement pas toujours le cas. On ne maîtrise pas toujours tout le code sur lequel on travaille, et le langage C ne rend pas forcément la base de code que tu hérites meilleure, loin de là.

robinHood (./5264) :
non c'est l'inverse, ce n'est pas le C qui à plus de temps c'est l'autre qui en aura moins "le langage est safe, donc bat lec code deux fois plus vite"

Ca dépend peut-être des sociétés, mais je peux te dire que c'est pas du tout ce que je constate. J'ai vu beaucoup plus de projets Java avec des politiques de qualité sérieuse que des project C ou C++.
Le sérieux dépend vraiment des moyens qu'acceptent d'y mettre les responsables. Et souvent quand on choisit un langage pour des raisons de sécurité, c'est justement parce qu'on s'en soucie. Quand on s'en moque, on se fiche pas mal du langage tant qu'on produit vite.

robinHood (./5264) :
la trisomie arrive => go le 100% éprouvette
planter ton c15 au bout de 8 ans arrive => go 100% voiture autonome
les dépassement de tampon arrivent => go interdire le C et tout réécrire

Au risque de me répéter : Personne ne dit qu'il faut absolument réécrire tout le C existant en urgence. Juste qu'il faut bien être conscient des risques et surtout ne pas dire : "Nous on est bons, ça ne nous concerne pas."
Toute technologie comportes des risque sur différent points à différents niveaux : il faut juste bien les évaluer et prendre les décisions en conséquence. On ne va bien sur pas récrire sans raison un code de qualité, utilisé dans un domaine pas particulièrement risqué.
Par contre quand on construit un nouveau langage, ça serait dommage de ne pas prendre en compte la sécurité, autant que possible au vu des objectifs.

robinHood (./5264) :
c'est juste qu'en réalité en voulant interdire les pointeurs vous attaquez frontalement ma méthode personnelle de dev (et vous enlevez le fun absolu)
généralement je n'utilise pas de for ni de variable intermédiaire, je calcule les adresses de fin et fais des while, partout, bref calculer la fin d'un buffer c'est mon quotidien

Encore une fois on n'impose rien a personne, on dit juste qu'il faut être conscient des problèmes potentiels.
Oui le C pose des risque supplémentaires comparé à d'autres langages, et si tu peux faire avec tant mieux pour toi, utilise le. Par contre, quelqu'un qui dit que le C ne pose pas de risque voire permet de le réduire m’inquiète.

robinHood (./5264) :
on dirait que le langage est le graal et va vous éviter tous les bugs du monde, vous faites la révolution et foutez à la poubelle la référence absolue depuis 60 ans juste pour un buffer overflow de temps en temps

On parle du langage parce qu'on est sur le sujet des langages, mais bien sur que ce n'est qu'un élément parmi d'autres. Et encore une fois on ne dit pas de mettre tout le C existant à la poubelle.

Heureusement que les commandes de vol des avions ne sont pas écrits en C... heu si en fait. (Ok je sors).

Certes, mais en général ce genre de logiciel est fait avec des niveaux de vérifications qu'on applique pas sur la très grande majorité des logiciels C.

quel risque d'erreur ? tu as déjà oublié un break et t'en serais rendu compte trois mois plus tard ?

c'est comme ça que ça fonctionne c'est tout, il faut arrêter de voir tout voir comme un problème éventuel lol

ça frôle l'obsession, à te lire personne ne sais marcher et tout le monde doit donc utiliser un youpala

robinHood (./33) :
quel risque d'erreur ? tu as déjà oublié un break et t'en serais rendu compte trois mois plus tard ?

En effet, ça m'est arrivé de l'oublier et je m'en suis toujours rendu compte assez vite. Mais j'ai déjà du reprendre du code de quelqu'un à qui ça avait échappé car c'était dans un cas particulier rare.
Après, tout n'est pas forcément grave, mais quand on a une méthode qui permet d'éviter l'erreur et de faire plus clair, autant la prendre.

on peut pourquoi pas ajouter dans la boucle des outils d'analyse de code avec des warnings levés en cas de suspicion du style, ou utiliser l'ia pour analyser le code (et les débordement mémoire ça devrait être efficace dessus) mais bannir le C c'est un peu vener

Pour la énième fois on ne parle pas de bannir le C, mais de ne pas reproduire bêtement ses défauts quand on fait un nouveau langage.

disons que quant tu as déjà dit deux fois qu'il n'est pas urgent de tout réécrire je comprend qu'il faut donc à terme tout réécrire, soit fuck off le C

ensuite effectivement éviter des erreurs classiques à la con en faisant un nouveau langage, oui clairement, mais la franchement concernant le C si tu me demande ben je n'en vois pas véritablement :/ et j'ai touché mes premières lignes de C il y a plus de 25 ans ...

(après une adresse ne me fait pas peur, de l'alignement c'est la base, inverser les bitfields ça pète les couilles, des defines locaux ça serait vraiment top etc etc rien de ouf ou non classique, et rien ne justifiant de changer de langage)

J''ai pris le cas extrême comme exemple, mais bien sûr qu'il n'y a pas un complot anti C comme on en a l'impression quand on te lis. Et si je je me suis amusé à la répéter mot pour mot c’était juste pour noter que tu n'en avais absolument pas tenu compte. Si tu lis vraiment de mes messages, c’est plutôt clair que je ne dit pas que tout le C doit être remplacé.
Certes, je penses qu’un autre langage que le C serait souhaitable dans la plupart des situations, mais le gain ne vaut souvent pas le coût d’une réécriture. Et surtout, chacun reste libre d’utiliser le langage qu’il veut.

Vu son omniprésence le C n’est pas près de disparaître, le COBOL est encore bien présent dans ses domaine historique alors que ça fait plus de 30 qu’il est passé de mode. Ne t’inquiète pas tu pourras faire toute ta carrière avec si tu le veux, et il en restera certainement après ta mort.

on va dire que l'on répond tous de manière variable mais dès la première fois j'ai lus "il n'est pas urgent de tout réécrire donc je comprend qu'il faut donc à terme tout réécrire"

c'est aussi qu'un code mainte fois éprouvé dois rentrer dans ta whitelist ?

mais sérieusement Rust produit un truc genre vraiment éprouvable sans te poser de questions ? c'est assez louche pour s'en poser non ?

désolé godzil d’accaparer ton sujet, après d'un coté remettre en question lui ou un autre c'est déjà l'éprouver justement

robinHood (./39) :
on va dire que l'on répond tous de manière variable mais dès la première fois j'ai lus "il n'est pas urgent de tout réécrire donc je comprend qu'il faut donc à terme tout réécrire"
c'est aussi qu'un code mainte fois éprouvé dois rentrer dans ta whitelist ?

J'y ai déjà répondu, mais je vais le reformuler pour être clair : réécrire une base de code qui ne pose pas de problème particulier est rarement une bonne idée.

En général on fait ça uniquement si on a des problèmes fondamentaux à résoudre, pas juste pour changer de langage. Dans le carde d'une réécriture nécessaire, il peut en effet être opportun de se poser la question de changer de langage vu que le coût de la réécriture sera a payer de toute façon. Mais si on a une grosse base de code de bonne qualité, on ne va pas attaquer une réécriture.

robinHood (./39) :
mais sérieusement Rust produit un truc genre vraiment éprouvable sans te poser de questions ? c'est assez louche pour s'en poser non ?

Rust n'est pas magique, bien sur qu'il ne pourra pas grand chose pour les erreurs logiques, mais il va empêcher une grande partie des erreurs techniques ce qui est quand même bon a prendre. Plus des 2/3 des failles critiques des gros logiciel C rentrent dans les catégories Buffer Overflow, Use after free, Double free, Uninitialized memory ou Data Race ; ce sont des erreurs qui ne peuvent pas arriver accidentellement en Rust.

Par contre, je ne suis pas sur que le C poste.. sur le forum, apres il y a probablement une lib pour ca!