Discussion :

[floyer]

Oui, il est théoriquement possible de faire du code C/C++ sans bug… mais avec des milliers / millions de lignes de codes, sauf à utiliser des vérifications formelles (méthode B ou autre), statistiquement il y a de fort risques de bug qui pourraient être évités par des langages plus sûrs.

Alors c’est sûr, on peut toujours dire «*c’est la faute du programmeur, pas du langage », mais il paraît que l’erreur est humaine et le programmeur humain.

Il est utile de lire https://usenix15.nqsb.io/ qui parle de problèmes d’implémentation de SSL avec beaucoup de problèmes de gestion de mémoire dans les versions usuelles écrites en C.

[commandantFred]

Oui, il est théoriquement possible de faire du code C/C++ sans bug… mais avec des milliers / millions de lignes de codes, sauf à utiliser des vérifications formelles (méthode B ou autre), statistiquement il y a de fort risques de bug qui pourraient être évités par des langages plus sûrs.

Alors c’est sûr, on peut toujours dire «*c’est la faute du programmeur, pas du langage », mais il paraît que l’erreur est humaine et le programmeur humain.

Il est utile de lire https://usenix15.nqsb.io/ qui parle de problèmes d’implémentation de SSL avec beaucoup de problèmes de gestion de mémoire dans les versions usuelles écrites en C.

Très respectueusement, je ne crois pas que ce que disent les développeurs sur la sureté de leur code fasse le poids face à des agences de sécurité disposant de budgets militaires.
Sur cette question, les développeurs sont en conflit d'intérêt. C'est comme quand un monopole d'état publie une étude anonyme sur la pertinence de son travail. C'est publié parce que la presse n'est pas regardante sur ces questions.
La NSA, la DGSI ont des obligations légales. La loyauté est inscrite dans leurs statuts et sur le contrat de travail des militaires (qui encourent la prison à vie s'ils mentent délibérément pour favoriser un groupe autre que leur gouvernement - aux USA, c'est même la peine de mort).

Ceux qui se plaignent des exploits de hackers ne sont pas souvent développeurs. D'ailleurs, personne ici n'a parlé d'attaque dont il aurait été victime. (ça m'est pourtant arrivé en 2001)

Ce serait bien de tenir compte de ce point. La sécurité d'un code ne se lit pas dans les grimoires ni dans les normes. Elle s'écoute chez les victimes de cyber-attaques.

Jusqu'ici, les directives de la DGSI n'ont pas été contraignantes mais ça pourrait changer de façon très brutale si le gouvernement décide de bannir certaines technologies trop impliquées dans l'espionnage et le vol. A ce moment, il faudra surtout répondre aux problèmes posés par les victimes. Les problèmes de développeurs, surtout s'ils sont incompréhensibles par la majorité des décideurs, n'intéresseront personne.

EDIT : Pour illustration, je citerais l'énorme scandale de la conversation entre deux officiers allemands concernant les tactiques d'attaque au moyen de missiles air-sol. Je citerai le général Richou (France) qui dit que cette conversation n'est pas un évènement. Ce qui l'est en revanche, c'est qu'elle soit parvenue aux hackers qui l'ont publiée sur les réseaux sociaux. Je ne pense pas que le sysadmin qui a autorisé cette conversation sur un logiciel mal sécurisé dorme sur ses deux oreilles maintenant. Clairement, l'armée allemande va faire une chasse au logiciel mal sécurisé et quelques têtes vont forcément tomber.

[foetus]

La sécurité d'un code ne se lit pas dans les grimoires ni dans les normes. Elle s'écoute chez les victimes de cyber-attaques.

Certes donc attendons des mois/ des années à ne rien faire. Et lorsque les rapports seront tombés, on fait quoi des projets : on les recode ? Ou alors on attend ?
Parce que selon toi, seul 1 rapport/ audit peut dire si ton projet est sécurisé ou pas. Faisons 1 projet YOLO en attendant

Comme on le dit, ce sont tous les ""bugs communs""/ ""failles de sécurité basiques"" qu'il faut éliminer en très grande partie, de façon + ou - automatique mais de façon sûre.
Pas besoin d'1 rapport pour nous dire des trucs basiques comme : ne pas mettre en clair 1 mot de passe dans le code, ne pas interpréter les textes saisis dans les zones de texte, mettre void dans les fonctions sans paramètre (A.K.A. procédure), …

Je ne pense pas que le sysadmin qui a autorisé cette conversation sur un logiciel mal sécurisé dorme sur ses deux oreilles maintenant. Clairement, l'armée allemande va faire une chasse au logiciel mal sécurisé et quelques têtes vont forcément tomber.

Tu ne sais pas comment a fuitée la conversation ? Et si c'est juste 1 des 2 militaires qui a partagée sur 1 site ou autre ? Alors quel est le rapport avec ce fil

Édit: je ne sais pas si cette affaire, mais l'Allemagne parle d' "erreur individuelle", parce qu'1 connexion n'était pas sécurisée (1 militaire n'a pas respecté les règles). Donc voila, rien à voir

[Uther]

Le problème est que la pile du C est la même que la pile système. Son pointeur est stocké dans le registre SP (stack pointer)

Heu non, chaque thread de chaque processus a sa propre pile qui est heureusement différente de celle du noyau du système d’exploitation. Sinon n'importe quel programme pourrait altérer le fonctionnement des autres, voire même de l'OS.
C'est transparent du point de vue du programme en cours d'exécution, mais le registre SP est sauvegardé/restaurée par l'OS lors des changements de contexte pour pointer sur la pile du thread en cours d’exécution.

Comme le dit OuftiBoy, plus haut, C reste le seul langage disponible pour les micro contrôleurs : Atmel, pic et surtout ESP32 aujourd'hui.

C'est vrai que certains microcontrôleurs exotiques n'ont que des compilateur en C, mais pour le coup les exemples sont mauvais car une simple recherche rapide montre que Rust les supporte, et je serais surpris que ça ne soit pas le cas de C++ aussi, vu que Rust et Clang (qui supporte le C++) s'appuient tous les deux sur LLVM pour le backend. De nos jours la plupart des compilateurs reposent sur des briques communes (LLVM, GCC) ce fait qu'il est plus simple de supporter plusieurs langages, quand on a déjà un backend qui marche pour une architecture.

Damn, trois trucs faux ou à côté en trois phrases. Je pensais que vous étiez en vacances. Vous êtes sûr de vouloir à tout prix intervenir sur ce topic ?

Non je vous assure qu'il a raison et 30 secondes de recherche sur internet vous auraient suffi pour le vérifier. Prenez au minimum la peine de faire ça avant d'accuser les gens merci.

[commandantFred]

Heu non, chaque thread de chaque processus a sa propre pile qui est heureusement différente de celle du noyau du système d’exploitation. Sinon n'importe quel programme pourrait altérer le fonctionnement des autres, voire même de l'OS.
C'est transparent du point de vue du programme en cours d'exécution, mais le registre SP est sauvegardé/restaurée par l'OS lors des changements de contexte pour pointer sur la pile du thread en cours d’exécution.


C'est vrai que certains microcontrôleurs exotiques n'ont que des compilateur en C, mais pour le coup les exemples sont mauvais car une simple recherche rapide montre que Rust les supporte, et je serais surpris que ça ne soit pas le cas de C++ aussi, vu que Rust et Clang (qui supporte le C++) s'appuient tous les deux sur LLVM pour le backend. De nos jours la plupart des compilateurs reposent sur des briques communes (LLVM, GCC) ce qu'il est plus simple de supporter plusieurs langage, quand on a déjà un backend qui marche pour une architecture.


Non je vous assure qu'il a raison et 30 secondes de recherche sur internet vous auraient suffi pour le vérifier. Prenez au minimum la peine de faire ça avant d'accuser les gens merci.

Citation Envoyé par Kannagi Voir le message
Qu'appelle tu pile systeme ?
Celle de l'OS ?
Parce que la pile de ton exécutable et celle de l'OS (et des autres applications) , sont pas dans les mêmes adresses mémoires.

Sinon non en C la taille de la pile est "infini", c'est juste l'OS qui le limite, en embarqué la pile c'est la taille de la RAM - (text/bss/data/heap).
Mais le C ne définis pas une taille précise de la pile, elle peut faire quelque Ko comme plusieurs Mo ,techniquement rien n’empêcherai d'avoir une pile de 1Go (mais l'interet serait bien limité).

