Discussion :

[Kannagi]

Ben en fait, c'est bien le développeur qui fait le "miracle" en C. Les gains en performance de C par rapport à C#.net, en faisant un portage de code strict, s'arrêtent aux boucles (2 ou 3 cycles d'horloge par itération) l'usage des pointeurs explicites (1 ou 2 cycles). L'arithmétique sur pointeurs, c'est juste quelques nano secondes parce qu'on écrit dans le cache à fréquence CPU plutôt qu'en RAM à fréquence mémoire.

La magie du C , c'est les optimisations. Une fois qu'on a pigé la dizaine d'objets que manipule le compilo, désassemblé un peu de code (en C, l'assembleur se lit bien), on fait des raccourcis de fou, on rassemble le code qui utilise la même data pour empêcher les move's inutiles, on indexe des gros tableaux (pas de hash mais bien des tableaux d'indices) etc...
C# optimisé n'est que 15 à 20% moins rapide que C optimisé à condition de ne pas abuser des appels librairies, accès disques , databases...

Sauf si vous bosser avec un CPU des années 80 ou sur un proc embarqué , vous ne pouvez pas prédire le temps d’exécution des instructions.
Un branchement sur x86 varie entre 0.5 et plus de 20 cycles.
Les pointeurs explicite pareil , pas regardé , mais les calculs d'adresses doivent eux aussi varier entre 0.25 et 5 cycles.
Les ARM 64 doivent être dans le meme ordre de grandeur mais ils ont moins de pénalité sur les branchements.

Sinon les dernières version de C# , le JIT est relativement performant et pas sur qu'on voit beaucoup de différence entre les deux , comme toujours celà dépend de l'implémentation.

Par contre non comment le C code et l'asm , y'a un petit monde ,surtout si on active les optimisations , seul le -O0 semble presque faire une traduction littéral.
Par contre c'est pas le C qui est proche de l'asm ,c'est plutôt l'inverse nombre de constructeur ont fait en sorte que les CPU fonctionne proche de ce que peut générer un compilateur , et encore c'est pas suffisant , quelque fois il faut une analyse poussé du code C pour faire les bonne optimisations.

Par contre juste un truc qui me fait tiquer :

parce qu'on écrit dans le cache à fréquence CPU plutôt qu'en RAM à fréquence mémoire.

Cette phrase n'a aucun sens , une fréquence est un intervalle dans le temps , elle ne sont pas de nature différente.
Le cache CPU et la RAM ont certes une fréquence différente, mais ce n'est pas ça qui explique la différence d’accès (ça peut l'expliquer en partie).

Bon, j'ai essayé de rendre ça compréhensible mais il suffit de retenir que les attaques ont lieu au runtime et non pas au design time.

Je sais comment fonctionne l'exécution dans un OS , niveau CPU ou software, ce n'était pas ma question.
Je comprenais pas le rapport avec le C.
Mais je pense pas qu'on parle de cybersécurité,que Rust ne résout en rien.
On parle de sécurité du code que le code s’exécute sans comportement indéfini.

[Uther]

Je viens de l'essayer en javascript, aucun problème
je vous met au défi de lever une exception ou de provoquer une erreur de calcul avec cette expression.

Je ne comprends pas pourquoi vous insistez sur ce faux problème. Si votre école a appelé ça un undefined behavior, Votre école s'est trompée. Point final.

Ton compilateur sort peut-être actuellement le résultat que tu attends, mais c'est une erreur de penser que c'est forcément le résultat qu'il devait te retourner. D'après le standard, le compilateur est libre de faire absolument ce qu'il veux de ce genre d'instruction. Le comportement de cette expression pourrait très bien changer en fonction de la portion du code dans laquelle elle se trouve, des paramètres d'optimisation, de la version du compilateur ou autre.

Comparer avec JavaScript n'a pas de sens vu que sa spécification est différente. Je ne connais bien la spec de JavaScript, mais il me semble que, comme en Java, l'évaluation des éléments d'une expressions est précisément défini. Je ne suis même pas sur que le concept de UB existe en JavaScript.

[commandantFred]

Par acquis de conscience, j'ai fait le test sur un vrai compilateur en ligne.

Le résultat parle et franchement, seul un gangster sociopathe peut le contester. Ce qui fait le métier de developpeur, ce sont les tests, certainement pas le blabla de jeunes impétueux qui ne citent aucune source ni ne démontrent quoi que ce soit.

Le résultat : on se trompe tous !

Moi parce que j'ai ajouté 1 à i alors qu'il est incrémenté AVANT exécution de l'expression et qu'il apparait deux fois dans cette même expression, donc il faut ajouter 2 en non 1. La valeur de i résultante est en revanche correcte, (i +=2)

Vous parce que vous prêtez à cette expression un caractère ésotérique alors qu'elle ne pose aucun problème au compilateur. Elle sera très stable et n'aura pas de "pouvoirs magiques"

Donc là, je le dis tout net :

