David Delassus a écrit 762 commentaires

J'attend le support des modèles C4 dans mermaid pour m'en servir : https://github.com/mermaid-js/mermaid/issues/1276

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Il y a une différence entre :

• une faille de sécurité dans un composant critique de 80% de l'infrastructure IT mondiale

Et

• une faille de sécurité dans un logiciel utilisé de manière anecdotique par quelques utilisateurs

Oui, dans les 2 cas c'est des failles de sécurité. Non toutes les failles ne se valent pas en terme de criticité. Dans le cas de Gimp, soit c'est une nouvelle faille et dans ce cas tu rollback, soit c'est une ancienne et tu attends le fix.

Dans le cas d'un composant critique tel que OpenSSL ou la stack TCP du kernel, là, il y a urgence car des millions de personnes et des milliards de devices sont potentiellement en danger.

Il faut prendre en compte la taille du vecteur d'attaque quand tu évalue la criticité d'une faille. Non un buffer overflow dans Gimp qui permet l'exécution de code arbitraire n'est pas si grave. C'est pas comme si tu pouvais en faire un rootkit. L'attaque est difficile à industrialiser car il faut que tu puisse transmettre l'image vérolée à ta cible, et être sûr qu'il va l'ouvrir naïvement avec la bonne version de Gimp et que son anti-virus ne va pas détecter du code exécutable dans une image.

Mais oui, c'est vrai, je ne comprend rien au sujet, je suis un ignare, blah blah blah, dénigre autant que tu veux. Comportement très mature de ta part.

J'arrête de débattre avec des sourds, tchao.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Tu écris peut-être du C-linkdd

Non, comme je l'ai dit précédemment, j'écris du C + Compilo + CPU. Par exemple :

• C + GCC 8.3 + x86
• C + CLang 7.2 + arm64
• C + BCC + Intel 6809

Comme quoi, faut bien lire tout dans son ensemble pour comprendre un argument.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

sans me faire pwner

Comment tu peux te faire pwn avec un programme qui accède pas à internet ? Tout les échecs ne sont pas critique.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Écrire 10 lignes de C sans UB, ça demande un talent et un temps dont peu de personnes disposent.

Et alors ?

Il faut arrêter de voir le C comme un langage haut niveau du même type que le C++ ou Python.

Le C permet des choses formidables mais il amène de gros coûts, qui se résolvent très mal avec des yakas.

Aujourd'hui, si tu as besoin des performances du C, tu y vas tout en sachant qu'il y a des footguns, et tu mets les gardes fous en place pour t'empêcher de faire de la merde.

Coder en C, ce n'est pas avoir une épée de Damoclès au dessus de la tête en plein milieu d'un champ de mine. C'est le cas si tu code sur libopenssl ou un kernel. Mais un segfault dans gimp ? Osef total, bug tracker + fix à la prochaine release.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

C'était un des attraits du C à la base : la portabilité.

Et donc dans ce cas la, tu évites les undefined behavior comme j'ai dit plus haut.

Dépendre des undefined behavior ne rend pas ton programme invalide, il le rend pas portable, c'est tout.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Il n'a aucune garantie que la prochaine version de son compilateur fasse la même chose

Lorsque l'on dépend d'un undefined behavior, on lit la spec du compilo avant de le mettre à jour.

Il n'a aucune garantie que le changement d'une option de son compilateur continuera à faire un programme qui a le même résultat.

On lit la spec du compilo avant de faire joujou avec ce qui fonctionne.

Il ne faut pas avoir d'UB en se disant "je sais ce que je fais".

C'est le principe même des Undefined Behavior.

Quand tu programme en C, tu programme en C + Compilo + CPU. C'est pour ça que tu as les mots clés volatile / register / etc… pour contrôler le comportement du compilo dans ton code.

Le C est un langage bas niveau, c'est de l'ASM avec une syntaxe moins dégueulasse. Si tu fais de l'ASM sans lire la doc de ton CPU, ton programme est certain de ne pas être valide. C'est pareil en C, que tu évite les undefined behavior ou non.

Non, un programme avec un UB n'est pas un programme valide.

A ce moment là, le simple fait d'utiliser int rend ton programme invalide, car sa taille change selon le CPU.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Sauf que la, le comportement dépend du set d'instruction du CPU. Tu dis "tomber sur un modulo" parce que tu as l'habitude de l'instruction add des x86.