Comme vous dites (avec une nuance toutefois), certains contrôleurs extrêmement populaires, vendus à des millions d'exemplaires par an, n'ont rien d'autre qu'un bootloader et un compilateur C. Ca ne les empêche pas de faire du machine learning et d'avoir une communauté de développeurs impressionnante (Atmel).

Amis du C++, je vous invite à programmer des micro contrôleurs ! Aidez nous à programmer des portails automatiques, des régulateurs mppt pour panneaux solaires, des compteurs de passages de chat, des fauteuils à télécommande et autres merveilles.
Donc oui, il y a des gens qui ont même porté Windows sur esp32, ça boote et ça affiche une boite de dialogue modale typique. Amusez vous, c'est fait pour. Mais si vous mettez cette compétence sur votre CV. L'employeur va quand même chercher votre expérience en C.
Quoiqu'on dise. C reste le plus rapide et celui qui tutoie le hardware dans sa langue maternelle.

Pour la pile infinie, je vais quand même émettre une réserve sérieuse.

Concernant le registre SP, je suis ravi que vous remettiez les pendules à l'heure. Effectivement, C comme C++ rangent leurs variables locales, leurs arguments et le pointeur de retour de fonction gentiment à l'emplacement pointé par un registre du CPU. C'est la première et la plus ancienne cause de prise de contrôle à distance. Associé à un Trojan silencieux, votre machine se retrouve entièrement sous contrôle d'un hacker, file system, pointeur de souris, droits réseau, ... Il peut même zipper vos fichiers sur votre machine et se les attacher dans un mail que VOUS allez gentiment lui envoyer. Mais il préfèrera sans doute se les uploader sur un compte cloud gratuit en binaire natif. Il peut même taper un mot de passe sans que vous n'ayez la possibilité de savoir lequel ! C'est vrai, les mots de passe, c'est personnel !

[KsassPeuk]

Dans ton lien : "They define the semantics of an imperative programming paradigm". Question naive : pour les autres paradigmes, en particulier (au hasard...) en POO, il y a des sémantiques spécifiques ou c'est la même sémantique appliquée à de la POO transformée en impératif ? EDIT: et pour la concurrence ?

Le papier d'origine c'était pour un langage impératif simple, depuis ça a été dérivé un peu pour tout et au passage, ça a été fortement amélioré par plein d'autres gens notamment Rustan Leino.
La POO au final, c'est pas si compliqué d'un point de vue logique pure: soit tu respectes le LSP et tu as déjà ta règle pour le calcul de plus faible précondition, soit c'est pas le cas, et ça devient une disjonction des différents cas d'appels.
Ce qui est plus dur, c'est la modélisation efficace de la mémoire, mais en fait c'est déjà dur en C, et les techniques dont on a besoin pour bien traiter le C sont aussi celles qui sont nécessaires pour des langages qui introduisent plus d'abstractions comme C++.

Pour la concurrence, il y a aussi plein de papiers sur le sujet. Dans les papiers fondateurs, on va avoir Owicki-Gries (https://en.wikipedia.org/wiki/Interference_freedom). Ensuite, il y a eu plein de nouvelles dérivations de ça, comme le rely-guarantee, la logique de séparation concurrente, et puis les versions relaxées pour pouvoir raisonner sur des modèles mémoire faibles comme ceux des processeurs "modernes" (je mets ça entre guillemets, parce que c'est quand même plus si jeune).
Par contre, il y a moins d'outils pour faire ça et surtout moins d'outils automatiques, il faut se palucher les preuves dans des assistants de preuve.

Oui, il est théoriquement possible de faire du code C/C++ sans bug… mais avec des milliers / millions de lignes de codes, sauf à utiliser des vérifications formelles (méthode B ou autre), statistiquement il y a de fort risques de bug qui pourraient être évités par des langages plus sûrs.

L'ANSSI (pour ne citer qu'elle) pousse de plus en plus à l'utilisation d'outils formels pour des questions de sûreté/sécurité. Par exemple, pour du CC EAL6, ils ont tendance à être beaucoup plus regardant dans les nouveaux schémas de certification : avant la demande de traçabilité modèle/code n'était pas aussi pressante de leur part. C'est plutôt vers ça actuellement que la demande en outillage pour la sûreté se dirige de leur côté et ça peut fortement améliorer la sûreté d'un code C (C++, c'est une autre histoire, le langage est super gros, et construire un outil formel pour lui, c'est une montagne de boulot). En gros, si tu veux ton tampon CC EAL7 de l'ANSSI, t'as pas le choix c'est méthodes formelles ou rien (donc actuellement en France, Atelier B, Coq ou Frama-C/WP). Mais clairement, quand on leur demande si un outil de vérification formelle pour Rust les intéresse, on a toute leur attention. Donc pour compléter, pour eux : si tu veux faire du C, soit, mais prouve moi l'absence d'undefined behaviors (et si tu veux un haut niveau de certification, prouve le reste aussi) et via des méthodes formelles, et par ailleurs "dites les chercheurs, vous pourriez pas nous faire un outil de vérification formelle industrial level pour Rust ?". Et même d'un point de vue performance des outils de preuve, c'est pas déconnant du tout. Un problème critique pour la capacité de preuve en C, c'est la séparation de la mémoire parce que les aliasing rendent l'espace de recherche dans les formules logiques exponentiel quand tu as des écritures et donc ça peut rendre certaines preuves atrocement dures, dans un langage comme Rust, la séparation des zones mémoires écrites, elle est vraie par typage dans la plus grande partie de ton programme, et ça c'est très bon pour faciliter les preuves.