1. Soit vous citez une source bibliographique qui stipule qu'un démon s'est emparé des compilateurs - et qu'on le réveille par l'incantation "i++ + ++i"
2. Soit vous faites amende honorable et un peu profil bas parce que vous racontez vraiment des cracks sur un site web consacré au dev et que vous seriez blacklistés sur stackoverflow pour bien moins que ça.
3. Soit vous êtes une ferme à trolls payé par un état voyou pour instiller des bugs dans la tête des developpeurs innocents.

A vous de voir



EDIT :
J'ai essayé de mettre l'expression à la ligne précédant le printf. Le résultat est exactement identique.

[Kannagi]

Vu que tu semble considéré stackoverflow comme argument d'autorité :
https://stackoverflow.com/questions/...c-c-i-i-vs-i-i

Les réponses :

is still undefined behavior since ++i and i++ can be processed simultaneously in multiple pipelines in some CPUs, which will lead to unpredictable results.

ou

No, you are not correct. Each of the expressions ++i and i++ modify i, so the statement modifies i more than once. That is undefined behaviour.

Celà veut pas dire que ça fait quelque chose au hasard, mais que son implémentation est indéfini, si tu fais un compilateur C et que cela donne 21 sur ton printf (mais que l'instruction suivant fasse 22 ), ton compilateur serait correct d’après la norme.
Voir même renvoyer 1 pour une raison quelconque.

Avoir un comportement défini est utile surtout si on change de compilateur ou qu'on fasse de la cross-compilation.

[KsassPeuk]

vous racontez vraiment des cracks sur un site web consacré au dev et que vous seriez blacklistés sur stackoverflow pour bien moins que ça.

https://stackoverflow.com/questions/...c-c-i-i-vs-i-i

D'ailleurs le compilateur peut grogner aussi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
$ gcc -o out a.c -Wall
a.c: In function ‘main’:
a.c:3:17: warning: operation on ‘i’ may be undefined [-Wsequence-point]
    3 |   int j = i++ + ++i ;
      |                 ^~~

Mais sinon sans rire:

j'ai fait le test sur un vrai compilateur en ligne.

Qu'est ce qui n'est pas clair dans la définition de "undefined behavior" dans la norme ?

[commandantFred]

https://stackoverflow.com/questions/...c-c-i-i-vs-i-i

D'ailleurs le compilateur peut grogner aussi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
$ gcc -o out a.c -Wall
a.c: In function ‘main’:
a.c:3:17: warning: operation on ‘i’ may be undefined [-Wsequence-point]
    3 |   int j = i++ + ++i ;
      |                 ^~~

Mais sinon sans rire:

Qu'est ce qui n'est pas clair dans la définition de "undefined behavior" dans la norme ?

Alors là, je vais citer ma science :

La bible du C s'appelle "The C Programming Language" de Brian W. Kernighan et de Dennis M. Ritchie,
Livre auquel j'ai consacré ma prime jeunesse.

Il est mentionné sans ambiguité que l'opérateur unaire "++" situé avant l'opérande, est exécuté avant le code qui l'invoque. Si toutefois, ce même opérateur est situé après l'opérande, l'incrémentation sera exécutée après ce même code.

J'ai utilisé ce principe toute ma vie sans le moindre bug malgré l'infinité de plateformes sur lesquelles mon code s'exécute encore aujourd'hui, y compris du code de hackaton qui m'a propulsé à la première place sur plusieurs milliers de candidats.

Il n'y a donc aucune ambiguïté sur le moment où s'exécutent les incrémentations. L'une avant, l'autre après, aucun pipeline à gérer, le compilateur sait ce qu'il doit faire

La discussion Stack Overflow affiche fièrement 1 vote (celui de l'auteur de la question). Pour un scoop, c'est plutôt confidentiel.

Le seul truc bizarre dans cette expression, c'est qu'elle embrouille son lecteur humain, le compilateur et l'exécutable savent parfaitement ce qu'ils doivent faire.

Merci de copier la sortie console de votre test. J'offre une tournée générale si vous avez un résultat différent du mien.

[Uther]

Le résultat parle et franchement, seul un gangster sociopathe peut le contester. Ce qui fait le métier de developpeur, ce sont les tests, certainement pas le blabla de jeunes impétueux qui ne citent aucune source ni ne démontrent quoi que ce soit.

C'est la tragédie des codes reposant sur des UD, on peut avoir quelque chose qui marche, jusqu'au jour où ça ne marche plus, parce qu'on a changé de compilateur ou de réglage d'optimisation par exemple. Donc les tests c'est bien, mais malheureusement ça ne démontre pas l'absence de Undefined Behavior.

Le résultat : on se trompe tous !

Moi parce que j'ai ajouté 1 à i alors qu'il est incrémenté AVANT exécution de l'expression et qu'il apparait deux fois dans cette même expression, donc il faut ajouter 2 en non 1. La valeur de i résultante est en revanche correcte, (i +=2)

Vous parce que vous prêtez à cette expression un caractère ésotérique alors qu'elle ne pose aucun problème au compilateur. Elle sera très stable et n'aura pas de "pouvoirs magiques"

Notez que je n'ai pas parlé d'ésotérisme mais de comportement non déterminé (Undefined Behavior), c'est a dire des cas certes syntaxiquement valide mais que le programmeur se doit d'éviter dans un code normal. Dans ces cas là, la spécification du C laisse libre cour au compilateur de faire ce qu'il souhaite, y compris des comportements surprenant, car il s'agit de cas qui ne sont pas censé arriver. Il est tout à fait possible (et même probable dans ce cas particulier de UD) que votre compilateur se comporte de manière tout à fait déterministe, mais le standard ne l'y force absolument pas. Le compilateur a tout à fait le droit (et dans certains cas, ne s'en prive pas) de changer de comportement, en fonction des besoins d'optimisation le plus souvent.
Même si votre compilateur est consistant, rien ne garantit qu'il le restera et un autre compilateur peut réagir différemment.

Soit vous citez une source bibliographique qui stipule qu'un démon s'est emparé des compilateurs - et qu'on le réveille par l'incantation "i++ + ++i"

Alors comme source bibliographique le standard C++ ça vous va ?

6.5 Expressions, §2
Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be read only to determine the value to be stored.

Comme ça c'est un peu sec, mais à priori, c'est bien la section concernée. Dans l'expression i++ + ++i la valeur de i est incrémentée deux fois alors que la standard ne garantit le comportement que pour une seule modification. Je ne peux malheureusement lier le document original, il n'est pas en accès libre.

Soit vous faites amende honorable et un peu profil bas parce que vous racontez vraiment des cracks sur un site web consacré au dev et que vous seriez blacklistés sur stackoverflow pour bien moins que ça.

En effet je risque tellement de me faire blacklister de stackoverflow que je vous invite à regarder cette question où :
- la personne qui pose la question obtient des résultats variables avec son compilateur (chez moi Gcc et Visual Studio donnent des résultats à la fois différents entre eux et différent de la personne qui pose la question).
- une réponse à 600 votes lui explique que vu ce qu'est un UB ça peut arriver et qu'il n'y a pas de résultat à priori correct défini par le standard.
- d'autre réponses au alentours de 100 votes qui lui expliquent précisément ce qui dans la spécification cause ça.

Je ne vous demanderais pas de faire amande honorable ni profil bas, mais à défaut d’arrêter votre ton accusateur merci.

La bible du C s'appelle "The C Programming Language" de Brian W. Kernighan et de Dennis M. Ritchie,
Livre auquel j'ai consacré ma prime jeunesse.

C'est certes l'ouvrage de référence dans l'apprentissage du C et il faisait également office de référence technique dans les années où il n'y avait pas encore de norme. Mais bon la première norme C remonte à il y a 35 ans, c'est clairement l'unique spécification technique reconnue par tous les compilateurs mainstream depuis bien longtemps.

Il est mentionné sans ambiguité que l'opérateur unaire "++" situé avant l'opérande, est exécuté avant le code qui l'invoque. Si toutefois, ce même opérateur est situé après l'opérande, l'incrémentation sera exécutée après ce même code.

Ce qui n'est pas faux, mais pas aussi précis que la norme qui introduit entre autre les "sequence points" qui permettent de préciser,le moment oui l'incrémentation se fait dans l'évaluation de l'expression ou la limitation du nombre de modifications d'une variable que j'ai cité plus haut.
Et c'est normal : "The C Programming Language" est un manuel, pas une spécification.

J'ai utilisé ce principe toute ma vie sans le moindre bug malgré l'infinité de plateformes sur lesquelles mon code s'exécute encore aujourd'hui

J'ose espérer pour tes collèges que tu n'as pas trop appliqué le principe de modifier plusieurs fois une variable dans une même expression, car en plus d'être un comportement indéterminé, c'est illisible.

[Pyramidev]

De mon côté, pour C et C++, je m'appuie souvent sur en.cppreference.com. Les informations y sont bien classées et les pages insistent sur les différences entre les versions du C++ ou celles du C.

Pour le langage C, dans la page sur l'ordre d'évaluation, on peut lire :

If a side effect on a scalar object is unsequenced relative to another side effect on the same scalar object, the behavior is undefined.

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
i = ++i + i++; // undefined behavior
i = i++ + 1; // undefined behavior
f(++i, ++i); // undefined behavior
f(i = -1, i = -1); // undefined behavior

La FAQ de en.cppreference.com donne des liens vers les standards payants de C et C++ et les drafs gratuits qui précèdent ces standards.

Dans N2176 (final draft du C17), à la page 55, on peut lire :

If a side effect on a scalar object is unsequenced relative to either a different side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined. If there are multiple allowable orderings of the subexpressions of an expression, the behavior is undefined if such an unsequenced side effect occurs in any of the orderings.⁸⁵⁾
The grouping of operators and operands is indicated by the syntax.⁸⁶⁾ Except as specified later, side effects and value computations of subexpressions are unsequenced.⁸⁷⁾

La note 85 de bas de page indique :

85)This paragraph renders undefined statement expressions such as

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
i = ++i + 1;
a[i++] = i;