C'est un undefined behavior justement parce que l'on peut imaginer créer un compilo pour target un CPU qui fait les choses différemment.

Le C te permet de maîtriser tout les aspects de ton programme, depuis la conception jusqu'à l'exécution.

• Tu veux être portable sur toutes les archis ? Tu évites les undefined behavior.
• Tu sais quel est ton CPU target, et ta toolchain (version/arch du compilo) ? Tu prend connaissance de leur spec, et tu peux utiliser les undefined behavior qui sont spécifiés à un autre niveau

Le undefined behavior n'est pas un bug. C'est une mise en garde au développeur pour lui communiquer qu'il est censé savoir ce qu'il fait.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

il ne se passe pas plus de 3 ou 4 mois sans de nouvelles cve pointant des gestions de mémoires problématiques.

Et c'est une bonne chose, cela veut dire que l'outillage pour les trouver/détecter s'améliore de plus en plus. Intégrer ce mécanisme au processus de release (via de la CI/CD par exemple) se fait de plus en plus, et avec le temps, de moins en moins de CVE seront détectées post-prod.

Quant à la question de l'assembleur elle n'a pas de sens

Si elle a du sens. Les garanties que t'offrent ton langage sont dues à l'implémentation faite par un humain. La traduction Rust -> ASM, ou C -> ASM, ou XXX -> ASM n'est pas automatique. C'est un humain qui l'a implémenté. Si l'implémentation est erronée, tes garanties sont remises en cause.

mais sa sémantique ne permet pas de s'en assurer

Pas au niveau du compilateur certes, mais le bound-checking et le tracking d'allocations, ça fait des décennies qu'on sait le faire à l'aide d'outil d'analyse statique de code. Regarde la suite de test de SQLite si tu veux un bon exemple.

Je ne vois pas comment on peut correctement utiliser un langage sans accepter de voir ses défauts (et ils en ont tous).

Je ne dis pas que le C est un langage parfait, il a des défauts. Mais la gestion de la mémoire manuelle n'en n'est pas un, c'est une feature.

Je peux me casser un doigt avec un marteau, je dois abandonner l'idée de planter des clous ou j'apprend à m'en servir correctement ?

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

ok, super, t'as trouvé des softs écrits en C.
Je peux te sortir swiftc ou clang ou hotspot, tous écrits en C++, ca fera pas avancer le chimilimili.

Tu dis initialement que le C n'est plus utilisé que pour les kernel/drivers et l'embarqué. Je te cite des exemples pour contredire ta mésinformation. Si la vérité t'offense, c'est pas grave.

C'est le genre de code qui rentre dans "la montagne de code a porter" dont je parlais.

Pourquoi vouloir réécrire des choses qui fonctionnent bien, qui sont testées intensivement, juste parce que "un nouveau langage hype est apparu" ?

SQLite ne sera jamais réécrit en Rust par exemple. CPython non plus. Lua non plus. If it's not broken, don't fix it.

Une réécriture complète est un travail monstre, fastidieux et long pour arriver au même niveau fonctionnel. Personne dans son bon sens ne s'attèlera à une telle tâche, à part les prosélytes du langage hype X ou Y.

Surtout si il faut le faire tout les 5 ans à chaque fois qu'un nouveau langage sort avec comme argument "le langage XXX c'est le mal, il faut tout migrer vers YYY".

Pour ceux qui ont envie de rire un coup : https://github.com/ansuz/RIIR/issues

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Ce qui est dommage avec le C c'est juste la gestion de la mémoire très difficile et sa propension a permettre les buffer overflow par exemple.

Encore cet argument…

C'est quand même dommage, l'assembleur il y a pas de gestion de mémoire non plus et pourtant 100% des langages compilés (Rust inclut) target ce langage.

Le langage C est un langage bas niveau, il te donne des armes puissantes et un contrôle total, pour que tu puisse optimiser au maximum et à tout les niveaux. Si tu choisis de te tirer une balle dans le pied, libre à toi, il est pas là pour te prendre par la main.

