Bonjour Nal !
Dans son article Should you learn C to “learn how the computer works”?, Steve Klabnik nous narrait des éléments de l'histoire du C standard ainsi que sur la distinction subtile entre sa "machine abstraite" et d'un côté une machine concrète, de l'autre une machine virtuelle visant encore plus de portabilité (e.g. la JVM).
Début Octobre il remet le couvert sur ce thème et précise avec “C is not how the computer works” can lead to inefficient code.
Les deux articles sont intéressants en soit et je recommande leur lecture.
Et j'en profite pour tenter de lancer un petit débat sur LinuxFr sur un thème lié : vers où le C++ va, et est-ce une position utile et tenable à long terme ? (oui Steve parlait du C, mais je vais focaliser un peu plus sur le C++, vous allez voir pourquoi, même si le C suit le mouvement et que donc je désigne en fait un peu les deux—par la suite j'écrirai simplement C++) Concernant le "long" dans "long terme", je précise tout de suite que non, je ne crois pas que le C++ va mourir en 10 ans ni même en 20 quels que soient ses défauts, mais que le Cobol non plus n'est toujours pas mort aujourd'hui, et ne va pas mourir non plus.
Le C++ a effectivement été normalisé en décrivant une machine abstraite. Mais ce qui n'était au début qu'un élément de langage servant à permettre l'expression effective du standard (devant par définition entre autre préciser un dénominateur commun) est rentré depuis au cœur des compilateurs et plus précisément dans les passes d'optimisations, conçues dès lors principalement pour répondre aux spécifications de la machine abstraite et guère au-delà, même potentiellement dans des cas tordus engendrant des risques ("exploitation" des UB, c'est à dire optimisations très avancées par hypothèse de leur absences). Ces risques sont non seulement de plus en plus amplifiés avec l'augmentation de la visibilité des compilos (par exemple le LTO), en plus d'être d'une nature particulièrement problématique de base dans un monde à la connectivité réseau déjà ultra étendue et continuant à croître. Ils existent d'une manière ambiante dans ces langages et donc potentiellement dans le code écrit avec (d'une manière toute aussi ambiante : pas de section safe/unsafe), étant donné le peu d'analyseurs statiques fiables et l'indécidabilité du problème dans le cas général (même si on peut restreindre les programmes sources acceptés pour l'analyse pour éviter ce risque, mais à quel point ? et quel est alors l’intérêt face à un langage qui incorpore de base les "restrictions" et l'analyse qu'elles permettent ?).
Même de relativement récents ajouts dans le C++ n'inversent pas la tendance - au contraire - malgré : 1/ la fameuse efficacité des compilateurs capables de calculer des propriétés sur les variables et/ou de sortir des tests des boucles, réduisant l'impact du e.g. bound checking (à noter que ce genre d'opti peut être pratiqué d'une manière totalement non-risquée lorsque les hypothèses sont prouvées au lieu d'être simplement supposées, et à défaut certainement au moins en maîtrisant le risque fortement) 2/ l'efficacité redoutable des processeurs modernes, y compris certains relativement "légers" sur téléphone portable (ainsi hors hyper-threading le bound checking peut devenir souvent quasi-gratuit, même si le compilateur n'a pas réussi à trop l'optimiser, grâce à de l'OOO très profond et de la spéculation). Ainsi par exemple std::span ne propose même pas d'API d'accès avec indices vérifiés, ce qui est selon moi et vu ce que j'ai exposé précédemment, profondément ridicule. De plus même lorsque des API plus sûres existent, elles sont typiquement plus laborieuse à utiliser (.at() au lieu de [], value() au lieu de * ou ->), alors que les besoins en perfs sont typiquement concentrés et non pas diffus, tandis que le besoin en sécurité par défaut croit.
Et je ne parle même pas de la possibilité même d'exprimer dans ce contexte certains types de code : par exemple je ne suis pas sûr du tout qu'il soit possible d’implémenter un allocateur généraliste en C++ standard strictement conforme (+ primitives d'alloc de page auprès de l'OS, par exemple)—et si c'est possible je suis sûr que ça nécessite plusieurs jours d'études poussées de la norme (en plus de toute connaissance nécessaire sur les allocateurs)
Bref pensez-vous que le C++ fait fausse route sur ce thème (surtout en 2019…), ou que chaque cycle compte même sur du code sur lequel on ne lance pas de profileur, même lorsque ce code traite directement ou indirectement des données potentiellement manipulables, et même vu les difficultés que ça engendre auprès des programmeurs (sans compter ceux qui sont même pas au courant de ce bordel)
Et est-ce que ça va mener à sa perte dans un monde hyperconnecté ? Ou est-ce quelque chose le sauvera (les contrats peut-être ?)
Sur ce cher Nal, bon Trolldi !
# Le C++
Posté par barmic 🦦 . Évalué à 10.
Le C++ je sais pas mais toi tu es très difficile à lire. J'ai relu plusieurs fois ton texte. Je pense avoir compris le sens général, mais je suis persuadé qu'il y a des phrases dont il manque des parties ou qui ont été refacto en cours de route. Essai de faire des phrases plus courtes tu sera plus compréhensible.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Le C++
Posté par Guillaume Knispel . Évalué à 3.
Mwai j'ai écris ça trop vite c'est vrai, j'aurais du le reprendre et poster demain.
[^] # Re: Le C++
Posté par ted (site web personnel) . Évalué à 10.
Non, un troll ça se lance le vendredi.
Un LUG en Lorraine : https://enunclic-cappel.fr
# Joli lancer !
Posté par rewind (Mastodon) . Évalué à 7.
Je vais d'abord corriger une inexactitude.
Il n'y en a pas parce que dans quelques temps (probablement C++23), il y aura les contrats qui permettront de vérifier les indices au bon endroit (c'est-à-dire dans le code appelant puisqu'avoir un bon indice est une pré-condition). Donc, le comité a décidé de ne pas ajouter une fonction (genre at) qui ne servira plus à rien bientôt.
Sur le reste, je ne vois pas trop où tu veux en venir. C++ évolue aussi dans le bon sens. Par exemple, les entiers sont dorénavant considérés comme étant codés en complément à 2, ce qui était une scorie de l'époque où C a été standardisé. Depuis C++11, il y a un modèle mémoire pour faire du multithread.
Sur les analyses statiques, il y a tout un tas d'outils et il y en a de plus en plus tous les jours. Par exemple on a la technique proposée par Herb Sutter qui est le chef du comité de normalisation, cette technique qui permet de faire des vérification sur l'utilisation de la mémoire est déjà implémenté dans clang. Certes, ce n'est pas au niveau de certains autres langages mais c'est un bon pas en avant.
Après, il ne faut pas se leurrer, C++ n'est pas fait pour être un langage «safe». Il est utilisé dans des contextes où, justement, le fait de pouvoir faire des choses à la limite du raisonnable est une fonctionnalité indispensable.
Quant à la mort prédite de nombreuses fois de C++, je pense qu'il suffit de regarder la courbe du nombre de papiers soumis à chaque réunion du comité de normalisation ou du nombres de présents à ces réunions (ça monte en flèche depuis 10 ans) pour se dire que c'est un langage bien vivant et en pleine forme (et en pleine ébullition). Le comparer à COBOL est un joli troll.
[^] # Re: Joli lancer !
Posté par Guillaume Knispel . Évalué à 2.
Ça laisse quand même au minimum entre 2020 et 2023 sans solution sérieuse.
Mais on reste en UB sur overflow. Non plus pour les raisons historiques de l'UB (difference entre 2 procs), mais bien uniquement pour les raisons postmodernes : "opti" (avec les guillemets pour indiquer que c'est avec la technique des transformations valides uniquement sous hypothèse, typiquement non prouvée, d'absence d'UB). Après étant donné l'impact sur le codegen des indexations sur x86, peut-être que cette opti là c'est une des rare que je "veux" peut-être (en compromis)—mais faudrait voir si on peut pas prouver les non débordements au lieu d'en faire l'hypothèse, ainsi que bencher avec/sans. Il y a des bases de code majeures (ex : Linux) qui compilent en fno-strict-overflow ou fwrapv, donc probablement que c'est pas si crucial que ça, en fait.
Et il est extrêmement bienvenue, même si on arrivait à faire du multithread avant. Tout comme on arrive à faire de la shm ou du mmap aujourd'hui, alors que dans la machine abstraite c'est pas officiellement prévu. C et C++ avaient ce statut spécial nécessaire pour les langages systèmes ; la norme + ce qui est nécessaire pour écrire de vrai programmes sur de vrais plateformes. La tendance postmoderne des implémenteurs est beaucoup plus de se contenter de la norme et d'ignorer tous les problèmes concrets que cet extrémisme engendre (et rejeter la faute sur les utilisateurs du compilo au lieu d'améliorer la qualité d'implémentation).
Justement. S'il refuse obstinément de prendre raisonnablement ce tournant, mon hypothèse c'est qu'il va passer de statut de langage système absolument majeur à celui de langage de niche. Et encore. Vu que j'arrive même pas à coder d'allocateur avec sans faire 42 UB formelles par ligne, j'ai du mal à voir quel niche il va finir par occuper : jeu vidéo offline, peut-être. Hm même ça, ça n'existera bientôt plus trop.
[^] # Re: Joli lancer !
Posté par rewind (Mastodon) . Évalué à 9.
assert, c'est pas fait pour les chiens, hein.Sur overflow des entiers signés. En non-signés, l'overflow est très bien spécifié (ça revient à 0). Et tu peux ne pas avoir d'UB avec un flag du compilo (que tu donnes d'ailleurs).
Il y a plein d'autres exemples de trucs qui sont UB mais qui sont utilisés en permanence par tout un tas de gens, y compris dans la bibliothèque standard. Ce papier montre quelques exemples assez éloquent autour du thème de la création d'objet (au sens C++, c'est-à-dire objet mémoire). Pour moi, on est encore très largement dans le mode «la norme + ce qui est nécessaire pour écrire de vrai programmes sur de vrais plateformes».
Mais ils l'assument complètement, depuis très longtemps. Les racines de C++ ne sont pas celles-ci et ils priorisent d'autres aspects de la programmation. Et c'est tant mieux. D'autres langages existent avec d'autres pré-requis pour d'autres contextes, c'est très bien. En attendant, contrairement à ce que tu laisses entendre, C++ va très bien merci. C'est peut-être juste toi qui préfères autre chose que ce que C++ a à offrir. Ce n'est pas très grave.
[^] # Re: Joli lancer !
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
L'acronyme n'apparaît nul part dans le journal ou dans les liens mentionnés, ou précédemment dans la discussion. J'imagine qu'il s'agit de comportement indéfini/undefined behavior (UB) vu le contexte.
# Performances vs. Sécurité
Posté par Colin Pitrat (site web personnel) . Évalué à 4.
C'est un point qui me paraît effectivement très dommage dans le design du C++. Ecrire du code fragile est rendu plis facile qu'écrire du code robuste. On peut comparer à Rust qui opte pour la sécurité par défaut et permet d'ôter certaines protections en les identifiants clairement (unsafe, type dédiés, etc …).
[^] # Re: Performances vs. Sécurité
Posté par Firwen (site web personnel) . Évalué à 4.
C'est deux approches opposé:
La première approche fait confiance au compilateur, la deuxième approche fait confiance au programmeur.
J'aurai tendance à dire que la première approche (Rust) semble plus logique sur le papier et plus approprié à du développement où la sécurité compte.
Mais à en croire pas mal de retours de blogueurs, l'approche de Rust peut aussi se révéler passablement pénible quand le modèle mémoire ne s'y prette pas ( Graph avec multitude de relations mutuelles ( https://blogs.dust3d.org/2019/03/13/why-i-rewrote-the-mesh-generator-of-dust3d-from-rust-to-cplusplus/ ) ) ou quand obtenir la performance requise s'associe avec se battre avec la bound checking du compiler ( https://www.reidatcheson.com/hpc/architecture/performance/rust/c++/2019/10/19/measure-cache.html )
[^] # Re: Performances vs. Sécurité
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
L'autre problème plus subtil est que c'est une mauvaise idée de se dire "pas besoin de programmeurs compétents pour ça, le langage s'occupe de tout".
Souvenons-nous que des gens ont réussi à faire des trucs unsafe en Ada et que ça a fini par la destruction de la première fusée Ariane 5.
Il vaut mieux savoir que le langage de programmation utilisé ne nous sauvera pas et que dans tous les cas il faut aussi faire confiance au programmeur. Et, cependant, lui donner les outils pour faire son travail correctement.
[^] # Re: Performances vs. Sécurité
Posté par barmic 🦦 . Évalué à 8.
En même temps personne ne dit ça. Ce qui est dit c'est qu'il est déjà suffisamment complexe d'éviter le bugs pour s'outiller pour en limiter. Pour ça il est possible :
Tu as trouvé un bug médiatisé avec Ada ? Combien de bug par an arrivent à cause d'un buffer overflow ? Choses qu'on sait supprimer depuis plusieurs dizaines d'années. En tant que développeur je ne suis pas fier que l'industrie à la quelle je fais parti n'arrive pas à éradiquer ce genre de choses. Le buffer overflow c'est surtout pour du C ou C++, mais le déréférencement de valeur nulle on en a presque partout et on a même des langages qui viennent d'arriver qui continuent d'avoir ce problème ou qui se satisfont de le corriger en partie. Alors qu'on sait supprimer cette forme d'erreur.
Quand on peut avoir un code qui prouve l'inexistence de certains bug ça vaudrait le coup qu'on arrête de faire les flemmards en se trouvant des excuses.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Performances vs. Sécurité
Posté par Firwen (site web personnel) . Évalué à 10.
Tu m'excuseras, mais ça c'est une vision idéaliste ou d'académique ( même si sur ce fond je suis d'accord avec toi ).
Il y a des raisons à la dégeulasse-itude ambiante des softs, et ça n'a rien à voir avec les solutions techniques pour éviter ça. Les solutions techniques, elle existent depuis 3 décades, et rien n'a changé.
Les raisons du bordel et de la tristesse de la situation sont simple:
Et Le résultat c'est :
Que le code en C embarqué de ta voiture a été fait à la va vite. probablement par trois équipes différentes en Inde. Et que ni toi, ni même la NASA n'arriverait à la comprendre ( http://www.safetyresearch.net/blog/articles/toyota-unintended-acceleration-and-big-bowl-%E2%80%9Cspaghetti%E2%80%9D-code ).
Que > 300 personnes ont perdu la vie dans un 737 MAX parce que Boeing a trouvé bonne l'idée de faire une rustine logiciel dégeulasse développé par une team externalisée pour régler les problèmes d'un avion vieux de 30 ans.
Que la plupart des sites web que tu visites sont des blobs infames en JS fait à la va vite qui shippent 3MB de JS, car ils ont été fait par une team sous dimensionnés de développeurs "full stack" qui ont produit ça à la va vite à grand coup de NPM.
Que la première action des jeux vidéos que tu achètes de nos jours est de faire une mise à jour de 25GB avant même de se lancer car l'équipe de dev était tellement sous pression qu'elle a a sorti un produit baclé et inachevé pour respecter les deadlines.
Et des exemples du genre, je suis sur que les gens ici peuvent m'en rajouter une 20eme facilement.
Le problème de la sécurité logiciel, c'est un problème avant tout humain et surtout un problème de management.
Tant que la politique ambiante sera "délivre aussi vite que tu peux, le lifetime, l'architecture et la maintenance on s'en fou, il nous faut un MVP", ça restera comme ça et ça n'a rien à voir avec un problème de "flemmard", c'est encore une fois, un problème de management.
[^] # Re: Performances vs. Sécurité
Posté par fearan . Évalué à 10.
Tu peux ajouter dans la liste
Dans tout ça des problème de buffer overflow? en dev oui, en prod, pas depuis que je suis sur le projet. Par contre on a eu de la corruption mémoire pour mauvaise utilisation des threads, des calculs qui oscillent et ne rendent pas la main, oom killer parce que travailler sur 96 réseau en même temps ça passe pas, des fuites mémoire en java,
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Performances vs. Sécurité
Posté par barmic 🦦 . Évalué à -1.
Mais oui, ça n'existe pas. C'est ce qui est intéressant avec ce genre de bug, il faut les chercher pour les trouver.
La mauvaises qualité c'est toujours les autres, le système, l'air ambiant, le chat écrasé que vous avez croisé ce matin,… Vous êtes prompte à trouver des raisons externes.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Performances vs. Sécurité
Posté par fearan . Évalué à 6.
Ce qui est marrant c'est que tu prétends savoir mieux que moi les problèmes existants sur le logiciel sur lequel je travail; on travail avec des données d'entrée contrôlées et cohérente (sinon on les jettes) ; par contre allonger le temps de traitement n'est pas envisageable,
Force est de constater, que lorsque je fais une évol, j'ai tendance à retirer plus de lignes que d'en rajouter; sur fichier de 9000 lignes, j'en ai viré 3000, rien qu'en factorisant un minimum le code, et au passage gérer des cas 'oubliés' dus à la duplication sauvage; lorsqu'on a des soucis du au multi-threading, c'est bibi qu'on appel; je me bas pour remplacer les paramètre shared_ptr par des référence lorsque c'est possible, et supprimer tous les new qui trainent. J'ai fait mon lot de mauvais code par le passé, et il y a toujours du code que je trouve perfectible, mais faute de temps, on fait au mieux.
J'ajouterai que la sécurité du logiciel, n'est pas à l'ordre du jour; la liste des utilisateurs est assez limité, et que si quelqu'un est à même d'y injecter des données malveillantes, il n'a pas besoin de chercher bien loin pour faire que l'appli ne marche pas. Par contre il ferait mieux d'utiliser les autres applis à sa disposition pour foutre le chaos;
Bref le buffer overflow c'est vraiment le cadet de nos soucis.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Performances vs. Sécurité
Posté par barmic 🦦 . Évalué à -1.
Je ne prétends pas connaître ton métier, je suis quitte plutôt que d'expliquer ce qui peu être fait, tu explique ce qui ne peut pas. Tu délégue la responsabilité comme si tu n'y pouvais rien du tout.
D'autre part quand je dis que l'industrie n'arrive pas à supprimer les buffer overflow et que tu réponds que ça n'existe qu'en test et pas en prod il est logique que je te montre que factuellement, il en existe un énorme paquet qui posent des problèmes de sécurité.
Si tu es un maître codeur j'en suis très content pour toi. Sincèrement. Est-ce que tu arrive à faire des revues ou du pair programming pour éviter que ça se reproduise ? Moi j'arrive bien à avoir un processus de revue, mais j'ai du mal à m'organiser pour du pair programming par exemple et quand j'en fais c'est pas toujours très bien fais malheureusement
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Performances vs. Sécurité
Posté par anaseto . Évalué à 4.
D'un point de vue productivité, ils sont gênants, oui. Après, ça, c'est une autre question : impact de ces bugs au niveau productivité ; faudrait voir si des études ont été faites.
Par contre, d'un point de vue sécurité, il n'y a pas eu que des approches « langage » pour réduire l'impact de ces bugs, il y a eu aussi des évolutions prenant des approches différentes, comme la mitigation de ces bugs au niveau OS. Les deux approches ont leurs avantages et désavantages. Mais il faut se rappeler qu'un buffer overflow, sur un OS prenant la sécurité au sérieux, c'est pas aussi facilement exploitable qu'il y a vingt ans.
Après, dans l'idéal, les deux approches sont complémentaires, mais certains langages safe ont tendance à faire leur propre gestion mémoire, souvent orientée performance et non sécurité (faisant l'hypothèse zéro bugs dans le compilo), donc certains bugs mémoire dans le compilo peuvent du coup être plus graves, car certaines mitigations ne s'appliquent plus.
[^] # Re: Performances vs. Sécurité
Posté par barmic 🦦 . Évalué à 1.
Tout à fait tu peux même avoir une approche architecturale. Par exemple en séparant le code qui gère les IO du code plus critique ou en utilisant en langage plus sûr pour les IO et un langage plus orienté performance pour le code critique.
Il faut voir ce que l'on appel exploitable. L'exécution de code arbitraire c'est rendu plus complexe par exemple avec les pages mémoires non exécutables, mais le simple fait de faire crasher un service peu déjà être une exploitation grave de la faille. Soit parce que tu ne veux pas que ce service tombe, soit parce que faire tomber ce service consomme une partie de tes ressources et donc le faire tomber en boucle peu consommer toutes tes ressources (tout ton CPU, tout ton espace disque, flooder tes alertes monitoring pour cacher une attaque plus sophistiquée,…).
Ça me fait penser (je vais avoir du mal à retrouver des pointeurs là dessus) que l'un des grands gap pour la performance mémoire actuellement semble être qu'on utilise une mémoire trop fiable. Si on change les prérequis mémoire, les constructeurs peuvent faire quelque chose de bien plus performant. Ça ajoute de la charge au code, mais ça reste plus efficace. Je crois que c'est dans un GLMF que j'avais lu ça.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Performances vs. Sécurité
Posté par anaseto . Évalué à 2. Dernière modification le 28 octobre 2019 à 12:08.
Oui, mais à ce niveau tu as ce même problème qu'avec un langage ayant des vérifications à l'exécution pour l'accès à un élément de tableau, par exemple rust. Après, ça a peut-être plus de chance d'être détecté par chance dans les tests. Et les itérateurs etc. réduisent un peu le nombre de ces cas pour les boucles simples. Ceci dit, on pourrait imaginer (à tort peut-être) qu'on se plante plus facilement dans les cas justement un peu moins évidents où on a besoin, quel que soit le langage, d'écrire l'index à la main et, donc, de risquer un crash.
Je mets de côté le cas où on dispose d'une preuve formelle mécanique que l'accès est valide, ce qui reste encore laborieux et peu accessible, limité à des langages plutôt académiques ou de niche.
[^] # Re: Performances vs. Sécurité
Posté par barmic 🦦 . Évalué à 1.
Tu peux avoir une vérification faite à l’exécution avec une vérification que tu gère l'erreur à la compilation. C'est ce que tu as avec les exceptions vérifiées en java. Ça ne garanti pas que c'est correctement géré mais ça limite les problèmes.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Performances vs. Sécurité
Posté par fearan . Évalué à 2.
Avec quel impact sur les perfs? En c++ tu as les deux options, at() ou operator[], en quoi est ce gênant? De plus en java, tu n'as aucune vérification à la compilation que tu gère bien le java.lang.ArrayIndexOutOfBoundsException qui est une unchecked exception :)
C'est peu de le dire… le nombre de catch qui ne font rien et qui traine sans même logger l'erreur est hallucinant.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Performances vs. Sécurité
Posté par barmic 🦦 . Évalué à 2.
C'est exactement ce que j'essaie d'expliquer depuis le début. C'est cette démarche qui fait qu'on sort des trucs buggé parce que peut être que ça a un impact sur les performances. Continuez à penser aux performances avant la fiabilité et on continuera par se faire bolosser par tous les autres domaines ingénieries.
Je préfère amplement le soft qui ne réagi pas bien à un stimuli (une requète ou je ne sais quel évènement) que celui qui se mange un sigsev des familles.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Performances vs. Sécurité
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 4.
C'est marrant, moi, c'est tout l'inverse. Combien de softs te renvoient des tonnes d'exception non traitées genre "même pas mal" ?
En plus, côté confiance, tu m'excuseras mais un truc qui balance une stacktrace de 50km, moi, ça me rassure pas. Au boulot, la boutade habituelle pour ce genre de situations, c'est de dire : "laisses, c'est une erreur normale"
Un sigsev, c'est le signe qu'il y a un vrai problème et qu'on ne peut pas laisser le programme tourner comme ça. S'il n'y en avait pas, rien ne garantit que le programme ne serait pas en train de faire n'importe quoi.
[^] # Re: Performances vs. Sécurité
Posté par barmic 🦦 . Évalué à 1.
Il y en a un qui a potentiellement un gros problème de sécurité et l'un qui a un bug pour un utilisateur. Je ne vois pas la subjectivité qui permet de dire : je préfère avoir une CVE qu'un bug utilisateur documenté.
Tu le sais comment ? À part lancer du fuzzing sur ton programme et attendre ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Performances vs. Sécurité
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
Je n'ai jamais dit ça mais si ton bug documenté modifie des données utilisateur dans son dos, ce n'est pas beaucoup mieux.
Le petit article suivant propose une classification que je trouve pas trop mal.
Le fuzzing, c'est un peu l'IA de la validation logiciel. Je ne dis pas que c'est inutile mais franchement, il y a beaucoup de choses à faire avant d'en arriver là.
De la couverture de code et du profilage mémoire lors des tests unitaires, d'intégration et des tests fonctionnels, ça fait déjà pas mal de choses.
Après, pour que cela n'arrive pas chez l'utilisateur final, cela suppose que l'on laisse le temps de faire des tests un peu poussés avec un vrai cahier de tests qui ne se passe pas en deux heures.
[^] # Re: Performances vs. Sécurité
Posté par barmic 🦦 . Évalué à 1.
Ou simplement utiliser un langage qui empêche de facto ce genre de choses ? Si vraiment les développeurs ont peur de gagner trop de temps je suis certains qu'il y a pleins d'autres choses à améliorer ailleurs.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Performances vs. Sécurité
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
Une partie des problèmes évoqués ont été, en partie, pris en compte dans Ada depuis la révision de 1995 et pourtant, il suffit de regarder les statistiques d'utilisation du langage pour voir que cela ne suffit pas à attirer les développeurs.
Même l'introduction des contrats en 2012 n'a pas changé grand chose à cet état de fait.
Ce qui compte, et cela a déjà été mentionné, c'est le time to market ou le MVP, on se fout de la qualité, il faut juste être le premier.
[^] # Re: Performances vs. Sécurité
Posté par barmic 🦦 . Évalué à 1.
J'ai pleins de choses à dire là dessus :
Bref je dérive,je trouve juste que c'est très manichéen de se sentir fort et de rejeter la faute sur les autres.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Performances vs. Sécurité
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 4.
Ca, ce n'est pas du time to market, c'est une échéance pas un jalon commercial dont le seul but est de gagner un marché avant tout le monde quelle que soit la qualité.
Encore une fois, time to market tel que je l'ai utilisé n'est pas le temps nécessaire à la production mais bien le temps pour avoir un produit "vendable". D'ailleurs, pour certains, le terme TTM ne va pas toujours très bien avec le terme qualité (cf. la page Wikipédia).
Qui a dit que l'on ne faisait pas cela ?
Disons que quand je fournis un chiffrage à 300K€ et que mon commercial me dit que ce n'est pas la cible du client et qu'il faut que je descende à 120K€, hormis retirer des fonctionnalités et rogner sur la qualité, désolé, j'ai du mal à faire.
Du coup, une fois avoir bien rogné à droite et à gauche sans arriver à descendre à la "cible", baisser le prix devient une stratégie commerciale.
Il y a beaucoup d'a priori dans ton message qui sous-entendent que les informaticiens ne bossent qu'entre eux et ne veulent surtout pas se mélanger à d'autres corps de métier. Ce n'est pas forcément le cas de toute la population de LinuxFR.
[^] # Re: Performances vs. Sécurité
Posté par barmic 🦦 . Évalué à 1. Dernière modification le 27 octobre 2019 à 21:45.
Avant de chercher toutes les excuses du monde, on pourrait d'abord s'intéresser à ce que l'on peut faire nous.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Performances vs. Sécurité
Posté par Firwen (site web personnel) . Évalué à 5. Dernière modification le 27 octobre 2019 à 21:55.
Quand tu as un problème qui touche tout une industrie. Tu cherches "pourquoi" avant de blâmer des individus.
[^] # Re: Performances vs. Sécurité
Posté par barmic 🦦 . Évalué à 2.
Non, je cherche ce que je peux faire à mon niveau. Ni toi, ni moi, ni l'ensemble des membres qui se sont un jour connecté à linuxfr ne vont changer l'industrie. Par contre on peut se demander ce que l'on peut faire pour améliorer ce que l'on fait.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Mouais
Posté par fearan . Évalué à 2.
API plus sûres existent, elles sont typiquement plus laborieuse à utiliser (.at() au lieu de [], value() au lieu de * ou ->), alors que les besoins en perfs sont typiquement concentrés et non pas diffus
Oui mais non, généralement quand j'accède à un indice dans un vecteur, je sais que je ne vais pas taper dans le vide, je ne l'ai pas choisi aléatoirement, * et -> sont des accesseurs sur les pointeurs, et je ne m'attends pas à un test.
C'est des sémantiques proches du C, et c'est tant mieux, le comportement est similaire. Rien n'est plus piégeant en java que le == qui tantôt va le faire sur les valeurs (type primitifs), tantôt sur les référence d'objet, et parfois avec la mutualisation des références, va fonctionner quand même.
C'est typiquement le type d'opérateur que j'utilise en coeur de boucle, et l'appli sur laquelle je bosse ne peut pas se permettre de perdre des perfs.
J'ajouterai que modifier le comportement d'un programme lors de la mise à jour d'un langage n'est pas souhaitable; si tu veux être 'sécure' lit la putain de doc et apprends à coder!
Des mauvais codeurs, même avec un langage safe te feront toujours du mauvais code; ces deux derniers jours j'ai du refactorer une partie de code (faite il y a 3 semaines); on appel ça une fin de chantier chez nous… Au final j'ai diminué le code de 100 lignes, et c'est plus générique (une classe pilotée par 2 booléens constant à la création, là ou une Intergace et deux implémentations auraient suffit…) et puis ça aurait été trop demandé à la classe de gérer ces cas… Non il fallait tester ces booléens pour savoir quelle fonction appeler… C'était du java
Honnêtement, je préfère ne pas avoir de codeur plutôt qu'un mauvais codeur.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# P'tite remarque de syntaxe
Posté par Cetera . Évalué à 1.
En français, le ou est toujours inclusif. Donc là où il y a « et/ou », « et » est redondant et « ou » suffit.
Purée, je suis fier de moi. On dirait du Devos ! :D
Pour la version exclusive du « ou », on utilise « soit-soit ».
[^] # Re: P'tite remarque de syntaxe
Posté par sebas . Évalué à 4.
« Je te sers un verre ? Tu veux un cognac XO ou un sauternes 1er grand cru ? »
Purée, si tu demandes les 2 (et dans le même verre, en plus), on risque de te servir du coca ou une Kro, à la place ;-)
[^] # Re: P'tite remarque de syntaxe
Posté par raphj . Évalué à 2.
Je vois mal quelqu'un demander « Tu veux soit une bière, soit un jus d'orange ? » :-D
Et si je dis que mes chaussures sont rouges ou bleues, elles sont probablement soit l'un, soit l'autre.
En logique, certes, « ou » est inclusif par défaut mais à mon avis, si tu sors voir du monde et que tu utilises « ou », tu risques de te rendre compte que beaucoup de gens comprennent ce mot dans son sens exclusif par défaut dans beaucoup de cas. Pour preuve, le fait que justement « et/ou » soit très répandu. L'exemple d'utilisation de sebas est bon également. Expliciter ne peut pas faire de mal.
[^] # Re: P'tite remarque de syntaxe
Posté par Cetera . Évalué à -1. Dernière modification le 26 octobre 2019 à 16:23.
Non, bien sûr. Dans une question, ce serait malvenu de t'empêcher de choisir les deux. Surtout si on te vend les boissons en question. :p
Et sinon, pour moi, ce sera une bière, merci.
[^] # Re: P'tite remarque de syntaxe
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5.
[^] # Re: P'tite remarque de syntaxe
Posté par Thomas Douillard . Évalué à 2.
/me envoie un jus d’orange à pulkomandy<
[^] # Re: P'tite remarque de syntaxe
Posté par Benoît Sibaud (site web personnel) . Évalué à 3. Dernière modification le 26 octobre 2019 à 14:32.
Tu veux vraiment une réponse ou bien ?
[^] # Re: P'tite remarque de syntaxe
Posté par Cetera . Évalué à -1.
Ou pas. Mdr !
[^] # Re: P'tite remarque de syntaxe
Posté par lolop (site web personnel) . Évalué à 9. Dernière modification le 27 octobre 2019 à 16:20.
Tu tiens ça d'où ?
Exemple très courant : au resto quand il y a "fromage ou dessert" c'est typiquement exclusif.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: P'tite remarque de syntaxe
Posté par Cetera . Évalué à 3. Dernière modification le 27 octobre 2019 à 23:18.
Je tiens ça de… euh… j'aime la langue française, quoi. :)
https://fr.wiktionary.org/wiki/ou est plus exact que moi et prend même en compte ton objection.
En résumé pour ceux qui ont la flemme de vérifier, il y a bien une distinction à faire :
- Si les deux cas sont envisageables, alors le ou est inclusif (donc on n'écrit surtout pas et/ou) ;
- s'ils sont réellement incompatibles, alors le ou est effectivement à comprendre de manière exclusive.
Ainsi, par défaut, le ou est inclusif. C'est le sens commun qui en donne le sens exact. Subtilité marrante : si le ou est placé au sujet et qu'il y a ambiguïté, alors celle-ci sera levée simplement par l'accord en nombre du verbe sans avoir recours à une autre formulation plus précise ; c'est beau, le français !
[^] # Re: P'tite remarque de syntaxe
Posté par Zenitram (site web personnel) . Évalué à -2. Dernière modification le 28 octobre 2019 à 08:47.
Désolé, je continuerai à l'écrire.
Car tout bêtement ton "réellement incompatibles" ne marche pas à 100% : fromage ou dessert n'est pas incompatible, m'empêche l'offre est avec un ou exclusif.
Du coup quand je dis à mes invités "fromage ou dessert", pas foule va comprendre pour sûr que les 2 sous possibles, donc je dis fromage et/ou dessert.
Bref, des fois ca reste pratique d'écrire et/ou, pour lever une ambiguïté de manière simple.
Tu vas à la piscine lundi ou mardi? Aide moi, je ne vois d'accord!
Et ton lien dit l'exemple comme "ambigüe"… Donc pas que moi.
Jamais vu de carte de resto avec ça alors que c'est exclusif 99.999% du temps, tu m'en montres une?
[^] # Re: P'tite remarque de syntaxe
Posté par Cetera . Évalué à -3.
Ben justement, non. Si tu as compris mon message précédent, c'est exactement le contraire. Le et/ou ne sert qu'à indiquer l'inclusivité, alors que c'est l'exclusivité, qu'il faut préciser dans les cas ambigus. Pour respecter la logique de la langue, tu peux toujours inventer une formulation du type ou/non-et, mais bon… c'est moche, et il y a d'autres moyens pour exprimer cette idée.
L'histoire de l'accord donnerait : « Tu vas à la piscine lundi ou mardi ? Quelles belles journées ce seront. » Et là, dans ce cas précis, il est évident que ça ne peut être qu'exclusif.
Là, tu chipotes. La langue, ce n'est pas mathématique. Pour une carte resto, même si grammaticalement il y a clairement ambiguïté, tout le monde sait ce que ça veut dire. Je maintiens que dans l'article, pour des histoires de compilateurs, de boucles et de variables, il n'y a pas besoin de mettre et/ou, dans la mesure où les deux sont compatibles.
[^] # Re: P'tite remarque de syntaxe
Posté par Cetera . Évalué à 0.
Mince. J'ai donné l'exemple en version inclusive. Je recommence :
« Tu vas à la piscine lundi ou mardi ? Quelle belle journée ce sera. »
Et là, c'est bien exclusif.
[^] # Re: P'tite remarque de syntaxe
Posté par Tit . Évalué à 3. Dernière modification le 28 octobre 2019 à 11:43.
Typiquement pour cet exemple,"vas-tu à la piscine lundi ou mardi ?"
il me semble que le "ou" est plutôt exclusif, j'ai l'impression que le questionneur pense que ce sera soit lundi, soit mardi… s'il pense que les deux sont possibles, il dira un truc du genre "vas-tu à la piscine lundi ou mardi… ou ces deux jours ?"
(la formulation de ton exemple de "levée d’ambiguïté", est vraiment étrange ;-) on a dû mal à comprendre ce que que signifie cette phrase. que veux-tu dire par "quelle belle journée ce sera?" que la journée sera belle parce qu'il va aller à la piscine ce jour là ou parce que il va faire beau (les deux jours donc) ?… dans les deux cas, personne je pense dans la vraie vie ne dira les choses comme ça : par ex dans le deuxième cas, il dira "ce seront deux belles journée" puisqu'il va faire beau les deux jours, même s'il pense que que son interlocuteur ira à la piscine soit lundi, soit mardi, ; et dans le premier cas il pourrait dire, un truc du genre "ça va être super" ! (ce qui ne résout rien pour notre problème ;-))
[^] # Re: P'tite remarque de syntaxe
Posté par anaseto . Évalué à 3.
À l'oral, tu dis d'habitude juste « Tu vas à la piscine lundi ou mardi ? », tu rajoutes pas après une phrase exprès pour résoudre l'ambigüité ;-)
Ce qui permet de résoudre l'ambigüité, c'est le contexte et le ton dans lequel la phrase est exprimée, pas la définition du dictionnaire, ni une potentielle inclusivité ou exclusivité par défaut. Au fond, tu t'en rends bien compte quand tu dis :
[^] # Re: P'tite remarque de syntaxe
Posté par Cetera . Évalué à -1. Dernière modification le 28 octobre 2019 à 10:32.
J'expliquais l'histoire de l'accord à Zenitram qui demandait de l'aide. Mais nous sommes entièrement d'accord sur le fond ! ;)
[^] # Re: P'tite remarque de syntaxe
Posté par anaseto . Évalué à 3. Dernière modification le 28 octobre 2019 à 09:34.
Uniquement si les deux termes sont au singulier :-) Et puis, même alors, ça ne marche qu'à l'écrit : L'oiseau ou la grenouille chante ou chantent a la même prononciation, donc tu ne parles pas du français, mais d'un code d'écriture spécifique introduisant une différence inexistante dans la langue française (au sens de la science linguistique).
Et puis savoir si les termes sont « réellement incompatibles » est justement pas toujours évident sans le contexte (wiktionnaire que tu pointes donne un exemple, comme mentionné par Zenitram ci-dessus). D'ailleurs, wiktionnaire donne plus d'exemples d'exclusif que d'inclusif, montrant que considérer les choses inclusives par défaut semble osé.
Du coup, et/ou, c'est concis et bien pratique. D'ailleurs, je l'ai déjà entendu (donc utilisation dans la langue orale, pas seulement écrite). Après, subjectivement, c'est logique mais pas très naturel d'écrire ça comme ça (les mots n'ont pas de slash d'habitude), donc je serais ouvert à éhou ou quelque chose dans ce goût là ;-)
[^] # Re: P'tite remarque de syntaxe
Posté par Cetera . Évalué à 0. Dernière modification le 28 octobre 2019 à 10:28.
L'écriture n'est pas à dédaigner. Droit, littérature… Souvent, l'orthographe garde une trace d'usages plus anciens qui se manifestaient dans la langue parlée.
Oui, tu as tout à fait raison, il y a parfois une ambiguïté qu'on peut vouloir lever de manière concise. Si on respecte la logique de la langue, ce serait plutôt en indiquant les cas où le ou est exclusif. Les tournures alternatives vont dans ce sens. Comme le dit très justement Benoît, ou bien fait l'affaire. Ça ne prend qu'un mot de plus, et ça reste élégant. Plus que éhou, qui introduit un hiatus dégueu et qui ne répond pas au problème.
[^] # Re: P'tite remarque de syntaxe
Posté par anaseto . Évalué à 2.
Je comprends ce que tu veux dire, mais une solution n'empêche pas forcément les autres : une langue naturelle, c'est pas comme un langage de programmation ou l'on peut décider de l'introduction d'un nouveau mot-clé ou pas pour éviter qu'il y ait plusieurs façons de faire une même chose. De la même façon que des tournures alternatives apparaissent, des mots nouveaux peuvent apparaître et disparaître aussi.
Après, les considérations subjectives sur la sonorité du mot en question… le futur dira ce qu'en feront les gens, ils finiront peut-être par prononcer ésou, ou bien étou (pas impossible, héhé), ou bien le diphtongue «éou» (peu probable en français, car inexistant actuellement), ou bien encore héroïquement le éhou d'origine. Ou le mot ne survivra pas à l'usage et disparaîtra :-)
[^] # Re: P'tite remarque de syntaxe
Posté par Tit . Évalué à 0. Dernière modification le 28 octobre 2019 à 16:32.
je vois pas comment prononcer cela, je n'arrive qu'à faire éhou… Vous arrivez-vous à faire un éou différent de éhou ?
(c'est peut-être parce que j'ai pas vraiment compris ce qu'était une diphtongue, ou parce que je suis trop nul pour la prononciation ;-))
[^] # Re: P'tite remarque de syntaxe
Posté par anaseto . Évalué à 2.
Pense plutôt « éw » avec un « w ». Un diphtongue c'est une « fusion » de deux voyelles. Pour une déf plus technique, wikipédia.
C'est un son assez courant, écrit « eu » en basque ou espagnol, pas en français.
[^] # Re: P'tite remarque de syntaxe
Posté par moi1392 . Évalué à 3.
En langue française, le / indique un choix exclusif entre deux mots.
À l'écrit, je l'utilise occasionnellement dans des courriels par exemple, et il ne me choque pas.
Par contre, à l'oral, j'ai du mal avec le et/ou, je préfère faire une périphrase dans le genre tu vas à la piscine lundi, mardi ou les deux jours ?
Je trouve que ça passe beaucoup mieux comme cela. Et je n'ai pas trouvé d'info sur le "/" à l'oral. (s'il peut s'écrire, il doit bien avoir une façon de le dire)
[^] # Re: P'tite remarque de syntaxe
Posté par anaseto . Évalué à 2.
Oui. Après, dans la vie réelle, il y a d'autres possibilités : « C'est quand que tu vas à la piscine ? » (question plus ouverte même si on sait que ça peut être que les deux premiers jours de la semaine) ou « Tu vas à la piscine lundi et mardi ? » (on tente un truc, la réponse nous dit si en fait c'est pas les deux jours et juste l'un des deux), ou « c'est quel(s) jour(s) que tu vas à la piscine ? » (versions pluriel identique à l'oral en pratique).
Pas forcément, on est habitués à plein de lettres qui ne se prononcent pas dans notre écriture. Faudrait faire un sondage :-) Personnellement, quand je lis, je subvocalise souvent et le et/ou dans ma tête c'est éhou, en deux syllabes (sans diphtongue).
# au contraire, totalement désirable
Posté par AnthonyRabine (site web personnel) . Évalué à 3.
C'est marrant, autant ton discours pouvait tenir dans les années 2000, avec la stagnation de la norme et une offre de compilateurs alarmante (qui se souvient de Visual c++ 6 et son support hasardeux des templates), autant je crois qu'il ne tient plus aujourd'hui.
Perso, je l'utilise pour tout, y compris pour écrire du code Backend voire front-end avec ecmascripten.
Jamais un langage n'a été aussi versatile et surtout, important pour moi, un langage générant possiblement du binaire sans dépendance.
Les dernières avancées de la norm et des librairies tierces le remettent en avant.
J'ai bien tenté d'apprendre d'autres langages, mais je ne me fait pas à leur syntaxe relou perlesque.
[^] # Re: au contraire, totalement désirable
Posté par Jean-Baptiste Faure . Évalué à 10.
En français "versatile" n'est pas un compliment. Ça ne me donne pas envie d'apprendre le C++.
[^] # Re: au contraire, totalement désirable
Posté par anaseto . Évalué à 1. Dernière modification le 27 octobre 2019 à 09:01.
En même temps, le truc le plus proche que je trouve en « français », c'est flexible ou adaptable, et c'est quand même moins précis. Pas étonnant, donc, que cet anglicisme se propage, il apparaît même sur wiktionnaire. Note, que le sens de l'anglicisme est quand même lié au sens original de façon figurée, c'est pas un sens totalement différent, même si ça passe paradoxalement du négatif au positif suivant le sens figuré utilisé (le sens littéral étant neutre de ce point de vue, toi tu parle déjà d'un sens figuré).
Édit : peut-être polyvalent est plus proche.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.