while allowing

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
i = i + 1;
a[i] = i;

[OuftiBoy]

Houlala, ça s'énerve ici on dirait... Quant on fait les choses sérieusement, pour du code critique, on ne change pas de compilateur en cours de projet. Un des soucis, c'est que oui, pour savoir ce que l'on fait, faut connaître l'assembleur. Je me souvient, il y a bien longtemps, dans une autre galaxie, que j'ai pigé comment les pointeurs fonctionnaient en C après avoir un cours d'assembleur. Tout d'un coup, j'ai pigé le concept. A l'époque, il n'y avait pas internet, et trouver un bon bouquin était un défit (et oui, le C de K&R et leur bouquin, c'était top).

L'avantage, quand on a été formé à l'ancienne, c'est qu'on a dû faire des choses correctement, de nous même, sans aller piquer un bout de code par ci et par là. Faire un TSR sous DOS, programmer un 'Device driver' avec le SDK qui demandait 22 disquettes, faire du temps réel sur un vieux Cromwell.

Et oui, savoir comment fonctionne un compilateur ça aide aussi. ça devrait être obligatoire dans toute formation digne de ce nom. Et pour savoir comment ça fonctionne sous le capot, je pense qu'il faut l'ouvrir le capot, et mettre ses mains dans le cambouis. Donc faire un petit compilateur soit même, ça aide a comprendre, faire un petit noyaux temps réel (RTOS), ça aide aussi.

Mais c'est pas grave, on a formé une palanquée de développeurs a faire du java, ou des sites web en javascript, faut pas s'étonner qu'ils ne maîtrisent pas le C et/ou le C++ (je ne parle même pas de l'assembleur). J'ai peut-être l'esprit déformé, mais pour du code critique, on regarde le code qu'a générer le C -> assembleur.