Quand tu fais un logiciel dans le langage hype X, tu utilises des tests unitaires, de l'analyse statique de code, et bien d'autres outils pour t'assurer de la qualité du code. Le C n'a pas attendu 50 ans pour avoir de tels outils dans son écosystème. Dans les années 80 ces outils existaient déjà. Et ils ont très certainement été l'inspiration pour les compilateurs d'aujourd'hui.

Il n'y a pas d'autres raisons à ça que son statut

Bonjour les oeillères.

• Le langage qui est utilisé comme référence en terme de performance et auquel tout les langages se comparent
• Le langage qui te permet de contrôler avec le plus de précision où et quand allouer / libérer de la mémoire (as tu déjà eu des problèmes avec le GIL de Python ou le GC de Go ?)
• Le seul langage qui, un demi siècle plus tard, est encore l'un des plus utilisés dans l'industrie (finance, vidéo, embarqué, OS, …)
• Le langage qui est considéré comme le plus portable qui existe
• Le langage qui peut s'interfacer avec tout les autres langages qui existe

Oui, ce langage ne doit son succès qu'au fait que certaines libs offrent une API C.

Aujourd'hui je n'ai pas l'impression que c'est le langage de prédilection pour ce genre de logiciels.

Non effectivement, aujourd'hui la hype c'est TypeScript + React + Electron, et ainsi tu ouvres un chrome par application (cc Slack, Teams, Atom, VS Code, Lens, Spotify, …). Quel progrès, j'ai 24Go de RAM, 85% utilisés.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

SQLite n'est ni un kernel, ni un driver, ni de l'embarqué, ni un hardware digne des années 80, et il a même pas la moitié de l'âge du langage C (22 ans).

https://sqlite.org/whyc.html

CPython par exemple, c'est pas un kernel, pas un driver, pas de l'embarqué, etc… Il existe PyPy pourtant, après tout Python n'est qu'une spec.

Ou alors Lua.

Ou alors tout le domaine de la finance qui a besoin de performance à la nanoseconde près.

Le C à quand même perdu énormément d’attrait ces 30 dernières années.

C'est effectivement l'observation qu'on peut faire si on détourne le regard sur ce qu'apporte le C depuis maintenant 50 ans.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

50 ans.

50 ans que chaque année un nouveau langage apparaît pour l'enterrer.
50 ans qu'il survit. Nay, que dis-je, 50 ans qu'il est en vie!

Un demi siècle, et toujours aucun signe de la retraite.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

J'ai eu comme un mauvais souvenir qui a refait surface sans crier gare en lisant le titre.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Dans mon cas, Windows 11 avec VS Code.

Parmi les toolchains que j'ai :

• Elixir 1.13 / OTP 24
• Python 3.10 avec poetry
• NodeJS (via NVM pour supporter plusieurs versions) avec Yarn
• Rust (via rustup)
• CLang et CMake
• Go 1.17

Je travaille intensément avec Docker et Kubernetes (KinD en local, DigitalOcean pour la (pre)prod).

Cela va faire 5-6 ans que je n'ai plus de Linux installé en natif autre part que sur des serveurs. Ca a commencé par un ordinateur fournit par un employeur qui était sous Windows 10. J'utilisais pas mal le Windows Subsystem Linux, au début. Maintenant je ne l'utilise que rarement.

L'OS de Microsoft a beaucoup évolué et me permet d'avoir un environnement de dev efficace. Et cela m'a permit de beaucoup progresser question portabilité.

J'ai fini par tomber amoureux par le manque de choix. Au lieu de passer mon temps à tout configurer au poil, ou a tester 30 000 alternatives, je prend ce qui est fournit et je me focus sur mon travail.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

De mémoire, tu peux pas avoir ton RootFS qui utilise fuse.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

De toute façon, y a plus de petit fichiers, c'est fini (joke)

Toi tu connais pas NPM (joke aussi)

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Les pluriels des mots n'apparaissent jamais dans un dictionnaire. Étant donné que c'est ma source, normal que cela ne soit pas pris en compte.

Faire une liste complète prendrait beaucoup de temps je pense.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Les pluriels sont des déclinaisons d'un mot. Il est donc "normal" de ne pas le trouver dans un dictionnaire. Le mot c'est "tear".

Ce que je retiens de la plupart des retours que j'ai eu, c'est que pour rendre le jeu agréable il faut passer plus que 30 secondes sur la conception de la liste.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Certes Nomad est un excellent outil. Mais le comparer à Kubernetes n'est pas très correct.