(Ah et puis pour l'instant méthodes formelles sur des millions de ligne de C, c'est plutôt de l'ordre de la science fiction pour la raison invoquée précédemment : les aliasing)

[commandantFred]

Certes donc attendons des mois/ des années à ne rien faire. Et lorsque les rapports seront tombés, on fait quoi des projets : on les recode ? Ou alors on attend ?
Parce que selon toi, seul 1 rapport/ audit peut dire si ton projet est sécurisé ou pas. Faisons 1 projet YOLO en attendant

Comme on le dit, ce sont tous les ""bugs communs""/ ""failles de sécurité basiques"" qu'il faut éliminer en très grande partie, de façon + ou - automatique mais de façon sûre.
Pas besoin d'1 rapport pour nous dire des trucs basiques comme : ne pas mettre en clair 1 mot de passe dans le code, ne pas interpréter les textes saisis dans les zones de texte, mettre void dans les fonctions sans paramètre (A.K.A. procédure), …



Tu ne sais pas comment a fuitée la conversation ? Et si c'est juste 1 des 2 militaires qui a partagée sur 1 site ou autre ? Alors quel est le rapport avec ce fil

Édit: je ne sais pas si cette affaire, mais l'Allemagne parle d' "erreur individuelle", parce qu'1 connexion n'était pas sécurisée (1 militaire n'a pas respecté les règles). Donc voila, rien à voir

Vous avez mille fois raison sur le fond. La question est trop sérieuse pour attendre. C'est précisément l'objet de ce topic à vrai dire.
Donc, sur la forme, je ne pense pas qu'il faille attendre.

Le moyen le plus simple de protéger son code, c'est de l'écrire en C#. D'ailleurs, je vous signale, puisque c'est l'objection la plus fréquente, qu'on peut désactiver la garbage collection provisoirement dans ce langage. Il faut juste la réactiver avant de concaténer des Strings notamment (mais pas que)

Oui, j'ai fait auditer un code C par les services gouvernementaux et vous pouvez imaginer que tous les intervenants du projet ont suivi cette affaire de très près. J'avais du mal à trouver le sommeil en attendant leurs réponses. Heureusement, le code faisait moins de 8000 lignes et les modifications que j'ai dû faire étaient certes très perturbantes pour la lecture du code mais aussi très répétitives alors que le code était terminé et testé. Au final, c'était un travail mécanique sans mauvaises surprises.

Je suis d'accord pour la conversation entre officiers allemands. Un administrateur a autorisé l'usage d'un soft de conférence pas sécurisé (j'ai oublié son nom mais on peut le trouver dans la presse)
En seconde lecture, on peut se demander pourquoi un logiciel lambda qui demande un mot de passe et une authentification n'est pas sécurisé. Là où les allemands sonnent l'alarme, c'est que les éditeurs mettent sur le marché des passoires... C'est donc bien le marché du software généraliste qui est concerné.
Pendant le confinement, tout le monde utilisait Zoom, malgré les mises en gardes répétées concernant sa sécurité.

Mais les gens sont réfractaires au changement. Ils préfèrent minimiser le risque ou donner une excuse bidon plutôt que changer leurs habitudes. Je n'ai même pas regardé les rapports de risque de Zoom bien que je l'aie utilisé (je n'avais pas le choix en fait). Peut-être qu'un bon VPN suffit mais pas sûr que Zoom fonctionne conjointement à mon VPN.

Maintenant, j'utilise M Meet et je n'ai toujours pas fait l'effort de regarder les contraintes de sécurité...

L'objet de ce qui se passe maintenant consiste justement à améliorer la sécurité du software lambda utilisé par madame Michu. C'est au plus haut niveau des états et je crains qu'ils ne tranchent méchamment dans le vif.

EDIT : Il y a aussi un énorme patacaisse à propos des pièces jointes de mail. Notaires, services d'urgence, banques, sites de vente en ligne, etc... plein de monde envoyait des scans de documents hyper dangereux en pièce jointe. Ca ne s'invente pas. Ce sont des millions de copies de pièces d'identité, documents bancaires, etc... qui se retrouvent dupliqués à de centaines d'exemplaires dans les boites de réception et autres "Documents envoyés". Il y a un énorme travail de pédagogie à faire en plus du software à déployer (on évitera FTP !). SMTP et FTP ont plus de 50 ans, leurs mots de passe transitent en clair...

[commandantFred]

Je ne pensais pas me retrouver avec une fronde syndicale de développeurs C++ en arrivant sur ce topic.
C'est d'ailleurs la seule information utile que je retire de cette expérience. Je suppose que vous êtes plus prolixes avec des interlocuteurs qui ne remettent pas en question vos acquis professionnels. Je ne pense pas que vous soyiez aussi bourrus que vous en avez l'air mais je crois qu'il est temps de mettre un terme à cette expérience.

J'avais un tas d'autres questions à soulever. Je suis déçu par la fréquentation de ce topic et étonné que certains puissent penser qu'ils vont réhabiliter une technologie sur ce forum alors que la NSA, Google et le gouvernement américain s'acharnent à en annoncer la fin.

Cette fin sera extrêmement lente et il y aura du boulot pour les papi's du C++ largement jusqu'à nos retraites à tous. Du moins, c'est ce que je vous souhaite à tous.

[Fagus]

Evidemment qu'on teste l'absence de bug !

Tout ce qu'on sait, c'est si le teste passe ou pas, mais ça ne prouve pas l'absence de bug.

Si on écrit 1/x et que x peut être manipulé par l'utilisateur, c'est évident qu'il faut bloquer l'entrée x=0 ou prévoir le cas division par 0.
Mais si au lieu de x, on a une équation mathématique compliquée qui comporte une division, ça peut être oublié, et le programme passera tous les tests, sauf celui sur la valeur exacte qui provoque une division par zéro. C'est du vécu quand j'ai réimplémenté un algo déjà implémenté commercialement. À un moment j'ai entré la valeur spéciale dans les logiciels concurrents : bam comportement aberrant sur division par zéro oubliée.

Ou bien si on a un algo compliqué conditionnel avec plusieurs dizaines de branchements qui ne s'emboîtent pas, c'est facile dans un moment de fatigue ou sur une faute de frappe d'écrire dans un coin si x > n ... {code} ; si x<n {code} alors qu'on voulait écrire si x<=n. Le code produit une erreur de logique seulement si x=n.

Sur les atmel, esp, je ne connais très modestement que le compilateur d'arduino. On écrit souvent dans une sorte de c, mais c'est un compilateur c++. C'est pas très élégant, mais ça m'arrive d'écrire en mélange de c/c++ parfois, tant que ça consomme pas trop de ressources.

[commandantFred]

Tout ce qu'on sait, c'est si le teste passe ou pas, mais ça ne prouve pas l'absence de bug.

Si on écrit 1/x et que x peut être manipulé par l'utilisateur, c'est évident qu'il faut bloquer l'entrée x=0 ou prévoir le cas division par 0.
Mais si au lieu de x, on a une équation mathématique compliquée qui comporte une division, ça peut être oublié, et le programme passera tous les tests, sauf celui sur la valeur exacte qui provoque une division par zéro. C'est du vécu quand j'ai réimplémenté un algo déjà implémenté commercialement. À un moment j'ai entré la valeur spéciale dans les logiciels concurrents : bam comportement aberrant sur division par zéro oubliée.

Ou bien si on a un algo compliqué conditionnel avec plusieurs dizaines de branchements qui ne s'emboîtent pas, c'est facile dans un moment de fatigue ou sur une faute de frappe d'écrire dans un coin si x > n ... {code} ; si x<n {code} alors qu'on voulait écrire si x<=n. Le code produit une erreur de logique seulement si x=n.

Sur les atmel, esp, je ne connais très modestement que le compilateur d'arduino. On écrit souvent dans une sorte de c, mais c'est un compilateur c++. C'est pas très élégant, mais ça m'arrive d'écrire en mélange de c/c++ parfois, tant que ça consomme pas trop de ressources.

Oui ça me rappelle un tas de trucs aussi. Je suis le gars qui demande 100 Gb de données à tester et, croyez moi ou non, à ma façon de les demander, je les obtiens toujours. Après je lance plusieurs machines en accès concurrent pour provoquer un max de collisions réseau et je laisse tourner le weekend.
Je me suis toujours demandé pourquoi les compilateurs ne proposent pas l'option "En cas de zéro division, retourner : -1 | 0 | 1 | NULL | lever exception. C'est juste histoire de la rendre non-bloquante... Humain répond : "Ah, non, ce n'est pas conforme" | "Ah oui, c'est bizarre mais ça ne bloque pas"... (rayer mention inutile)

Sinon tu mets Si x> n ... ELSE .. haha

Le compilateur arduino est moche mais il marche bien. Les Raspberries sont revenues à des prix décents mais quand même plus chères qu'avant. Peut-être pour faire payer les martiens qui les utilisent pour piloter leurs drones contre les neptuniens... A ce sujet, j'ai supprimé les codes d'IA pour piloter des robots de mes pages quand j'ai appris que des vénusiens s'en servaient pour manoeuvrer leurs engins tueurs. Ensuite, je me suis dit que pour eux, c'était aussi pour sauver leurs vies, ça m'a dégoûté de publier du code de pilotage d'engin. Je n'ai pas remis le code en ligne : un genre de pacifisme, héritage culturel difficile à résoudre. Anyway, ce n'était pas un code impossible à reproduire mais il était testé sur de vrais engins donc, gros gain de temps pour ceux qui cherchaient au printemps 2022.

En fait, je programme le dimanche aussi. Et les autres jours aussi.

message sympa merci

[OuftiBoy]

Concernant le monde de l'embarqué, ce n'est aussi simple que.

Quant on a une base de code, écrite en C, qui est utilisée depuis de 20 ans sans le moindre soucis, rien que le fait de la réécrire sera plus dangereux que de garder ce qui fonctionne depuis des années. Pas seulement en terme de "Bugs", mais aussi en terme fonctionnalités, il y'a parfois des routines très pointues, qui on été étudiées, testées (je par de fonctionnalité), et validées. Les réécrire a l'identique, avec un autre langage, n'est souvent tout simplement pas possible. Des fois, une fonctionnalité fonctionne correctement ou pas, et ça se joue à quelques µs.

Je voudrais ajouter aussi à la discussion, que même si en effet, les microcontrôleurs deviennent de plus en plus gros, que ce n'est forcément ceux-là qu'on va utiliser. On nous déjà fait changer de microcontrôleur, pour gagner 0,10 €. Lorsque l'on produit en grande série, le moindre centime d'économisé peut faire qu'un produit se vende bien ou pas. Car entre ceux qui font la produit, et ceux qui l'utilisent au finale, il y'a plusieurs couches d'acteurs qui chacun, et c'est bien compréhensible, doit faire une marge. Et au final, le 0,10€ devient 1€. Si on multiplie par des dizaines de milliers de produit, et que chaque produit final comporte plusieurs sous-système, la note au final peut être énorme.

De plus, en entreprise, il est important de garder une cohérence, s'il y a disons 20 dev maîtrisant le C, on ne vas pas passer à Rust (ou autre), si facilement. Le changement fait peur, et autoriser un nouveau dev a utiliser un autre langage, fait que lui seul pourra auditer son code. On ne passe pas une équipe de 20 dev du C a Rust en disant juste que ça va permettre de régler des problèmes qui n'existe pas (vu la base de code qui a prouvé sa qualité depuis des décennies).

Je ne suis pas contre Rust, mais j'ai du mal a penser qu'il peux régler tous les soucis, d'une variété d'utilisations énorme (de l'embarqué aux gros sites Web qui doivent être hyper sécurisé). Les vrais soucis viennent plus souvent des technologies "du Web", que du code de bas niveau. Je n'ai jamais voulu faire du dev Web, car de ce que je vois, rien n'est jamais vraiment stable dans cet écosystème. Ce qui était adulé il y a 1 an, et jeter aux ordures, pour le nouveau "framework" à la mode. Des couches, sur des couches à n'en plus finir, qui sont souvent écrites par des dev peu expérimentés, ça peut vite créer des soucis, je le comprend très bien.

Il y a aussi eu le (selon moi), néfaste passe des smatphones, qui ont changés la manière, ne fusse que visuel des sites web, qui a influencé le dev des applications que je nommerais "Bureautique". On veut tout faire dans un navigateur, qui en quelque sorte, "remplace", l'OS de base petit à petit. Il faut que tout soit connecté à tout, même quant ce n'est pas nécessaire, ce qui multiplie les risques. Pour ma part, je regrette le temps du début d'internet, où l'on consultait des info, sans plus. Beaucoup de soucis liée a des attaques, on déferlés suite à l'introduction, petit à petit, de "programmation dans le web". Je déteste au plus haut point les "application dans le navigateur", rien qu'en terme d'expérience utilisateur, c'est tout simplement une horreur. Ce qu'on autorise sans soucis dans une application web (du genre tu clique sur un bouton, et entre-temps, la mise en page se fait progressivement, et que le bouton n'est plus à la même place, ou que des boutons ne ressemblent plus à des boutons, pour une soit disant question de design, ou que tu doivent "scroller" pour trouver le bouton pour ne fussent que valider un choix, serait tout simplement considéré comme une erreur sur une application de bureau "classique").

Bref, tout n'est pas binaire, noir ou blanc, toute la palette de gris s'étalent entre différents problèmes, et il n'y a et n'aura pas UNE solution pour régler les différents soucis de notre discipline, que nous aimons tant.

C'était mes pensées du jour. BàV, et comme je dis souvent, Peace & Love :-)

[KsassPeuk]

Autant sur la difficulté à migrer quand on a toute son infrastructure écrite en C, j'y souscris, autant ceci :

Je ne suis pas contre Rust, mais j'ai du mal a penser qu'il peux régler tous les soucis, d'une variété d'utilisations énorme (de l'embarqué aux gros sites Web qui doivent être hyper sécurisé). Les vrais soucis viennent plus souvent des technologies "du Web", que du code de bas niveau.

me semble trompeur. Rust ne prétend pas régler tous les soucis. Le principe de Rust c'est conserver un maximum de contrôle et régler par typage une classe particulière de problèmes qui sont ceux liés à la mémoire (et ça ne règle pas tout un tas d'autres undefined behaviors par ailleurs genre tout ce qui est integer overflows). Malgré tout, entre 2013 et 2017, les CVEs liées à la mémoire, ça représentait autour de 20% des CVEs annuelles (d'après l'analyse dans la vidéo plus bas, 53% des CVEs sont dues à : Buffer Overflow (~6000 sur 5 ans) + SQL Injection (~6000 sur 5 ans) + Info leak (~3000 sur 5 ans)). 20% juste pour une classe d'erreur dont on comprend aujourd'hui comment s'en prémunir au niveau typage, c'est pas anodin. Je ne sais pas comment ça a évolué entre 2017 et 2022 ceci dit (enfin, pour les trucs non-critiques), mais je ne crois pas qu'il y ait eu un énorme changement dans les pratiques de ce côté.

La dite vidéo (navré, j'ai trouvé aucun moyen dans l'éditeur de ne pas mettre l'embedding, peu importe ce que je fais l'éditeur insiste pour mettre automatiquement l'embedding...) :

[OuftiBoy]

Je suis en effet d'accord. En fait, mon post visait à dire qu'il n'y a pas de solution "magique". Je suis d'accord pour dire que Rust propose de bonnes choses. Je voulais attirer l'attention sur le fait que c'est un peu facile de dire aux dev de "changer de langage", "arrêter" d'utiliser ceci ou cela (dans le cas de cette discussion, arrêter le C (impossible actuellement dans certains domaines), et le C++ (lui, je l'ai laissé tomber depuis assez longtemps, car il dérivait vers un syntaxe rendant la lisibilité de son code)), et remplacez le par Rust. Que c'était facile à dire, mais pas forcément a faire.

Je pense cependant qu'une trop grande "connectivité" de tout à tout, sans que ça soit forcément nécessaire, ne fait qu'empirer le problème. Des fois, à vouloir trop bien faire, on fait pire.

Je vais tenter deux analogies.

1./ Après le 11 septembre, et les avions détournés en envoyés dans les tours (je ne suis pas complotiste, mais y'a des choses qui me trouble toujours ajd à ce sujet, mais c'est une autre histoire).

Bref, pour "bien faire", on rendu l'accès au cockpit impossible, afin d'éviter d'autres détournements et drames. Malheureusement, ceci a causé d'autres drames, comme celui ou un gars dépressif c'est enfermé dans le cockpit pour laisser lentement son avion aller s'exploser contre une montage. Y'il a eu d'autres cas similaires.

2./ Dans un autre genre, le cas du Being MAX, et de son fameux logiciel MCAS. Outre le fait qu'on a laissé Boeing en grande partie s'auto certifier, le problème qu'on a désigné, c'était le logiciel MCAS. Ceci me pose problème, car l'origine du soucis vient d'ailleurs.

- Il n'y a pas eu d'informations au sujet de ce logiciel avant les 2 drames. Même les pilotes les plus aguerrit on été perturbé par ce dernier, car il n'en connaissait tout simplement pas l'existence.

- Il n'y avait pas de redondance de la sonde qui envoyait les info au logiciel (ce qui me semble obligatoire dans le cas de tout système mettant en jeu la vie d'autrui).

- La conception même de l'avion, d'après ce que j'en sais, posait problème. J'ai retenu de cette histoire (qui n'est pas encore finie je pense), que le déplacement des moteurs par rapport au modèle de base, posait un problème physique, rendant dangereux cet avion. D'où la création du fameux logiciel MCAS. C'est un cas typique où le software ne peux pas toujours compenser les soucis "Hardware".

Bref, la conclusion que je tire de tout cela, c'est que "rien" n'est sécurisable a 100%. Et ceci dans tous les domaines, pas qu'en "informatique", et qu'il vaut mieux, parfois/souvent, ne pas tirer de conclusions hâtive, et surtout, ne jamais croire qu'une solution parfaite peut exister.

Je ne dis pas qu'il ne faut pas mettre en place tout ce que l'on peut pour diminuer le risque. Pour les problèmes lié a "l'informatique", le seul moyen d'arriver au risque 0, ce serait de NE PLUS faire d'informatique. Je sais qu'en France, on appuie fortement sur le "principe de précaution", qu'on pousse parfois à l'extrême (sauf pour le covid, mais c'est encore un autre sujet). Si on fait un résonnement par l'absurde (je suis Belge, donc c'est dans mes gênes :-)), le seul moyen d'éviter toute mort serait de ne plus engendrer la vie.

Donc oui pour progresser, non pour "trop" ou "trop vite" changer. Et je pense quant même que le "tout connecté" est une des pires choses qui pouvait arriver pour augmenter le nombre de catastrophes, que si l'on veut aller vers plus de "sécurité", peut-être que penser a "diminuer" cette hyper "connectivité" ne serait pas non plus une partie de la solution.

BàV. Peace & Love.

[djm44]

Je ne suis pas contre Rust, mais j'ai du mal a penser qu'il peux régler tous les soucis, d'une variété d'utilisations énorme (de l'embarqué aux gros sites Web qui doivent être hyper sécurisé). Les vrais soucis viennent plus souvent des technologies "du Web", que du code de bas niveau. Je n'ai jamais voulu faire du dev Web, car de ce que je vois, rien n'est jamais vraiment stable dans cet écosystème. Ce qui était adulé il y a 1 an, et jeter aux ordures, pour le nouveau "framework" à la mode. Des couches, sur des couches à n'en plus finir, qui sont souvent écrites par des dev peu expérimentés, ça peut vite créer des soucis, je le comprend très bien.

C'est tout à fait pertinent. L'univers des failles et des vulnérabilités se pose principalement mais pas exclusivement dans le développement Web. A partir du moment où les données doivent transiter sans être exposées on est plus dans un champ de compétences réseaux en l'occurrence internet et non pas dans un problème de langage. Rust ne peut pas prévenir des anomalies dans le trafic internet. C'est une rustine mémoire qui verrouille une partie de la mémoire sans plus. Que l'on fasse autant de bruits à ce sujet est exagéré.

Si le protocole SSL ou TSL par exemple sont défaillants Rust ne change rien. Maintenant si les développeurs veulent refaire les logiciels en Rust pourquoi pas cela ne change rien au fait que l'on puisse faire des logiciels surs en C et C++. Si un algorithme de hachage peut être attaqué c'est l'algorithme qu'il faut revoir pas le langage. Si un processeur dispose d'une mémoire cache pour prévenir de l'ordre des instructions à exécuter on est confronté à une spécificité matérielle sans rapport avec un langage quelconque .


Ceci étant de nombreux logiciels gèrent mal la mémoire en C++ par prolifération d'allocations pour mettre en oeuvre des fonctionnalités. Et ces allocations par la suite sont difficiles à libérer par exemple dans les environnements graphiques.

[OuftiBoy]

Alors j'ai un peu cherché:

https://en.wikipedia.org/wiki/Cyclon...ming_language)

Il s'agit d'une version plus Safe du C: Il y est mentionné que Rust y a puisé pas mal d'idées.
Pourquoi ça n' pas prit à l'époque, je ne sais pas.

Mais qd on fait de l'embarqué, c'est assez utile. (le temps pour l'allocation est déterministe).
De même, dans un passé lointain, c'était une bonne méthode de réutilisation de la RAM. Sans allocation dynamique et tous les soucis que ça peut engendrer si on ne fait pas attention. L'idée est très ancienne (apparemment, D. knuth on parlait déjà dans The Art Of Computer Programming).

Perso, j'avais entendu parlé de ça via µC/OS2 https://www.silabs.com/developers/micrium)

Il y a plein de système de ce genre avec leurs avantages et désavantages. Je pense même qu'un dev de Qt a lui aussi redécouvert la chose:
https://www.qt.io/blog/a-fast-and-th...-for-qt-part-1

C'est dans les vieilles marmites qu'on fait les meilleurs soupes disait ma grand-mère.

C'est juste pour alimenter la discussion :-)

BàV. Peace and Love.

[floyer]

Très respectueusement, je ne crois pas que ce que disent les développeurs sur la sureté de leur code fasse le poids face à des agences de sécurité disposant de budgets militaires.

Certes, certes, mais si une conception logicielle diminue la surface d’attaque par 2… même s’il reste un risque vis-à-vis des agences gouvernementales, c’est toujours cela de pris. L’article que je cite catégorise les défauts de plusieurs implémentations de TLS et on trouve des défauts au niveau de la mémoire qu’un langage d’assez haut niveau sait gérer et donc éviter.

Ceux qui se plaignent des exploits de hackers ne sont pas souvent développeurs. D'ailleurs, personne ici n'a parlé d'attaque dont il aurait été victime. (ça m'est pourtant arrivé en 2001)

Oui… l’attaque vise toujours un code déployé et utilisé chez un utilisateur, pas le développeur. Mais c’est bien du développeur et de ses outils que viennent les problèmes.

Ce serait bien de tenir compte de ce point. La sécurité d'un code ne se lit pas dans les grimoires ni dans les normes. Elle s'écoute chez les victimes de cyber-attaques.

Il y a deux manière de résoudre le problème : de façon réactive (ah, une CVE publiée, je la corrige), et proactive: à défaut d’une analyse de code fastidieuse, utiliser des outils d’aide, SonarCube et autres, et en amont des langages qui limitent les risques (sans les annuler… une SQL injection sera toujours possible indépendamment du langage). Quand aux victime, que savent t-elles des raisons qui on permis l’attaque (buffer overflow, SQL injection). Pas sûr qu’en les écoutant on fasse avancer la science à ce sujet.

A ce moment, il faudra surtout répondre aux problèmes posés par les victimes.

Une fois que la victime est victime… il est trop tard. C’est dès la production du logiciel qui faut se poser des questions. Je ne vois donc pas le propos.

EDIT : Pour illustration, je citerais l'énorme scandale de la conversation entre deux officiers allemands concernant les tactiques d'attaque au moyen de missiles air-sol. Je citerai le général Richou (France) qui dit que cette conversation n'est pas un évènement. Ce qui l'est en revanche, c'est qu'elle soit parvenue aux hackers qui l'ont publiée sur les réseaux sociaux. Je ne pense pas que le sysadmin qui a autorisé cette conversation sur un logiciel mal sécurisé dorme sur ses deux oreilles maintenant. Clairement, l'armée allemande va faire une chasse au logiciel mal sécurisé et quelques têtes vont forcément tomber.

Ce qui illustre que la SSI est un problème d’ensemble, architecture, principe du moindre privilège, langage, défense en profondeur, hygiène informatique, sensibilisation du personnel… c’est très vaste. Mais l’usage de bon outils (langages, linter, croisement SBOM/bases de CVE…) ne peut qu’aider sans tout faire.

D’une certaine manière le passage à Rust ou un langage plus sûr est comparable au passage de la NASA au système métrique suite à l’échec de Mars Climate Orbiter. On peut ergoter… le problème aurait pu être éviter si le concepteur avait bien fait ses calculs (ce qui aurait pu être possible). Mais d’un autre côté, des outils plus sûr limitent les risques.

[commandantFred]

Alors j'ai un peu cherché:

https://en.wikipedia.org/wiki/Cyclon...ming_language)

Il s'agit d'une version plus Safe du C: Il y est mentionné que Rust y a puisé pas mal d'idées.
Pourquoi ça n' pas prit à l'époque, je ne sais pas.

BàV. Peace and Love.

Je suis allé voir. Il y a une GC sur les données de heap. En même temps, les strings sont null terminated. C'est sûrement pour la compatibilité. En même temps, j'ajoute ma pierre aux grands gourous du C que j'ai connu, les \0, c'est vraiment la mmm.. : toujours ajouter 1 à la taille des chaines, le zéro est sauvé sur disque ? oui/non etc...
C n'a jamais été copié sur cette gestion. Les langages les plus primitifs font pointer les chaines sur un descripteur, généralement un entier qui donne la taille, suivi du contenu sans terminateur.

Quand elles sont bien comprises, les chaines du C permettent de gérer des pointeurs internes plus rapidement que n'importe quoi d'autre. OUI MAIS : entretemps, les choses se sont gâtées parce qu'on stocke désormais le texte en UTF-8 ou sur deux bytes. L'ascii 128, c'était avant...

Donc, quitte à laisser son exception culturelle au C sur les char* , autant les laisser tels quels. On peut stocker les chaines sur des int16* ce qui reste assez élégant. Pour l'UTF8, c'est moins joli mais de toute façon, je ne connais rien d'aussi disgracieux que ce fichu UTF-8 !

Il y a aussi cette "obligation" de tous les éditeurs à ne jamais travailler directement dans le buffer des chaines. On la clone d'abord, on exécute les traitements sur le clone et on remplace l'original qu'on poubellise. J'avoue ne pas comprendre pourquoi les ééditeurs sont tellement à cheval sur cette gestion mais devant l'unanimité, je ne m'amuserai pas à entrer en contestation sur la méthode.

Au final, la GC disqualifie Cyclone pour les acharnés du hardware et du cycle machine... Dans les faits, je me demande comment gérer les redondances pour compatibilité ascendante dans le quotidien d'un développement. Qui va développer avec des redondances pénalisantes juste pour rester compatible avec les vieilles versions de C ?
On a une Garbage Collection ou on n'en a pas ! Si on l'a, autant écrire un langage qui l'utilise bien (et qui permet de l'interrompre comme C#). Visiblement les GAFAM's ne veulent pas de GC pour leur bas niveau.

A propos de GAFAM , vous avez vu le casting de la fondation Rust (encadré en bas de la page wiki anglaise) je copicolle :
Founders
Amazon Web Services
Google
Huawei
Microsoft
Mozilla Foundation

Pas mal...

[foetus]

Quand elles sont bien comprises, les chaines du C permettent de gérer des pointeurs internes plus rapidement que n'importe quoi d'autre. OUI MAIS : entretemps, les choses se sont gâtées parce qu'on stocke désormais le texte en UTF-8 ou sur deux bytes. L'ascii 128, c'était avant...
Donc, quitte à laisser son exception culturelle au C sur les char* , autant les laisser tels quels. On peut stocker les chaines sur des int16* ce qui reste assez élégant. Pour l'UTF8, c'est moins joli mais de toute façon, je ne connais rien d'aussi disgracieux que ce fichu UTF-8 !

Es-tu sûr de ce que tu racontes ?

Parce que:
1) l'UTF-8 c'est entre 1 et 4 octets par point de codage. Il est compatible ASCII.
Lis la page Wikipédia: le premier octet contient la taille. Et donc oui, l'UTF-8 est très difficile à découper caractère par caractère parce qu'il faut lire la chaîne en même temps.
Mais 1 char* suffit, mais sa taille mémoire est différente de son nombre de caractères (sauf ASCII)

2) l'UTF-16 c'est 2 octets par point de codage. En C, tu as le nouveau type wchar_t et tout 1 pan de la bibliothèque standard a été refaite pour supporter l'UTF-16.
Le problème, c'est 1 caractère peut-être soit 1 point de codage (2 octets) soit 2 points de codage (4 octet). Ce sont les "surrogate pairs"
Par exemple, c'est soit 'é' (e accent grave) soit 'e' + '\'' (e + l'accent grave).
C'est pour cette raison que wchar_t c'est soit 2 octets sous Windows soit 4 octets sous Linux/ OS X.
Mais le découpage caractère est simple (wchar_t par wchar_t, je pense éventuellement 2 octets par 2 octets). Par contre sa taille mémoire peut être différente de son nombre de caractères

3) l'UTF-32. Là pas de problème, 1 point de codage c'est 4 octets. La taille mémoire d'1 chaîne de caractères est par contre assez conséquente.

4) Et pour les dinosaures, tu as aussi les "code pages" (ANSI, Latin-1, Shift-JIS, OEM (console Windows),…) : MBCS ("Multi-Byte Character Set") ici c'est 1 octet sauf les "code pages" étendus sur 2 octets.

Édit : @Pyramidev me répond message #168
Et j'ai changé effectivement caractère par "point de codage" qui est le bon terme

[OuftiBoy]

Juste que Rust n'a rien inventé, je n'y peut rien, ce sont les faits.

Reste que objectivement, avec un pool de mémoire gérer de la sorte, ça permet d'éviter des malloc/free à tout bout de champs. Le problème d'un GC, (qui n'est pas obligatoire), c'est que soit on le laisse faire qd il veut, soit il faut trouver un moment adéquat, mais pourrait ne plus l'être après un upgrade de code. Encore une, je n'ai rien contre Rust, mais les notion de Owner/lifeTime etc, ça me semble plus compliqué que de de savoir faire correctement un malloc et un free. Un simple teste pour voir si on a fait le même nombre de free que de malloc (y'a des outils qui font ça très bien, je pense à valgrind sous linux), et d'autres outils d'analyse de code statique du code peuvent aussi trouver une partie des problèmes. ça devrait obligatoirement se trouver dans toute bonne chaine de production de code. Pas seulement à la fin du développement, quant on ne peut plus faire grand chose, mais quotidiennement.

Il y a souvent trop de légèreté, mettre par exemple tous les "warning" on, c'est déjà trop pour certains. Le code doit se compiler sans un seul warning. Même en Python (langage de haut niveau s'il en est), un simple passage via PyLint peut révéler énormément de choses. Toujours dans Python, il y le "Typing" qui est arrivé depuis peu, autant l'utiliser, même si ça alourdit la syntaxe. Et là non plus, tout ne se passe pas bien du premier coup. Il y a eu de nombreuses itérations avant d'arriver à un certains point d'équilibre et de rendre cela vraiment utile.

Il y'a bien sûre de grands noms derrière la Fondation Rust, tout comme il y a/avait des grand nom derrière le notion de POO, qui n'est pas toujours bien implémentée, et/ou pas très bien utilisée. Des hiérarchies de classe grandes comme la Pyramide de Kheops, c'est un mauvais signe. Il faut toujours préférer la composition à l'héritage. L'encapsulation n'apporte rien. Et le polymorphisme, s'il est mal supporté/implémenter/utiliser peut lui aussi faire des ravages. Et pour tout dire, le fais qu'il y ai des "grand nom" qui poussent une technologie n'est absolument pas un gage de sécurité. Google pompe les données des utilsateur pour placer sa Pub, Microsoft n'arrête pas de changer d'avis (MFT, WInForm, XAML, Silverpoint, ModerUI; ...) De la stabilité ne serait pas un luxe. Boeing aussi, c'est "un nom", ça ne les a pas empêcher de laisser voler un avion qui n'aurait jamais dû décoller ;-)

J'ai dû surveiller du code C#, dans un assez gros projet, et il est très verbeux, et pas forcément très lisible. Et de toute façon, encore une fois, on ne peut pas mettre du C# partout. Un charpentier utilise un tournevis pour viser, et un marteau pour clouer, pas l'inverse.

Le bon sens se perd. Une fonction de 300 ligne ne gêne pas certains. J'ai déjà vu un code où certaines lignes (en C#) faisaient plus de 600 caractères de long !!! Quande je disait que c'était du mauvais code, on me répondait que le code "marchait". Soit. Un moment donner, on laisse les gens faire comme il veulent, s'ils ne veulent rien entendre, je ne vais pas me faire un ulcère pour eux.

Moi, je m'en tiens à des fonctions de maximum 25 lignes, des classes avec peut de méthodes, privilégie la composition à la place de l'héritage, et toujours des lignes de max 78 car de long. ça rend l'ensemble bien plus lisible, et quand c'est lisible, on voit plus vite des problème que lorsque ça ne l'est pas, ça me semble une évidence.

Et je maintien qu'on ne peut pas être "spécialiste" de tout. Un moment donné, on choisis une orientation, et on essaye d'être constant et de progresser dans une ou deux spécialité. Bcps semblent dire qu'ils maîtrisent 25 langages et 89 frameworks, je me méfie toujours un peu quand j'entend ce genre d'affirmations... Certains sont comme des médecins généralistes, d'autre des chirurgien de haute volée, mais je ne m'adresserait pas à eux pour faire la maintenance de ma chaudière. Mais en informatique, ça passe crême. On fait bosser un gars pendant 5ans sur du code java, puis la semaine d'après en le place sur un projet C#, et s'il ne sait pas pourquoi ton PC a planté, on le regarde de travers.

Du bon sens, de l'humilité et savoir dire NON qd on nous demande de faire quelque choses avec une "techologie" qu'on ne maitrise pas. Et c'est pas en envoyant le gars qui a fait 3 ans de C++ suivre une "formation" (je n'ai jamais suivit une formation qui en valait la peine, mais comme ça, le manager est couvert, s'il y a un soucis, il dira qu'il avait envoyer le gars faire une formation).

Pleins de gens aiment faire de la peinture, mais on ne leur abois pas dessus s'il ne sorte pas une copie parfaite d'un Van Goht et la semaine d'après les envoyer restaurer le plafond de la chapelle sixtine (sorry je ne connais pas le nom exacte).

Donc le gars de la maison blanche qui demande à plusieurs millions de développeurs d'arrêter d'utiliser le C / C++ pour "des langages qui protègent mieux la mémoire", j'ai difficile de le prendre au sérieux. Il ne vas pas se permettre de dire aux ingénieur de boeing de faire correctement leur boulot, mais les dev, on peut les mettre à toutes les sauces, on trouve ça normal.

Bon, BàV, Peace and Love.

[commandantFred]

Es-tu sûr de ce que tu racontes ?

Parce que:
1) l'UTF-8 c'est entre 1 et 4 octets par caractère. Il est compatible ASCII.
Lis la page Wikipédia: le premier octet contient la taille. Et donc oui, l'UTF-8 est très difficile à découper caractère par caractère parce qu'il faut lire la chaîne en même temps.
Mais 1 char* suffit, mais sa taille mémoire est différente de son nombre de caractères (sauf ASCII)

2) l'UTF-16 c'est 2 octets par caractère. En C, tu as le nouveau type wchar_t et tout 1 pan de la bibliothèque standard a été refaite pour supporter l'UTF-16.
Le problème, c'est 1 caractère peut-être soit 1 caractère (2 octets) soit 2 caractères (4 octet). Ce sont les "surrogate pairs"
Par exemple, c'est soit 'é' (e accent grave) soit 'e' + '\'' (e + l'accent grave).
C'est pour cette raison que wchar_t c'est soit 2 octets sous Windows soit 4 octets sous Linux/ OS X.
Mais le découpage caractère est simple (wchar_t par wchar_t, je pense éventuellement 2 octets par 2 octets). Par contre sa taille mémoire peut être différente de son nombre de caractères

3) l'UTF-32. Là pas de problème, 1 caractère c'est 4 octets. La taille mémoire d'1 chaîne de caractères est par contre assez conséquente.

4) Et pour les dinosaures, tu as aussi les "code pages" (ANSI, Latin-1, Shift-JIS, OEM (console Windows),…) : MBCS ("Multi-Byte Character Set") ici c'est 1 octet sauf les "code pages" étendus sur 2 octets.

Merci pour tout ça mais je n'avais pas envie de m'éterniser sur les questions de jeu de caractères. Comme vous le savez peut-être, l'important est de connaitre le bon nombre de bytes pour sizeof() et pour l'arithmétique sur ptr. Ensuite, il y a les trucs de gcc mais gcc n'est ni la question posée ni vraiment un sujet que j'ai envie de développer.

Je parlais d'un compilateur nommé cyclon, abandonné depuis longtemps et qui donc se réfère à une époque différente.

Ce serait bien de ne pas systématiquement revenir aux normes machin chose qui ont leur utilité mais ne constituent pas l'univers du C. J'ai failli prendre une mission en C récemment, j'aurais pu étaler toute la panoplie des dernières normes pour se faire bien voir (et éviter des procès). Mais là, ce n'est pas le sujet.

Donc oui, je suis sûr de ce que je raconte , on ne parle pas de la même chose. Les jeux de caractères sont innombrables, rien que dans mon éditeur html, j'en ai une soixantaine ! Imaginez que je vous les liste tous avec une explication pour chaque... OEM XX-nn est bien adapté au cunéiforme et au serbo-croate mais se prête moins bien au sanscrit... Damn, la journée va être longue...