Et puis, pour tout dire, on ne peut pas tout savoir, mettre un développeur "web" sur un projet en C, c'est pas une bonne idée. Moi je n'irais jamais faire du dev "web", je n'en suis pas capable (et j'en ais pas envie). Allez, pour détendre l'atmosphère, c'est comme au foot. Quant t'as eu une formation de gardien, tu te retrouves rarement meilleur buteur. C'est aussi respectable d'être gardien que d'être un renard des surfaces, mais c'est pas la même chose, c'est tout. Mets MBappé dans le rôle de gardien, je ne pense pas qu'il y ferait des miracle.

On a besoin de tout pour faire un monde.

Voilà voilà, peace and love :-)

[OuftiBoy]

Un des soucis, c'est que pour les managers, un informaticien, c'est un informaticien. Qui ne s'est pas déjà entendu dire, alors que le smartphone iOS de la mère d'un copain déraille, et te demande si tu sais pas "jeter un coup d'oeil pour voir ce qui ne vas pas" ? Si tu réponds que t'y connais rien en smartphone, elle te dit: "Mais, tu sais pas ça ? T'est informaticien pourtant".

Perso, je n'irais pas trouver mon dentiste si j'ai une jambe cassée. Mais en "informatique", ça se fait couramment... C'est aussi une partie du problème... Et l'informaticien, il veut sa voiture, sa maison et ses vacances, alors il dit OUI. Faut bien bosser pour rembourser tous les crédits qu'on nous a mis sur le dos... Faut savoir et oser dire NON quand on ne sait pas, quand on a pas le temps, quand on sait que ce qu'on nous demande de faire, ça marchera pas.

Bon, re peace and love les amis :-)

[commandantFred]

(...)

Je ne vous demanderais pas de faire amande honorable ni profil bas, mais à défaut d’arrêter votre discours accusateur merci.

Soit !
Cela dit, vous constaterez plus bas que GCC donne le même résultat. Pour moi (35 ans de dev), cette histoire est un hoax.

Pour revenir au topic, La Maison Blanche etc...

Les gouvernements réalisent, un peu tard, que leurs pays sont mis en danger par du software éparpillé sur tout leur territoire. Comme je l'ai fait pendant des décennies, ce software pilote des ascenseurs de centaines de mètres de haut, des systèmes vitaux d'avions, ... L'exemple donné dans un message précédent sur les SGBD citait SqLite... Vous connaissez l'histoire de SqLite ? Il a été développé pour piloter les missiles de croisière nucléaires américains, rien que ça...

Pourtant, le problème est sans objet dans ce cas. Ces engins ne sont pas connectés à l'internet. Ils sont évidemment programmables à distance mais IP n'est plus utilisé par les militaires depuis longtemps. Toute la stack de communication tactique est non seulement confidentiel défense mais sécurisée par des chiffrages, eux-mêmes inaccessibles au public.

Les systèmes critiques (j'ai pas mal d'expérience là dessus) sont quand même bien sécurisés.

Ce qui ne l'est pas, c'est le logiciel lambda que le commercial Iota a installé sur son laptop pour faire du CRM à distance, avec la complicité de l'opératrice Dzeta qui récupère les données sur le réseau de l'entreprise Omicron avec la bénédiction de tout le personnel dirigeant, trop content de suivre le travail des centaines de personnes en temps réel sur un compte partagé par tous les itinérants.
C'est le software génial qui aide toutes les boites du BTP à passer commande de fournitures et obtenir des ristournes chez les grossistes.

Et encore, les applis en B2B sont au moins protégées par un pare-feu. Il y a bien pire. Les petits open source sympas installés par des millions de quidams dont N% n'ont même pas activé le pare feu de leur OS...

En ce moment, plusieurs chaines de TV diffusent un message de la DGSI qui alerte sur les failles d'Outlook. Je n'avais jamais vu ça avant.

Il y a aussi cette directive, toujours de la DGSI qui oblige les développeurs français à rester joignables au cas où leur software serait identifié comme vulnérable par les services de l'état... (je peux retrouver cette directive et la copier ici...)

Quand je travaillais sous devoir de réserve, j'ai explicitement demandé à ce qu'on rende obligatoire la maintenance du code dans les appels d'offre. Presque aucun éditeur ne la propose pour limiter les coûts et la sécurité est souvent traitée comme un pétard mouillé dans les bureaux. Il y a plein de gens, sans offense, un peu comme vous, qui sont tellement habitués à retourner la responsabilité sur les autres que la sécurité est le problème exclusif du premier qui en parle. La seule évocation de ce problème rend le malheureux qui l'évoque "suspect".

Et comme vous le dites, remplacer CC++ par Rust est un chantier pharaonique.

On n'a même pas parlé des autres langages/archis.

D'où ma conclusion : La Maison Blanche a non seulement raison d'alerter sur la sécurité du software, mais il se passe exactement la même chose en France (et en Europe).

Par contre, je trouve qu'elle n'est pas dans son rôle en parlant de Rust. Même si tout le monde est plus ou moins d'accord pour migrer les OS vers Rust à court terme, Ce n'est pas au gouvernement de décider ça.

[mintho carmo]

Houlala, ça s'énerve ici on dirait...

T'expliquer que tu as tort, c'est pas s'énerver.

pour du code critique, on ne change pas de compilateur en cours de projet.

Si. Sur un projet maintenu pendant des années, le compilateurs utilisé peut évoluer. On peut avoir besoin de supporter de nouvelles plateformes (et donc des buildtools différents). Et pleins d'autres raisons possibles. Un exemple concret, c'est Android qui est passé il y a 2-3 ans de GCC a Clang.

pour savoir ce que l'on fait, faut connaître l'assembleur

A mon boulot, on a plus de 150 build chains, sur des projets de plusieurs centaines de milliers ou de millions de LOC. Prétendre qu'on peut garantir la qualité via une analyse manuelle de l'assembleur, c'est juste irréaliste (dans les domaines non critiques. Dans les domaines critiques -- où des vies sont en jeu -- on peut le faire mais cela à un cout énorme).

D'autant plus que cela peut dépendre aussi de la machine sur laquelle on execute le soft. Et quand on a des millions d'utilisateurs, qui peuvent avoir des millions de configurations hardware+system+soft différentes, c'est encore moins réaliste d'imaginer que l'analyse de l'assembleur garantie l'absence de bugs. (Dans les domaines critiques, on va avoir un control de l'environnement d'exécution, justement pour limiter ce problème).

Il faudrait commencer à accepter que si quelqu'un n'est pas d'accord avec toi, c'est pas forcément qu'il est incompétent, ne sais pas comment fonctionne un ordi et un compilateur et ne sait pas lire l'assembleur.

[OuftiBoy]

Est ce si difficile a comprendre qu'il n'y a pas 1 sorte d'informaticien ? Chacun voit le monde a travers ces yeux, et tous le monde ne voit pas forcément la même chose... Dans mon domaine, non, on ne change pas de compilateur en cours de projet, ni même pendant toute la maintenance du projet, et oui, on vérifie l'assembleur pas à pas avec un debugger. J'y peux rien si c'est devenu mon domaine. Je me suis spécialisé et adapté à ce domaine.

Je n'ai pas dit que les autres domaines DOIVENT faire comme dans le mien. Chacun sa spécialité. La discussion a démarrer en parlant de sécurité concernant les "fuites mémoires", et qu'il fallait passer à Rust. Et bien que ceux qui veulent passer à Rust le fassent. J'ai rien dis contre ça. J'ai dis que le C, quand on le maîtrise, qu'il y a moyen de ne jamais avoir ce genre de soucis. Perso, j'ai peut-être eu du bol, mais je n'ai jamais eu la moindre fuite mémoire ni le moindre soucis avec ça. J'ai rien dis d'autre. Si y'en a qui se sentent attaqué, j'y peux rien moi :-/

Je n'ai pas honte de dire que je ne maîtrise pas les technos web, ni le COBOL dans le domaine bancaire, je fais du bas niveau en C, parfois en assembleur. Pour le reste, c'est Python. Chacun a sa force, son domaine. Désolé mais je ne vois pas où j'ai laissé supposé que seul mon opinion valait, j'ai répondu avec ce que je sais dans le monde qui est le mien. Toute expérience est bonne a prendre, non ?

Encore une fois, sans rancune et re re peace and love :-)

[mintho carmo]

La discussion a démarrer en parlant de sécurité concernant les "fuites mémoires", et qu'il fallait passer à Rust.

La discussion a démarré par une annonce de la Maison Blanche. Sauf erreur de ma part, la Maison Blanche ne s'adressait pas uniquement à toi. Si toi, tu estime que tu n'es pas concerné, cela ne change rien à la problématique soulevée et aux solutions proposées. Si c'est juste pour dire "oui mais moi, je préfère croire que c'est pas vrai", c'est ton choix, mais ça fait pas beaucoup avancer la discussion.

Et cela ne change rien au problème que tu considères ceux qui ne sont pas d'accord avec toi comme des incompétents.

[OuftiBoy]

Je n'ai pas dis cela, j'ai dis que quand on le maîtrisait, le C ne pose pas de problème quand on sait ce qu'on fait et pourquoi on le fais. Et oui, mettre un développeur spécialisé en javascript dans un projet où le langage sera du C, je continue de penser que c'est pas une bonne idée, et l'inverse non plus. On peut être incompétent dans un domaine particulier, et un génie (attention, je ne dis pas que je suis un génie, ne pas déformer mes propos) dans un autre domaine.

Que l'on mettent en garde (la maison blanche dans le cas qui nous occupe) qu'il faut passer à d'autres langages (Rust en l'occurrence) pour avoir moins de problème de "fuite mémoire", je n'ai rien dit d'autre que Ada (utilisé par l'armée US) gérait déjà très bien cela, d'une autre manière.

Puis la discussion a tourné sur le fait que i++ + ++i posait problème. Oui, ça peut effectivement poser problème, mais qu'en utilisant pas ce genre de code difficilement lisible, on évitait le problème. J'ai dis qu'en écrivant du code simple, lisible, pensé, on évitait ce genre de problème. C'est mal de dire ça ? Ce n'est pas le genre de code qu'il me viendrait à l'idée d'écrire, je ne peux pas le dire ?. On peut le faire, mais on regarde ce que le compilo génère, et si ça fait ce que l'on pense, si on veut se faire du mal, a soit et à ceux qui viendront après, ben, qu'on écrive ce genre de chose. Qu'y puis-je ?

Maintenant, si quelqu'un est capable d'être spécialiste de tout (ce qui n'est pas mon cas) et bien soit. Que l'on fasse écrire le code pour un guidage d'un missile par un développeur javascript qui pense que faire du i++ + ++i est une bonne idée, je me permets d'en douter. Que ça soit dans la norme ou pas, que ça soit indéfinis ou pas, c'est même pas le vrai problème, c'est juste un code peut lisible. J'ai offensé quelqu'un en disant cela ?

J'ai aussi dis que le problème de formation était générale, c'est faux ça aussi ? Il y a des gens qui pensent réellement que le niveau des étudiants a augmenté depuis d'une manière formidable ces 20 dernières années ? Bien, qu'il en soit ainsi. On voit le résultat, il est tellement magnifique que des élèves ne savent même plus lire et comprendre correctement un paragraphe de 10 lignes. C'est de ma faute aussi ? Je suis arrogant en disant cela ? Bon, je m'en excuse, continuons ainsi. Mettons des profs formés en 5 jours devant les élèves ne vas pas résoudre le problème je pense. Mais si certains le pense, encore une fois, continuons.

Bonne fin de soirée à tous. re re re Peace & Love :-)

[smarties]

Je trouve ça bien de mettre en avant Rust mais pas jusqu'à remplacer C et C++ qui ont des écosystèmes bien fournis et il n'est pas judicieux de tout refaire en Rust forcément mais sur le lancement de nouveaux projets ça s'étudie.

[OuftiBoy]

Je ne vois pas où j'ai demandé des excuses ? Tu confonds certainement avec la réponse de quelqu'un d'autre. Ou alors cite moi le passage où j'ai dis cela. Si dire qu'écrire du code du genre i++ + ++i est une mauvaise pratique, et que c'est prendre les gens de haut en le disant, je m'en excuse. Et si avoir de l'expérience (dans un domaine, pas dans tous), c'est considérer comme étant "mal", je m'en excuse aussi. Je pensais être sur un forum où les gens savaient discuter sans se vexer à la moindre vanne ou réponse dont il ne partage pas l'avis. Pardon, mille pardon. Mea Culpa.

[Kannagi]

Et oui, mettre un développeur spécialisé en javascript dans un projet où le langage sera du C, je continue de penser que c'est pas une bonne idée, et l'inverse non plus. On peut être incompétent dans un domaine particulier, et un génie (attention, je ne dis pas que je suis un génie, ne pas déformer mes propos) dans un autre domaine.

Pourquoi cite tu plusieurs fois les dev javascript ?
Tu sais que la plupart qui post ici sont des dev C ?

Puis la discussion a tourné sur le fait que i++ + ++i posait problème. Oui, ça peut effectivement poser problème, mais qu'en utilisant pas ce genre de code difficilement lisible, on évitait le problème. J'ai dis qu'en écrivant du code simple, lisible, pensé, on évitait ce genre de problème. C'est mal de dire ça ? Ce n'est pas le genre de code qu'il me viendrait à l'idée d'écrire, je ne peux pas le dire ?. On peut le faire, mais on regarde ce que le compilo génère, et si ça fait ce que l'on pense, si on veut se faire du mal, a soit et à ceux qui viendront après, ben, qu'on écrive ce genre de chose. Qu'y puis-je ?

le code i++ + ++i est un exemple de UB "amusant" ,le soucis de ce code n'est pas qu'il est illisible, il en existe près de 200 UB en C99 et ils sont tous loin d’être aussi évident :
https://gist.github.com/Earnestly/7c903f481ff9d29a3dd1
Bien sur qu'on peut écrire du C safe,mais plus le programme sera complexe, moins ça sera évident de le faire.

Tu imagine bien que pour un OS comme Linux, c'est tout sauf évident avec ces millions de ligne de code,sans parler que le noyau Linux change de compilateur vu le nombre de plateforme visé.

Un des soucis, c'est que oui, pour savoir ce que l'on fait, faut connaître l'assembleur. Je me souvient, il y a bien longtemps, dans une autre galaxie, que j'ai pigé comment les pointeurs fonctionnaient en C après avoir un cours d'assembleur. Tout d'un coup, j'ai pigé le concept. A l'époque, il n'y avait pas internet, et trouver un bon bouquin était un défit (et oui, le C de K&R et leur bouquin, c'était top).

Et oui, savoir comment fonctionne un compilateur ça aide aussi. ça devrait être obligatoire dans toute formation digne de ce nom. Et pour savoir comment ça fonctionne sous le capot, je pense qu'il faut l'ouvrir le capot, et mettre ses mains dans le cambouis. Donc faire un petit compilateur soit même, ça aide a comprendre, faire un petit noyaux temps réel (RTOS), ça aide aussi.

Mais c'est pas grave, on a formé une palanquée de développeurs a faire du java, ou des sites web en javascript, faut pas s'étonner qu'ils ne maîtrisent pas le C et/ou le C++ (je ne parle même pas de l'assembleur). J'ai peut-être l'esprit déformé, mais pour du code critique, on regarde le code qu'a générer le C -> assembleur.

Étant plus programmeur assembleur que je pratique souvent pendant mon temps libre, je peux aller aussi sur les préjugés par exemple je remarque que les vieux briscard connaisse assez mal l'assembleur même quand il l'ont pratiqué dans les années 80
La plus évidente étant qu'ils considèrent que tel instruction = tant de cycle, pourtant depuis le Pentium, ce n'est plus du tout vrai, à croire qu'ils ont arrêté de prog en asm en 1995 et/ou arrêter de lire la doc ou se renseigner dessus à partir de cette date.

Sinon tout ceux qui font de l'embarqué regarde le code assembleur, pour debug ou pour savoir si le code est correctement optimisé.
Je m'amuse pas à le regarder pour voir si y'a un bug, si le compilo à un bug, faut arrêter de l'utiliser.

[commandantFred]

Pourquoi cite tu plusieurs fois les dev javascript ?
Tu sais que la plupart qui post ici sont des dev C ?


(...)
Bien sur qu'on peut écrire du C safe,mais plus le programme sera complexe, moins ça sera évident de le faire.

Tu imagine bien que pour un OS comme Linux, c'est tout sauf évident avec ces millions de ligne de code,sans parler que le noyau Linux change de compilateur vu le nombre de plateforme visé.


Étant plus programmeur assembleur que je pratique souvent pendant mon temps libre, je peux aller aussi sur les préjugés par exemple je remarque que les vieux briscard connaisse assez mal l'assembleur même quand il l'ont pratiqué dans les années 80


Sinon tout ceux qui font de l'embarqué regarde le code assembleur, pour debug ou pour savoir si le code est correctement optimisé.
Je m'amuse pas à le regarder pour voir si y'a un bug, si le compilo à un bug, faut arrêter de l'utiliser.

Pour le C safe. Crois moi, c'est pas gagné avec les compilos actuels. Par contre, rien n'empêche de faire une compatibilité ascendante vers un fork sécurisé capable d'exécuter le vieux code , tout en offrant des options de sécurité. En fait, Microsoft a assez bien pensé ce sujet en migrant vers C# mais C n'a pas besoin du gros dotnet framework. Juste une version light mieux optimisée pour la vitesse. Le vrai sujet est : GC or not GC. On est quand même bien protégé par la GC. De toutes façons, ce sera moins performant que le C natif mais ça recyclera des milliards de lignes de code.

Vu l'actualité récente, je pense que les OS vont migrer sous Rust. Pour Linux, c'est pratiquement acté, pour les autres, je met ma main au feu si des projet ne sont pas déjà en développement.

Pour les cycles machine en asm, les cycles restent un système de comptage statistique.
La sécurité, c'est un tout autre problème. Ca ne s'invente pas. Il faut lire les bulletins mais la présidence américaine a raison sur un point. La gestion mémoire des compilateurs C (et pascal au fait) n'est plus adaptée au bordel ambiant...
Penser qu'on peut tout sécuriser par le code est une illusion. C'est le compilateur qui pose problème avec l'absence de runtime.

Intel a beaucoup travaillé sur la LLVM de Webassembly. J'y ai cru un temps mais les perfs sont très loin du compte et la normalisation du W3C est interminable. Actuellement, WASM ne gère pas du tout les strings ni les exceptions...

[OuftiBoy]

Pourquoi cite tu plusieurs fois les dev javascript ?
Tu sais que la plupart qui post ici sont des dev C ?

Je cite javascript parce que c'est un langage (que je ne pratique pas) fait pour le développement web (que je ne pratique pas nom plus). J'aurais pu parler d'un autre langage, c'est juste que ça m'est resté dans la tête en l'ayant vu passer dans la discussion. Je le connais de nom, j'ai vu quelques exemple, et ça s'arrête là.

le code i++ + ++i est un exemple de UB "amusant" ,le soucis de ce code n'est pas qu'il est illisible, il en existe près de 200 UB en C99 et ils sont tous loin d’être aussi évident :
https://gist.github.com/Earnestly/7c903f481ff9d29a3dd1

i++ + ++i, c'est amusant quand on papote sur forum, moins quand on en trouve dans du code ;-) Je sais qu'il existe des pièges dans le C, c'est pour que, faisant du C, j'évite tout ce qui est dangereux, trop nouveau. Je suis prudent, trop peut-être, mais je suis comme ça.

Bien sur qu'on peut écrire du C safe,mais plus le programme sera complexe, moins ça sera évident de le faire.

Tu imagine bien que pour un OS comme Linux, c'est tout sauf évident avec ces millions de ligne de code,sans parler que le noyau Linux change de compilateur vu le nombre de plateforme visé.

C'est certains que plus un projet est grand, plus on a de "chance" de faire quelques boulettes. C'est évident. Le meilleur moyen pour ne pas faire de bug, c'est de ne pas écrire de code :-) Mais plus sérieusement, plus on reste dans un domaine, sur un nombre d'outils, qu'on a appris, avec le temps, a bien connaître, meilleur on devient dans ce domaine. Enfin je pense cela. Maintenir une base de code comme le noyaux linux, c'est pas quelque chose que j'aimerais faire. Je sais que Linus autorise du Rust maintenant dans Linux, notamment parce que comme c'est une base énorme de C, et que pour attirer de nouveaux contributeurs (certains des premiers mainteneurs vont bien se retirer), il ouvre la porte à une nouvelle génération qui connaît mieux Rust (ou qui aiment mieux, ou qui se sentent plus a l'aise avec).

Étant plus programmeur assembleur que je pratique souvent pendant mon temps libre, je peux aller aussi sur les préjugés par exemple je remarque que les vieux briscard connaisse assez mal l'assembleur même quand il l'ont pratiqué dans les années 80
La plus évidente étant qu'ils considèrent que tel instruction = tant de cycle, pourtant depuis le Pentium, ce n'est plus du tout vrai, à croire qu'ils ont arrêté de prog en asm en 1995 et/ou arrêter de lire la doc ou se renseigner dessus à partir de cette date.

Je n'ai pas de préjugé, je pense qu'on ne sait pas tout savoir dans tous les domaines. Alors oui, je suis plutôt conservateur dans mes choix, même si en plus du C (sur micro-controleur, genre PIC/Atmel/Fujitsu(Renesas)/ST) j'utilise Python pour le reste (pas que des petits scripts, des applications Windows, avec WxPython, que j'ai appris a connaître (c'est binding sur une base en C, wxWidget anciennement wxWindows)), et là aussi, je m'en tient à "set" restreint de fonctionnalités. Python évolue très vite, j'ai peur qu'il attrape le syndrome C++, parce qu'on y ajoute pleins de choses (c'est peut-être inévitable, je sais pas) qui commencent, c'est (que) mon avis, a se dénaturer. Sinon, oui, sur les petit micro (qui eux aussi deviennent de plus en plus gros) le C est incontournable. J'ai déjà eu de compilo 'C' qui générait des erreurs à la compilation, sur du code pourtant 100% correctes. Donc oui, je regarde l'assembleur qui est généré, même si ça devient plus compliquer au fur et à mesure que les microcontroleur sont maintenant pratiquement des mini PC, avec 512K de RAM (j'ai dû me battre une fois pour faire rentrer au chausse pied un code pour un petit PIC de chez microchip qui avait 512 bytes de RAM), des périphériques intégrés CAN/USB/TCPIP. Oui, je suis un vieux Briscard, j'ai fais mes gammes sur un Commodore64 en 84 ;-) et je vais m'y remettre, car c'était trop chouette :-)

Sinon tout ceux qui font de l'embarqué regarde le code assembleur, pour debug ou pour savoir si le code est correctement optimisé.
Je m'amuse pas à le regarder pour voir si y'a un bug, si le compilo à un bug, faut arrêter de l'utiliser.

Malheureusement, même si c'est moins fréquent maintenant, j'ai eu quelques expériences avec des compilateurs C qui produisait du code buggé. Je ne citerais pas de marques, mais ça m'est arrivé plusieurs fois... D'où ma prudence sans doute.

Bonne nuit ;-)