Nomad est un outil d'orchestration de conteneur et de VM. Kubernetes est bien plus que ça. Kubernetes offre des fonctionnalités comme la gestion du traffic (Service, Ingress, NetworkPolicy, …), la gestion des secrets et de la configuration (ConfigMap, Secret), la gestion du stockage (PeristentVolume, PersistentVolumeClaim, …). Il permet de gérer précisément le scheduling, le monitoring (liveness/readiness probes), le service discovery, etc…

Les opérateurs Kubernetes qui existent permettent également d'augmenter les capacités de son API, on va avoir ainsi du Cert-Manager, du Tekton, du KubeDB, du ArgoCD, etc…

Kubernetes offre aussi la gestion de cluster (drainage des nodes, ajout de worker node depuis un peu partout, etc…),

Si on veut atteindre le même niveau de fonctionnalité avec les outils de Hashicorp, il va falloir mettre en place Nomad, Vault, Consul, Terraform, etc… Tout de suite, la complexité de l'infrastructure atteint celle d'une distribution Kubernetes.

Bref, Nomad c'est bien mais non ce n'est pas la même chose que Kubernetes : https://www.nomadproject.io/docs/nomad-vs-kubernetes

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

~2500 mots de 5 lettres dans ma liste vs 12478 mots au scrabble anglais. Oui il m'en manque beaucoup.

J'ai pas cherché plus de 2min :

• google: english dictionary json
• premier lien pertinent, clic, download
• python + filtering

Bim.

Si tu trouves une liste plus complète, libre à toi de faire une PR :)

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

dans quels cas std::function ne fera-t-elle pas d'allocation dynamique ? Est-ce garanti ?

Quand elle est initialisée à partir d'un pointeur de fonction, et oui c'est garanti.

Pour les lambdas, je suis pas sûr.

proposer une implémentation qui ne fait jamais d'allocations dynamiques

A partir du moment ou je veux pouvoir "defer" des fonctions, lambdas, des méthodes d'objet, et pouvoir jouer avec std::bind. Je pense pas que cela soit possible.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Un autre exemple qui vaut le coup d'oeil :

class texture_manager {
  private:
    new_defer_frame();
    SDL_Renderer *m_renderer;

  public:
    texture_manager(SDL_Renderer *renderer) : m_renderer(renderer) {}

    SDL_Texture *load(const char *asset_path) {
      defer_frame __; // pour pas shadow celle définie au niveau de la classe

      auto surface = IMG_Load(asset_path);
      if (surface == nullptr) {
        throw std::runtime_error(IMG_GetError());
      }
      __.defer([&]() { SDL_FreeSurface(surface); });

      auto texture = SDL_CreateTextureFromSurface(m_renderer, surface);
      if (texture == nullptr) {
        throw std::runtime_error(SDL_GetError());
      }
      defer({ SDL_DestroyTexture(texture); });

      return texture;
    }
};

Dans cet exemple, j'ai 2 frames, une au niveau de la classe qui sera appelée par le destructeur, m'évitant ainsi de devoir maintenir une liste des textures créées. Et une au niveau de la fonction pour détruire la surface qui n'est que temporaire.

Dans ma fonction run_sdl_program(), j'ai plus qu'à faire un new et "defer" le delete de mon texture_manager.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

il me semble que l'ordre de libération est inverse

C'est le cas, j'ai utilisé rbegin et rend, qui itère sur le std::vector depuis la fin vers le début.

En go, j'imagine que ça :

En Go defer exécute du code à la fin de la fonction, pas à la fin du scope, donc ton defer à l'intérieur du if ne sera pas exécuté au bon moment.

Donc ma version C++ permet une gestion plus fine. Le fait de déclarer une seconde frame dans le if (qui repose sur le variable shadowing) va justement te permettre d'avoir le comportement souhaité.

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg

Et donc tu appelles quand le SDL_DestroyRenderer/Window et SQL_Quit ?

Si tu me dis que tu les appelles pas et que tu quittes tout simplement le programme sans t'en préoccuper, je te répondrais :

Et tu fais quoi si tu as plusieurs fenêtres (cf ceci) ?

https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg