7380

Lionel Debroux (./7379) :
En tout cas, mauvais point pour le langage d'implémentation: fournir une API externe en C reste bien sûr nécessaire pour des raisons d'interopérabilité, mais pour de nouvelles bases de code, continuer à tout écrire en C est de plus en plus inacceptable.
Pour moi, l'utilisation du C est un argument en faveur. Les alternatives n'ont pas la même efficacité en taille et en vitesse.

C'est triste que pour Linux, le mode principal d'introduction de sandboxing soit une approche de type containerisation avec un packaging à un format comme Docker, Snap ou Flatpak, autrement dit un gros paquet de nouilles, plutôt qu'une inclusion dans le code des programmes cibles.
En effet, j'ai horreur des conteneurs où il faut embarquer des copies de tout (bundling) et SELinux n'est pas non plus une solution (une base de données centrale qui contient les informations sur les permissions nécessaires pour tous les programmes, ce n'est absolument pas scalable), seccomp est clairement la bonne approche, mais a en effet besoin d'améliorations (notamment, il faudrait une manière raisonnable pour que les bibliothèques (libraries) puissent déclarer les permissions dont elles ont besoin, parce que le programme principal ne peut souvent pas deviner – la meilleure solution serait probablement une annotation dans une section ELF spéciale (comme pour l'annotation GNU_STACK) lue au chargement et immutable pendant toute l'exécution, pour garantir que du code exploit ne puisse modifier les permissions plus tard).
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

7381

Le minimum serait d'intégrer du C++ moderne dans l'implémentation pour bénéficier du meilleur typage, de la const correctness et de quelques facilités supplémentaires pour réduire la fréquence d'occurrence des problèmes de sécurité évitables et pour améliorer l'efficacité. Ils peuvent même tirer parti de C++17, puisqu'ils visent des plate-formes futures. Mais plus que Go, même s'il est très productif, je pensais à Rust, plus difficile d'accès mais vrai langage système qui interopère directement avec C, parce que non seulement il peut être très efficace (eux aussi vont assez loin sur les abstractions à coût nul), mais surtout, il a été fait pour être beaucoup plus sûr que C. Rust tient en général ses promesses de sécurité, même si j'ai vu passer que plusieurs bugs dangereux ont été trouvés dans la lib standard ces derniers temps, et vite corrigés après avoir été reportés. Les développeurs de Rust ont été critiqués par certains pour ne pas avoir utilisé de modèle formel de la lib standard, mais bien sûr, les autres langages mainstream ne font pas mieux.

Continuer à intégrer aux distros Linux de nouveaux composants de base écrits dans un langage dangereux, qui vont donc s'avérer à court et long terme contenir de grosses vulnérabilités évitables, ne va pas du tout dans le bon sens. Du C bourré de vulnérabilités, en particulier des débordements de zones mémoire, il y en a déjà bien trop dans les (dépendances directes de) packages essentiels de presque toutes les distros Linux. Les fuzzers le montrent régulièrement.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

7382

Le minimum serait d'intégrer du C++ moderne dans l'implémentation pour bénéficier du meilleur typage, de la const correctness et de quelques facilités supplémentaires pour réduire la fréquence d'occurrence des problèmes de sécurité évitables et pour améliorer l'efficacité.

Je ... non.

Le C++ est 1000x plus permissif que le C est fini; dans des mains "non experte" par faire une bouillie non maintenable.

Je préfère 100000x du C mal foutut que du C++. Haaa les joies de lire du code ou tu as besoin de lire et trouver les centaines de constructeurs d'objet implicites et essayer de comprendre pourquoi declarer cette variable, et pas celle la, rajoute 6s au tempe d'execution d'un outil qui devrait en tout et pour tout prendre 100ms
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

7383

Oh, bien sûr qu'on peut faire un bazar à la fois incompréhensible (bien pire que du C) et horriblement mauvais des points de vue performance et sécurité, quand on écrit du mauvais C++ smile
Mais utilisé à bon escient, un minimum de C++ peut améliorer à la fois la maintenabilité et l'efficacité. Je n'ai pas le temps de chercher le lien maintenant, mais je me souviens notamment avoir lu que quand les premiers morceaux de C++ ont été intégrés à GCC, non seulement le résultat était plus compréhensible et serait plus facile à faire évoluer, mais aussi, l'exécution était plus rapide de façon mesurable (1-2% ) parce qu'une partie des vérifications de type de données précédemment faites au runtime, à cause du typage plus faible de C, avaient été éliminées des binaires produits.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

7384

pencil et puis les implementations des compilos ont encore pas mal de bugs au niveau de C++17 (pour rappel mon bug d'optimizer il y a quelques mois) - aucun probleme avec C++14 par contre

./7382 Pour ton spoiler, si c'est le cas, c'est vraiment que ton code est mal foutu (ou qu'il a ete ecrit par poettering grin)

7385

(c'est un pléonasme, ça cheeky)
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

7386

Euh oui, le fait de dire "on peut faire de la merde avec tel langage" est quand même léger, sachant qu'on peut en faire avec n'importe quel langage. Du C bourré de macros à n niveaux, ça peut très bien devenir imbitable par exemple.

7387

On peut faire n’importe quoi avec n’importe quel langage, mais c’est plus facile avec certains langages. embarrassed
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

7388

Tiens d'ailleurs, je me demande si Linus Torvalds a toujours la même opinion du C++ ? Il y a une dizaine d'années, il écrivait ça :
http://harmful.cat-v.org/software/c++/linus
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

7389

Dans le contexte d’un kernel, je comprends son opinion. Maintenant, j’al souvent lu qu’on peut faire du C++ propre en utilisant qu’un subset du langage.

7390

Oui, beaucoup de gens sont à peu près d'accord là-dessus ; le souci, c'est que personne n'est d'accord sur quoi mettre dans le subset.
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

7391

D’où l’intérêt des nouveaux langages comme le Rust embarrassed
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

7392

pencil mais ca aussi c'est pareil pour tous les languages. rien ne t'oblige a inclure <algorithm> par exemple. Tu t'exposes juste a une tetrachiee de RTII dans ton binaire, mais c'est a peu pres tout en fait (en plus de pas necessairement connaitre tout l'implementation detail des algo, vu que ca devient compilo-specifique). pour boost, au contraire c'est open source, par contre lire le code est une veritable purge, on va pas se mentir (et pour l'argument de la portabilite de boost c'est juste que t'es oblige de lier statiquement a cause du mangling - a moins de compiler soi-meme -, sinon y a un bon paquet de boost qui st header-only)

O2: Je dirais que c'est selon les besoins. Mais la encore on revient sur l'argument C contre C++.

flan: ou asm.js? trifus

7393

Pas de gros mots embarrassed
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

7394

Rust c'est pas un gros mot, par contre Objective-C... grin

la seule "API" que je deconseille a n'importe qui qui fait du C++ c'est <iostream>. c'est juste de la grosse merde tant niveau perf que comportement attendu.

7395

Niveau sécurité, ça dépend vraiment de comment est écrit le C++. Si on vire complètement les tableaux et l'arithmétique de pointeurs et utilise seulement les types Qt comme QString et QList, ou à la limite la STL (mais elle propose plus de moyens de se tirer une balle dans le pied que Qt), les débordements de buffer disparaissent normalement complètement, mais bien sûr on perd aussi en efficacité (surtout si on active la vérification contre les débordements en lecture – Qt active par défaut des assertions qui vérifient ça et terminent le programme en cas de débordement).
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

7396

Ben pareil sans qt en fait, t'as des bounds check dans les conteneurs de la STL

7397

edit: cross-post
avatar

7398

c++ tu changes de version de gcc et toutes tes libs dynamiques deviennent inutilisables...

C forever. bien écrit c'est pas plus dangereux qu'autre chose.

7399

Lionel Debroux (./7379) :
En tout cas, mauvais point pour le langage d'implémentation: fournir une API externe en C reste bien sûr nécessaire pour des raisons d'interopérabilité, mais pour de nouvelles bases de code, continuer à tout écrire en C est de plus en plus inacceptable.
Le C grade quand même un avantage sur tous les autre langages: c'est qu'il y a des compilateurs C pour quasiment toutes les architectures existantes. Et comme Linux est en C, PipeWire est potentiellement portable partout ou est Linux.

Kevin Kofler (./7380) :
Pour moi, l'utilisation du C est un argument en faveur. Les alternatives n'ont pas la même efficacité en taille et en vitesse.
Non, il existe des alternatives compétitives sur ces points.
Le Rust par exemple est spécialement conçu pour permettre des performances similaires au C tout en garantissant un niveau de sécurité bien supérieur.
Le C++ peut avoir des performance équivalentes au C en taille et vitesse. Il a des fonction qui permettent une meilleure sécurité, mais ça demande quand même d'en faire bon usage, là où le Rust refuse de compiler tout ce qui peut aboutir à des UB (à moins d'utiliser un bloc "unsafe").

Folco (./7386) :
Euh oui, le fait de dire "on peut faire de la merde avec tel langage" est quand même léger, sachant qu'on peut en faire avec n'importe quel langage. Du C bourré de macros à n niveaux, ça peut très bien devenir imbitable par exemple.
En effet, mais le langage a son importance car il est clairement plus facile de faire involontairement du code dangereux avec certains qu'avec d'autres. On peut toujours se dire : "avec du bon code et des bons programmeurs, ça n'arrive pas", mais l'expérience prouve tous les jours que si, ça arrive.

Folco (./7389) :
Maintenant, j’al souvent lu qu’on peut faire du C++ propre en utilisant qu’un subset du langage.
En effet, Bjarne Stroustrup (le créateur du langage) travaille a définir un sous ensemble standard plus dont le bon usage pourrait être vérifié par les compilateurs. Mais c'est encore un travail en cours. A priori, ça limiterais pas mal les risques mais ne sera pas du niveau de ce que garantit Rust.

Warpten (./7396) :
Ben pareil sans qt en fait, t'as des bounds check dans les conteneurs de la STL
En effet, dans la STL, il y a deux syntaxes, avec et sans bound check. Mais ils ont eu la bonne idée de ne pas mettre de bound check sur la syntaxe la plus simple. sad

squalyl (./7398) :
c++ tu changes de version de gcc et toutes tes libs dynamiques deviennent inutilisables...
Dans le cas de PipeWire, ça ne serait pas un problème. Vu qu'il va falloir que la bibliothèque s'interface avec d'autre langages, Rust ou C++ utiliseraient l'ABI C de toute façon .

squalyl (./7398) :
C forever. bien écrit c'est pas plus dangereux qu'autre chose.
Si c'est bien fait, marcher en équilibre sur un fil à 10 mètres de haut sans protection n'est pas plus dangereux qu'autre chose non plus.

Sauf que c'est difficile de garantir le "si c'est bien fait", surtout quand il y a un facteur humain. Dans pratique, on sait que sur des bases de codes conséquentes, même avec des normes et des processus de relecture, on laisse toujours passer des erreurs. Donc si le compilateur peut de base empêcher toute une classe de problèmes, c'est toujours bon a prendre.
avatar

7400

De toute façon si tu fais une librairie dynamique c'est attendu que tes méthodes front facing soient en extern C

7401

Ça dépend quand-même de ce que tu veux proposer comme bibliothèque. Ce ne serait pas possible pour une bibliothèque de classes comme Qt.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

7402

Uther (./7399):
Lionel Debroux (./7379) :
En tout cas, mauvais point pour le langage d'implémentation: fournir une API externe en C reste bien sûr nécessaire pour des raisons d'interopérabilité, mais pour de nouvelles bases de code, continuer à tout écrire en C est de plus en plus inacceptable.
Le C garde quand même un avantage sur tous les autre langages: c'est qu'il y a des compilateurs C pour quasiment toutes les architectures existantes. Et comme Linux est en C, PipeWire est potentiellement portable partout ou est Linux.
Certes, il y a des ISA qui n'ont pas de bon compilo C et encore moins de compilo C++ acceptable, par exemple Z80 et eZ80: non seulement l'ISA, même améliorée, se prête mal à la programmation en C, mais de plus, le compilo de Zilog est une vraie bouse.
Cependant, Linux a des dépendances dures vers des extensions GCC au langage C, donc GCC ou quelque chose de suffisamment compatible (Clang sur certaines architectures, même si mainline Linux met des bâtons dans les roues en rendant inconditionnelles les dépendances vers des extensions GCC non universellement appréciées sur des architectures aussi majeures que x86/x86_64...) est un prérequis pour toutes les plate-formes où Linux s'exécute. Il ne me semble alors pas y avoir de (bonne) raison pour que PipeWire soit moins portable avec une implémentation interne en C++ et une API externe en C qu'avec une implémentation interne en C et une API externe en C.
Si une mini-libc et libstdc++ n'ont pas été portées sur certaines des plate-formes qui peuvent tourner Linux, c'est un gros problème d'utilisabilité desdites plate-formes, car le C++ se répand (beaucoup trop) lentement dans les deps core d'un système Linux bien élevé. Et je pense que certaines (la plupart ?) de ces éventuelles plate-formes bizarres ne seraient pas les cibles des utilisations clairement desktop et DAW visées par PipeWire.

Uther (./7399):
squalyl (./7398) :
c++ tu changes de version de gcc et toutes tes libs dynamiques deviennent inutilisables...
Dans le cas de PipeWire, ça ne serait pas un problème. Vu qu'il va falloir que la bibliothèque s'interface avec d'autre langages, Rust ou C++ utiliseraient l'ABI C de toute façon.
De plus, recompiler + upgrader le système cible + redéployer doit maintenant être une fonctionnalité de base sur la plupart des devices, y compris de l'embarqué assez dur, puisque justement, à cause de la sur-utilisation de C et C++ mal écrits qui donnent du code trop vulnérable, les mises à jour de sécurité doivent être réalisées fréquemment...
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

7403

Lionel Debroux (./7402) :
Certes, il y a des ISA qui n'ont pas de bon compilo C et encore moins de compilo C++ acceptable, par exemple Z80 et eZ80: non seulement l'ISA, même améliorée, se prête mal à la programmation en C, mais de plus, le compilo de Zilog est une vraie bouse.
Ouais enfin, on s'éloigne du sujet, non ? Parce que je pense que PipeWire sur un Z80, c'est un peu overkill grin
avatar

7404

7405

./7402 > Ok je connaissais pas tous ces détail sur Linux, ça remet le C++ en course en effet. Par contre d'autre langage ont quand même plus de mal. Rust est actuellement limité aux architecture supportées par LLVM.
Et puis je ne connais pas assez PipeWire pour voir si ça a un intérêt. Mais pour pas mal de logiciel ça peux quand même être intéressant de savoir que l'on est portable vers des systèmes qui ne requièrent pas GCC.
avatar

7406

Oui enfin en dehors de x86(_64) et peut etre ARM, "PipeWire" n'a aucun interet...
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

7407

Tiens j'ai essayé Manjaro aujourd'hui parce qu'il me fallait une distro et qu'un collègue utilise. Je suis vraiment impressionné par leur charte graphique. Sincèrement je préfère probablement au dernier macOS je pense, c'est dire. Bon après à titre personnel je ne suis pas fan des UI sombres, mais au moins là c'est bien fait.

F3hy
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

7408

Ouais, elle est bien classe, j'aime aussi beaucoup, c'est celle que j'installe quand flemme de paramétrer Arch. En plus, elle tourne plutôt bien sur des machines un peu ancienne.
avatar

7409

avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

7410

Ce n'est que partiellement une bonne nouvelle... je trouve la syntaxe de qmake, que j'utilise depuis des années au boulot, nettement plus agréable que celle de CMake, pour lequel j'ai très récemment eu à modifier des CMakeLists.
Maintenant, j'ai à peu près fini par retenir les vilains "CMAKE_C_COMPILER" et "CMAKE_CXX_COMPILER", certes plus descriptifs, mais tellement moins intuitifs que CC et CXX (QMAKE_CC et QMAKE_CXX, dans le cas de qmake) utilisés par les autres.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.