- Une conception saine : en application directe de la philosophie UNIX, ashd est découpé en plusieurs programmes qui font une seule chose, mais le font bien
- La sécurité : comme chaque processus ne fait qu'une seule chose, il est facile de restreindre ses droits au minimum dont il a vraiment besoin
- Une configuration simple et sensée : chaque programme ayant une responsabilité limitée, il est facile de le configurer (les options en ligne de commande suffisent généralement)
- La persistance : les processus sont persistants et peuvent ainsi garder des données de session en mémoire ou conserver des connexions vers des backends.
Ashd est composé des modules suivants :
- htparser, pour écouter les connexions TCP et parler en HTTP avec les clients
- dirplex, pour servir des fichiers depuis un répertoire (la réponse est déléguée à sendfile)
- patplex, pour les règles de gestion virtuelle
- sendfile, pour répondre aux clients avec un fichier et gérer les entêtes HTTP associés (content-type, last-modified, etc.)
- callcgi, pour appeler des scripts CGI
- userplex, pour servir les répertoires des utilisateurs à la /~user/ (ce programme est lancé avec l'utilisateur en question, ce qui évite les problèmes que l'on peut avoir avec apache qui tourne en www-data)...
Aller plus loin
- Ashd (27 clics)
# Principe intéressant
Posté par Ork . Évalué à 10.
Mais est-ce aussi performant qu'un serveur HTTP "monolithique" classique ? Du moins, quand le projet sera plus avancé ?
En tout cas, je vais suivre le projet de près, merci pour la découverte !
[^] # Re: Principe intéressant
Posté par mister popo ポポ (site web personnel) . Évalué à 6.
Vouloir scaler un serveur http est une mauvaise idée.
Pour du dynamique, il suffit d'avoir un serveur en front, et des workers derrière en fastcgi ou même en http.
Franchement, si on veut un truc plus hype que lighty/nginx/cherokee, mongrel2 est bien plus interessant que ce soft de vieux con.
Pour moi, le coup des 30 petits logiciels pour faire tourner une appli, ça fait penser à toute la stack qu'il faut pour faire tourner un serveur mail. Avoir des besoins différents à part (l'imap, l'antivirus) me semble sain. Mais tout le merdier disparate pour l'antispam me semble bien reloud.
[^] # Re: Principe intéressant
Posté par ZeroHeure . Évalué à 4.
Est-ce que tu glisses de l'anglais pour dissaïdor dans ton message, ou est-ce que tu y mets du français branchouille pour compliquer les choses? Non, vraiment je ne sais pas. Si le français t'embete, vire-le carrément.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Principe intéressant
Posté par Fabimaru (site web personnel) . Évalué à 4.
[^] # Re: Principe intéressant
Posté par cstar . Évalué à 4.
# Quelle soudaine productivité !
Posté par Philip Marlowe . Évalué à -10.
[^] # Pas si innocent
Posté par luditie . Évalué à 3.
[^] # Re: Pas si innocent
Posté par Gesmas . Évalué à -7.
Suite à la polémique sur le site Linuxfr.org à propos des compétences ou des incompétences supposées de Christophe Casalegno, je me suis intéressé à cette personne. J'ai lu le « qui-suis-je » disponible sur son site internet ([http://www.christophe-casalegno.com/qui-suis-je/]) et j'ai simplement cherché à en savoir un peu plus sur ces activités. J'ai donc fait des recherches à partir de Google sur les noms des organisations et sur les personnes mentionnées. Cette méthode n'est pas parfaite, mais elle se révèle souvent extrêmement pertinente.
Pour résumer mes résultats dont vous trouverez le détail ci-dessous, Christophe Casalegno utilise plusieurs moyens pour se valoriser; notamment l'autoréférencement (il se prévaut d'organisation au titre ronflant qu'il a lui-même créées ou qui sont celles de proches) ou l'imprécision (références floues, invérifiables). Bien entendu, il est normal de se présenter sous un jour positif dans une biographie. Néanmoins, il s'agit ici d'une véritable duperie, car il existe une différence gigantesque entre ce que le texte laisse supposer et la réalité
Pour le détail, je recopie le texte et le commente:
« Fondateur et CTO (Chief Technnical Officer) du groupe DNG (Digital Network Group) mes fonctions consistent à prendre les décisions stratégiques pour tout ce qui touche aux aspects techniques, opérationnels, recherche et développement, des différentes sociétés et activités du groupe et à les faire appliquer. J’ai également à ma charge, la gestion de l’image du groupe, ainsi que des relations publiques avec les actionnaires, les institutions et la presse. »
Ce qui est présenté ici est des plus normal. Un responsable prend en charge un certains nombres de décisions stratégiques. Les expliciter donne un caractère exceptionnel à la fonction. Bien entendu , on peut être épater par le nombres de tâches sous la responsabilité de Christophe Casalegno. Ce cumule de responsabilités signifie surtout que l'entreprise est toute petite. Remarquons le cocasse « relations publiques avec les actionnaires ».
« Membre de la NMIA (National Military Intelligence Association), je participe et j’interviens également directement au sein de nombreuses missions opérationnelles ou de terrain, comme : formations et conférences, sécurité appliquée aux nouvelles technologies, management de la perception et de l’information, communication de crise, recherche de fuite d’information, cybertraque et cyberdéfense, intelligence économique, presse et infoguerre. »
Aucune trace de Christophe Casalegno chez NMIA, aucune trace d'une conférence ou d'un formation donnée par Casalegno dans le cadre du NMIA. De plus le NMIA ne semble pas avoir de « mission opérationnelle ou de terrain ». Autrement dit, les termes sont inappropriés voire mensongers.
« Conseiller pour différents médias et organisations, je suis directeur de recherches auprès du Centre International de Recherches et d'Etudes sur le Terrorisme fondé par Yves Bonnet, ancien directeur de la DST. Ancien membre du KESAC (Kaspserky European Scientific Antivirus Center), j’ai notamment été chargé de mission "Infoguerre et Protection" auprès de la CJDSI. »
Quels médias ? La formulation implique une certaine durée et bizarrement on a aucune information sur les médias. Pour les organisations, c'est pour le moyen douteux cf ci-dessous.
Le Centre International de Recherches et d'Etudes sur le Terrorisme est contrairement à ce que son nom laisse entendre une toute petite organisation. Aucune mention de Christophe Casalegno, d'ailleurs l'association ne semble pas publié quoique ce soit. Un comble pour un centre international de recherche. Le centre ne semble pas avoir d'activité, il est visiblement un moyen pour Yves Bonnet de se prévaloir d'une association au titre ronflant. Remarquons dans les membres fondateurs la présence de Jean-Paul Ney, un proche de Christophe Casalegno.
Le KESAC doit avoir disparu parce qu'il n'en existe aucune trace sur internet. Sauf, la prose de Christophe Casalegno et quelques références éparses d'interview de son directeur en 2004 et 2006.
Pour le CJDSI, on retrouve l'ami Jean-Paul Ney. Le site n'a plus d'activité depuis 2008. On est donc dans le copinage et l'autoréférencement. Facile de s'auto-proclamé chargé de mission "infoguerre et protection".
« Je suis également membre fondateur de l’Institut International de la Coordination et de la Réponse aux Attaques Informatiques et membre d’honneur de l'IIHEC (Institut International des Hautes Etudes de la Cybercriminalité) : fondé par Daniel Martin, créateur et responsable du système d’information de la DST, responsable de la sécurité à l’OCDE, rapporteur à la cour des comptes, et intervenant dans le cadre des réunions du G8. »
L’Institut International de la Coordination et de la Réponse aux Attaques Informatiques est un autoréférencement avec l'ami Jean-Paul Ney qui se prévaut également d'être chercheur associé. Aucune référence des travaux de cet institut, aucun caractère international, aucune activité, pas de site web... rien. Il n'existe que dans les CV de la famille Casalegno et Ney.
Dans l' Institut International des Hautes Etudes de la Cybercriminalité, on retrouve l'ami Jean-Paul Ney et l'institut est partenaire de Digital-Network. Toute petite organisation. Dernière activité recensée en 2004. Aucune référence sur internet à part leur site et les CV de... Jean-Paul Ney et Christophe Casalegno. Personne d'autre ne semble collaborer ou être membre de cette organisation. Remarquons que membre d'honneur ne signifie rien en soi. Par contre, on se prévaut du passé « prestigieux » du fondateur (qui n'est peut-être plus dans l'organisation...).
« Enfin, je suis enseignant auprès de l'ISMP (Institut Supérieur Management Projet) dans la filière Chef de Projet BAC + 5 Transverse en Sécurité des Systèmes d’Informations, principalement dans les domaines de la sécurité informatique (techniques intrusives, social Engineering) et de la guerre de l’information (guerre électronique, intelligence économique, perception management). »
Aucune référence à Christophe Casalegno sur le site de l'institut ou de son nom associé à cet institut. [http://www.ismp.fr/commun/les-enseignants-2.html].
Je suis connu depuis plus de 20 ans sous le pseudonyme de Brain 0verride, depuis plus de 12 ans sous le nom de "Chris”, en tant qu’auteur et interprète.
Cela n'apporte rien sauf une pseudo-crédibilité de hacker difficile à démontrer, se donner un surnom ronflant est de nouveau de l'ordre de l'autoréférencement. Notons que Christophe Casalegno est agé de 34 ans, qu'il y a prétendu dans un message sur LinuxFr s'appelé ainsi depuis 27 ans !! Un an avant d'avoir reçu son premier ordinateur. Bien entendu "Chris" n'a jamais publié un disque, il écrit quatre chansons écoutables sur son site, mais vend ses talents pour faire carrière. Les références d'artiste avec lesquels il travail sont totalement inconnus (pour rester gentil).
« Quelques médias dans ou pour lesquels je suis intervenu : « Le Confidentiel », « Le livre noir du terrorisme » (préfacé par Yves Bonnet ancien directeur de la DST), « Souriez on vous espionne » Editions du pic du midi, « IT-Expert numéro 53 janvier/février 2005 », « Canal plus », « Kappa », « Itélé », « Le Figaro », « Mag Securs », « Distributique », « RTL », « Décision informatique », « StuffMag », « Emarrakech », « Le Nouvel Observateur », « BFMTV »… »
Le syndrome « Vu à la télé ». Aucune précision, sauf son ami Yves Bonnet déjà cité par ailleurs. On ne connais, ni le cadre, ni le type d'intervention et encore moins la qualité de celles-ci.
«Quelques références : Ministère de la défense, Ministère des finances, Warner Bros Pictures, Hewlett Packard, Expertel, GIE ARGOS, FT R&D, CCPB/CIBTP, Experteam-IT, TDF, CMA-CGM, SNEDA, CIS, Monster, Inovalis…»
Invérifiable, mais tout le monde peut se tromper... il s'agirait de savoir de nouveau la qualité et la durée de l'intervention.
Après cette lecture critique de cette présentation de Christophe Casalegno, on ne peut qu'être aboussourdi par le manque de référence crédible ou même existant. Ce n'est qu'une collection de titres ronflants, d'organisation au nom prestigieux.. et puis rien, que des coquilles vides.
Il y a clairement tromperie ! L'impression que veut donner Christophe Casalegno est très éloignée de la réalité.
Bien entendu, je ne ferai aucun commentaire sur sa santé mentale, mais il est plus que justifier de remettre en doute la véracité de ses compétences tant ce qu'il présente est trompeur.
[^] # Re: Pas si innocent
Posté par Lotso . Évalué à 5.
[^] # Re: Pas si innocent
Posté par grid . Évalué à 7.
La dacabale (qui n'existe pas) va durer longtemps ?
[^] # Re: Pas si innocent
Posté par Guillaume Denry (site web personnel) . Évalué à 9.
[^] # Re: Pas si innocent
Posté par LaBienPensanceMaTuer . Évalué à 9.
Franchement, que t'a t il fait ce Christophe ?
C'est ni le premier ni le dernier à se faire mousser et on peut limite lui trouver l'excuse de sa boite: bein ouai, faut qu'il fasse décoller son truc comme il peut, et s'est pas en écrivant "je suis une tourte mythomane" qu'il va trouver des clients.
Au lieu de gaspiller ton temps à faire une cabale (tout seul) contre ce monsieur, audite donc du code libre, patche, fait quelque chose de productif.
Avec ce commentaire (dans les 10 premiers concernant un sujet qui n'a rien à voir) tu prouves une nouvelle fois que tu t'enfonces dans une gaminerie digne de la cour du collège.
STOP
Fous lui la paix et fous nous la paix par la même occasion.
[^] # Re: Quelle soudaine productivité !
Posté par rewind (Mastodon) . Évalué à 1.
[^] # Re: Quelle soudaine productivité !
Posté par Christophe Casalegno . Évalué à 10.
[^] # Re: Quelle soudaine productivité !
Posté par grid . Évalué à 5.
[^] # Re: Quelle soudaine productivité !
Posté par El Titi . Évalué à 10.
S'il prend la mouche et qu'il décide de ne plus participer ca sera évidemment parce qu'il voulait se racheter une conduite, que vous l'aviez prédit et pas parce que ca devient lourd, évidemment.
[^] # Re: Quelle soudaine productivité !
Posté par Philip Marlowe . Évalué à 3.
[^] # Re: Quelle soudaine productivité !
Posté par patrick_g (site web personnel) . Évalué à 9.
C'est un compliment à l'adresse des relecteurs/modérateurs ?
[^] # Re: Quelle soudaine productivité !
Posté par Philip Marlowe . Évalué à -2.
[^] # Re: Quelle soudaine productivité !
Posté par El Titi . Évalué à 1.
Si tu fais allusion à son passé ancien, on ne peut que le féliciter pour ses progrès et j'imagine que c'était ton intention et pas du tout de la dérision.
[^] # Re: Quelle soudaine productivité !
Posté par Philip Marlowe . Évalué à 4.
Et voilà. 'culer un mouton...
[^] # Re: Quelle soudaine productivité !
Posté par Christophe Casalegno . Évalué à 8.
# Micro-noyau et copies mémoires
Posté par Victor STINNER (site web personnel) . Évalué à 9.
Soit les processus sont vraiment cloisonnés et il faut donc recopier les données d'un processus à l'autre. Au moins entre le processus qui génère le corps de la réponse HTTP et htparser qui gère la socket (ou bien htparser transmet la socket à son fils ? c'est possible sous Linux).
Soit les processus partagent de la mémoire. Ce qui revient un peu à utiliser des threads avec de la mémoire partagée. Un bug ou une faille de sécurité affectant un processus va contaminer tous les autres processus. Par contre, on peut éviter certaines copies mémoires. Maintenant quand je lis qu'un programme s'appelle "sendfile", je me demande justement s'il utilise l'appel système sendfile qui permet de copier les données depuis un fichier vers une socket sans aucune copie des données entre l'espace noyau et l'espace utilisateur (noyau (disque dur) => espace utilisateur (tampon), puis espace utilisateur => noyau (socket)).
[^] # Re: Micro-noyau et copies mémoires
Posté par Krunch (site web personnel) . Évalué à 6.
> doivent être copiées d'un processus à l'autre
Pour faire passer des données d'un processus à l'autre, il n'y a pas forcément besoin de les copier puisque le kernel peut mapper la même page dans les deux processus. Le problème c'est plutôt le coût du passage userland/kernel puisque tout est en userland et qu'il faut forcément passer par le kernel pour passer d'un processus/thread/serveur userland à l'autre.
> Soit les processus partagent de la mémoire. Ce qui revient un peu à utiliser des threads
> avec de la mémoire partagée. Un bug ou une faille de sécurité affectant un processus
> va contaminer tous les autres processus.
Si la mémoire n'est qu'en lecture seule pour tous les processus sauf un, non.
En pratique je suppute que ashd est passablement pourri au niveau des performances mais en théorie il devrait y avoir moyen d'en faire quelque chose d'assez correct je pense.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Micro-noyau et copies mémoires
Posté par Victor STINNER (site web personnel) . Évalué à 6.
[^] # Re: Micro-noyau et copies mémoires
Posté par Antoine . Évalué à 4.
[^] # Re: Micro-noyau et copies mémoires
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Micro-noyau et copies mémoires
Posté par Antoine . Évalué à 3.
[^] # Re: Micro-noyau et copies mémoires
Posté par geb . Évalué à 2.
[^] # Re: Micro-noyau et copies mémoires
Posté par Jux (site web personnel) . Évalué à 7.
[^] # Re: Micro-noyau et copies mémoires
Posté par neologix . Évalué à 1.
L'IPC par mémoire partagée ça a été fait sur certains micro-noyaux (par exemple sur QNX).
Mais on ne gagne pas forcément beaucoup par rapport à des envois de message : par exemple L4 se débrouille pour mettre le message dans les registres quand il peut, et provoquer un changement de contexte direct vers le processus à qui le message est envoyé.
Ensuite, avec de la mémoire partagée, il faut quand même un mécanisme de synchronisation pour indiquer l'arrivée des données (alors les messages en eux-même servent de primitive de synchronisation, tu bloques sur le recv/send).
Aussi, je ne vois pas trop comment ça se passe quand tu as 10 processus qui peuvent se parler, et comment le noyau contrôle ce qui est échangé, ça doit devenir le bordel.
Enfin, un problème que je vois, c'est pour les micro-noyaux distribués (par exemple Amoeba), bah là pas de mémoire partagée.
[^] # Re: Micro-noyau et copies mémoires
Posté par Philippe F (site web personnel) . Évalué à 1.
Le Design a l'air simple, c'est un atout, mais ça va pas plus loin. Des gens maîtrisant un peu plus la technique pourraient-ils nous éclairer ?
Parce que côté serveur web, on commence à avoir pas mal de compétition à apache, mais les autres projets que j'avais survolé m'avaient l'air mieux pensés que celui-ci.
# Désolé
Posté par Guillaume Chanaud (site web personnel) . Évalué à 5.
Je ne m'y connais pas des masses en serveurs web, mais j'avais idée de m'amuser un peu avec nginx, qu'est-ce que ce ashd aurait de mieux à vendre (la page web n'est pas très explicite. Ok il y'a plusieurs process qui communiquent entre eux 'over a simple protocol', donc ok on peut faire tourner certains de ces process sous des comptes différents, mais à part ça ? C'est juste un gain de sécurité (j'ai pas dit que c'était négligeable, mais je pense pas que l'architecture des autres serveurs sus-cités soit forcément moins bonne en terme de sécu...) ?
Je veux dire par là que les autres arguments sont un peu marketing (ce qui n'est pas le cas de la page web), je ne crois pas que nginx (oui je reprend celui-là en exemple) soit "mal conçu" ou que sa configuration soit très compliquée. Pour la persistance des process, là je n'en pense rien, à voir les bénéfices/inconvénients que cela peut apporter.
Par contre, comme ça garde la philosophie unix en découpant tout ça en programme sachant chacun faire une chose, le gros avantage doit être de pouvoir réutiliser un/plusieurs composants pour des scripts/projets, c'est ce qui me plait le plus dans le design actuel du bébé...
En tout cas bonne chance à lui pour la suite !
Christophe si tu as suivi un peu le développement du truc peut-être pourrais tu m'éclairer à ce sujet (quel cadre d'utilisation envisager aussi, plutot pour du fastcgi par la suite, plutot pour servir du contenu statique en backend (genre les images/css/js), etc, ? )!
[^] # Re: Désolé
Posté par Christophe Casalegno . Évalué à 1.
[^] # Re: Désolé
Posté par Victor STINNER (site web personnel) . Évalué à 5.
À vrai dire, quand j'ai vu une annonce d'un nouveau serveur web : je pensais à libevent (*) ou aux API asynchrones (non bloquantes). Or quand je lis le code source, je vois des read()/write() bloquants (ou alors j'ai loupé un truc) dans sendfile.c et un select() dans lib/mtio.c. htparser utilise getc() pour parser une requête HTTP : ça ressemble à un premier jet, je pense que les autres serveurs web utilisent des structures plus optimisées pour cette opération.
Ashd 0.1 ne semble donc pas adapté pour supporter de nombreux clients simultanés. Il faudrait tester avec Apache Benchmark (ab) ;-)
(*) http://www.monkey.org/~provos/libevent/
[^] # Re: Désolé
Posté par Jérémie Pierson . Évalué à 2.
Donc je crois que, même s'il n'y a pas de véritable exécution concurrente, les entrées/sorties ne sont pas bloquantes. Par contre, je n'ai jamais testé la montée en charge d'une telle technique. C'est assez proche de la programmation "événementielle" (libevent et compagnie), mais présenté différemment.
Par contre j'ai un peu peur du parser, moi aussi. Enfin, faut que je teste avant de critiquer :-)
[^] # Re: Désolé
Posté par Krunch (site web personnel) . Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Désolé
Posté par M . Évalué à 2.
[^] # Re: Désolé
Posté par galactikboulay . Évalué à 1.
[^] # Re: Désolé
Posté par gato . Évalué à 1.
# J'y crois pas.
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
> * La sécurité
Bon, je ne suis jamais convaincu par "C" et "sécurité" ensemble.
Des langages de haut niveau qui se compilent et qui ont des performances comparables à C, c'est pas ce qui manque. Et ces langages ont au moins le bon goût de ne pas permettre de buffer overflows, le bug de base qu'on trouve dans au moins 100% des logiciels écrits en C.
> (les options en ligne de commande suffisent généralement)
Et sinon, j'espère qu'on ne fait pas
./ash --user=popol --password=s3crEt
Ou plutôt, je l'espère, et je veux un shell sur cette machine, merci. Et mettez bien "ps" dans le PATH, hein !
[^] # Re: J'y crois pas.
Posté par pasBill pasGates . Évalué à 9.
Moi j'attends toujours de voir ca dans le monde reel et pas sur des micro-benchmarks.
[^] # Re: J'y crois pas.
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
[^] # Re: J'y crois pas.
Posté par pasBill pasGates . Évalué à 10.
b) Un script Perl pour une tache un tant soit peu complexe n'a absolument _aucune_ chance de rivaliser avec un soft ecrit en C correctement. Je dis meme pas qu'il a une chance sur 100, c'est 0, meme avec le JIT. Perl en interprete et tres tres lent, le JIT ameliore les choses mais c'est meme pas comparable a Java ou .NET
Ca ne veut pas dire qu'on peut pas faire un soft utilisable avec Perl hein, ca veut dire que si tu mets un dev Perl et un dev C avec le meme niveau et les memes connaissances en optimisation l'un a cote de l'autre, et que tu leur fais ecrire le meme soft, le soft en C sera plus rapide a chaque fois, sans exception. Le seul truc est que le soft en C pourra probablement prendre plus de temps a etre ecrit et potentiellement contenir plus de bugs
[^] # Re: J'y crois pas.
Posté par lolop (site web personnel) . Évalué à 5.
Pour les softs où la majeure partie des traitements peuvent être réalisés en appelant les bibliothèques compilées fournies avec le langage (ex. chaînes et regexp en Perl ou Python) et où le code ne fait qu'organiser la logique des traitements, la différence C/langage de script sera minime.
Par contre pour des softs où tu es obligé de faire pas mal de choses directement dans le langage (typiquement les boucles de calcul), le C gagnera. Mais tu peux aussi commencer à coder en Perl/Python/Ruby et consor, et une fois que tu as identifié les 5% du soft qui sont critiques (si vraiment tu as des problèmes de perfs par rapport à ton usage), les adapter sous forme de module d'extension en C pour ton langage de script.
Un avantage au C toutefois: l'overhead au lancement est plus faible que les langages de scripts. Vaut mieux éviter Perl/Python/Ruby & Co si c'est pour les relancer un million de fois (ou alors il faut adapter pour éviter d'avoir à relancer - du genre spamd pour spamassassin).
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: J'y crois pas.
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Après avoir lu le code d'un ou deux greffon de qpsmtpd, j'ai rajouté les miens. Tu copie ton code dans le bon dossier, tu relances et hop, c'est en production. Ca gère quand même 1500000 courriel par jour chez moi.
Je n'aurais jamais fait cela sur Postfix ou sur une usine à gaz basé sur java. Trop compliqué et trop peur de ne pas être capable de maintenir dans le temps mes greffons.
Bref, c'est facile de démolir Perl mais personnellement, je préfère voir une application Perl tourner sur mon système que voir un machin java dont je n'y comprends rien. Question de goût (et puis aussi de liberté).
[^] # Re: J'y crois pas.
Posté par pasBill pasGates . Évalué à 4.
[^] # Re: J'y crois pas.
Posté par ckyl . Évalué à 6.
Y'a un intêret à ton message hormis dire "J'y connais un peu en X, j'y connais rien en Y. Alors je dis que j'utilise des trucs qui reposent sur X en cassant du dos sur Y alors que j'y connais rien" ?
Tu sais des mécanismes de plugins bien fait, drag & drop ca peut se faire dans tout les langages (et même en s'ouvrant à plein d'autres langages que celui du coeur de l'appli). Et si tu veux que les admins qui ne sont pas des devs écrivent des extensions, tu fais des trucs propres et simples à utiliser comme des bêtes filtres E/S ou embarquer des interpreteur python/ruby/js (ca se fait en 10 lignes de Java-beurk) etc.
[^] # Re: J'y crois pas.
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
Un serveur internet^Wweb efficace pas en C : http://john.freml.in/teepeedee2-release
Mais j'avoue, difficile de comparer car personne n'a envie de recoder une appli déjà existante conséquente from scratch…
Ptet que les scripts-fu de gimp sont plus conséquents qu'un micro-bench et facilement récrivables dans d'autres langages ?
Moi j'attends toujours de voir dans le monde réel des softs sans bugs de merdes qui sont uniquement dus au choix d'un langage de bas niveau…
[^] # Re: J'y crois pas.
Posté par Jul (site web personnel) . Évalué à 1.
Mongrel en est l'exemple :
http://www.complang.org/ragel/ (j'ai perdu la page web ou le développeur interviewé raconte cette histoire).
Sa méthodologie de mémoire est :
- Tu prends un framework orienté evènement (twisted, POE, whatever);
- Tu prends ragel, tu génères ton automate à état à partir de la norme ;
- Tu fait de la plomberie pour faire correspondre les états bnf formels aux état du protocole réseau que tu veux, rajouter les conf;
- Tu écris les hook pour chaque état en transposant calmement les actions décrites dans la RFC ;
- Tu fais des tests non «unitaires» mais de conformité au protocole, et tu raffines jusqu'à ce que tu atteignes 100% (je parie que c'est la partie la plus longue)
Il se trouve que ragel génère du donc C tu peux essayer, le résultat devrait être le même qu'avec ruby, juste plus long.
À titre perso J'ai pas réussi à générer le code pour la norme diameter, on dirait que la syntaxe est incomplète ou non conforme, ou alors qu'il faut peut être que j'apprenne l'info :)
[^] # Re: J'y crois pas.
Posté par Krunch (site web personnel) . Évalué à 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: J'y crois pas.
Posté par Etienne Bagnoud (site web personnel) . Évalué à -2.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: J'y crois pas.
Posté par Guillaume Denry (site web personnel) . Évalué à 10.
Même si sur le fond je vois ce que tu veux dire, personnellement, je me méfie de ce genre de phrase à l'emporte-pièce, un langage peut offrir des mécanismes qui permettent de n'avoir à ne pas se soucier de certains aspects casse-gueule d'autres langages.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: J'y crois pas.
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
Tu peux mettre toutes les protections que tu souhaites au coeur du langage, ça ne va pas empêcher un programmeur de laisser un trou béant dans son application s'il utilise le mauvais concept.
Les fonctionnalités fournies dans ces langages ne sont pas là pour sécurisé l'application, mais pour décharger le programmeur de certains concepts délicats à gérer et ainsi permettre un développement plus rapide d'application complexe.
En C, comme dans n'importe quel autre langage, tout est disponible pour bien faire. La sécurité intervient uniquement au niveau du programmeur/développeur et il est autant possible de faire un programme sécurisé en C qu'avec n'importe autre langage, le temps est sensiblement différent et surtout lié aux compétences de celui qui code.
D'ailleurs tu le dis, certains langages permettent de désactiver ces mesures internes de sécurités, ce n'est pas par hasard.
Ensuite le protocole HTTP est connu et maîtrisé depuis un certain temps maintenant, je ne crois pas qu'il puisse encore poser problème en l'état actuel et les solutions existent et dans les problèmes que tu cites, soit ça se règle en appliquant "les bonnes pratiques de la programmation" (buffer overflow, droit d'accès, échappement divers), soit inhérent au fonctionnement réseau (et donc pas spécifique au protocole)(DOS).
Après c'est pas le premier venu qui peut le faire, mais en terme de protocoles, il reste simple comparé à ce qui se fait ces temps.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: J'y crois pas.
Posté par Guillaume Denry (site web personnel) . Évalué à 6.
Tu peux mettre toutes les protections que tu souhaites au coeur du langage, ça ne va pas empêcher un programmeur de laisser un trou béant dans son application s'il utilise le mauvais concept.
Ce qui me gène, c'est ton "rien à voir". Tout n'est pas noir ou blanc comme ça. Un langage avec de fortes contraintes pendant les phases de construction (cf. ADA) permet d'éviter des erreurs (pour des raisons de distraction, de compétence, de fatigue intellectuelle, etc) qui peuvent être des vecteurs de faille, même s'il ne garantit pas -évidemment- que ton programme sera une forteresse inviolable.
La sécurité en programmation est un concept très vaste qui commence à partir du moment où le développeur pose ses doigts sur le clavier jusqu'à la mise en production. Que le langage utilisé puisse être un maillon dans cette problématique, ça me paraît évident.
[^] # Re: J'y crois pas.
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
L'implication du langage reste minime. Des projets comme djdns ou qmail démontre bien qu'il est possible de faire des programmes complexes et sécurisé en appliquant les bonnes méthodes connues et reconnues comme étant sûres.
Il me semble qu'Ariane 5 s'est écrasée à cause d'un dépassement arithmétique, et ce malgré l'utilisation de ADA. Il me semble que cette sécurité avait été désactivée du langage pour des raisons d'efficacité (enfin c'est wikipedia qui le dit).
Ces sécurités dans le langage sont pour assister le développeur, mais à aucun moment il est correct de dire :
Bon, je ne suis jamais convaincu par "C" et "sécurité" ensemble.
Des langages de haut niveau qui se compilent et qui ont des performances comparables à C, c'est pas ce qui manque. Et ces langages ont au moins le bon goût de ne pas permettre de buffer overflows, le bug de base qu'on trouve dans au moins 100% des logiciels écrits en C.
C'est une approche erronée. Le langage peut offrir des sécurités pour le développeurs, mais ce n'est de loin pas l'élément clé de la sécurité et le penser est une faille de sécurité ("oh je contrôle pas ça, le langage s'en occupe").
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: J'y crois pas.
Posté par Guillaume Denry (site web personnel) . Évalué à 4.
Maintenant, personne n'a dit ici que le langage était l'élément clef en matière de sécurité, ça ressemble un peu à un homme de paille.
Je ne suis pas un expert (surtout au niveau statistique), mais on parle beaucoup de buffer overflow en matière de failles de sécu et tu ne peux pas nier qu'il est plus facile d'en faire dans un langage qui permet aussi facilement de faire de tels accès dans la mémoire que dans d'autres qui te foutent des barrières pour ça ou qui n'offrent même pas conceptuellement les outils pour pouvoir en faire.
Et puis citer le cas d'Ariane 5, je ne vois pas trop ce que ça apporte au débat. Aucun langage ne permet de faire un programme parfait ? Big news! Si on désactive sciemment un catch d'exception pour des raisons de performance, c'est au détriment de la sécurité ? Big news!
[^] # Re: J'y crois pas.
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Que la sécurité dépend clairement du développeur et quel que soit le langage. Ce comportement est typique. Le bug d'Ariane : on a une erreur, on désactive; le bug SSL Debian : erreur, on commente le code; un "buffer overflow", on double la taille du buffer ...
Actuellement on invente des langages pour corriger les problèmes typiques des langages précédents, des développeurs qui connaissent 30 langages mais à moitié et donc on a des programmes affreusement buggé, des solutions basées sur le langage "hype" du moment (qui seront inutilisables dans 3 ans), ...
D'un autre côté on un langage populaire et connu de tous, dont les "bonnes manières" sont connues, avec des algos testés, efficaces et décrits dans les livres, des compilateurs testés et optimisés, ...
Maintenant, personne n'a dit ici que le langage était l'élément clef en matière de sécurité, ça ressemble un peu à un homme de paille.
Heu :
Des langages de haut niveau qui se compilent et qui ont des performances comparables à C, c'est pas ce qui manque. Et ces langages ont au moins le bon goût de ne pas permettre de buffer overflows, le bug de base qu'on trouve dans au moins 100% des logiciels écrits en C.
Je comprend un peu comme "le langage défini le niveau de sécurité, C est au fond (non, creuse un peu encore)".
Que l'avis initial qui critiquait le choix du C pour écrire un serveur http sur le plan de la sécurité te semble idiot, c'est une chose.
Oui la deuxième partie est aussi dénuée de sens, mais j'avais déjà bondis.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: J'y crois pas.
Posté par 2PetitsVerres . Évalué à 4.
Ce n'est pas vrai. Les check Ada sont désactivé pour des raisons de performance (taille de code plus petite, exécution plus rapide, des trucs comme ça) pas parce qu'on a vu l'erreur et qu'on se dit que ce n'est pas grave. (enfin, ici c'est le cas, mais je ne bosse pas sur des lanceurs)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: J'y crois pas.
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: J'y crois pas.
Posté par 2PetitsVerres . Évalué à 2.
Au final, le problème c'est le manque de tests pour cause de "on a déjà testé". (ça m'arrange, mon boulot, c'est de tester \o/ )
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: J'y crois pas.
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Vu que ce n'est pas un avion, les 2 centrals sont les mêmes donc, les 2 ont envoyés les mêmes donnée d'autotest :)
En faisant un vote avec le modèle inertiel simulé, l'ordinateur de vol a corrigé, jusqu'à imposer des changements trop violent, ce qui a entrainer la destruction.
"La première sécurité est la liberté"
[^] # Re: J'y crois pas.
Posté par reno . Évalué à 4.
> Le bug d'Ariane : on a une erreur, on désactive
Uhm, sais-tu que le traitement devait se faire en un temps très court (bin oui au décollage d'une fusée, on n'a pas beaucoup de temps pour réagir)?
C'est surtout un problème de tests non (ré)effectué..
> le bug SSL Debian : erreur, on commente le code;
Oui, enfin de mon point de vue les programmeurs initiaux avaient aussi leur responsabilité dans l'affaire: l'utilisation de variable non-initialisée est suffisamment rare pour que tout bon programmeur avertisse les mainteneurs ultérieurs par des commentaires et nom de variables adéquats, ce qui je crois n'était pas le cas..
Pour le reste, oui pour avoir du code sécurisé il faut que les développeurs connaissent bien le langage, mais cela ne veut pas dire qu'on est obligé de se limiter au C..
[^] # Re: J'y crois pas.
Posté par 2PetitsVerres . Évalué à 2.
Même avec le catch activé, tu ne peux rien faire. Enfin, à part éventuellement mourir en beauté en disant "je suis mort là". Mais t'es mort quand même. (c'est quand même pratique de dire où on meurt)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: J'y crois pas.
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
[^] # Re: J'y crois pas.
Posté par 2PetitsVerres . Évalué à 6.
D'abord c'est Ada pas ADA, et ensuite ça n'aurait rien changé.
Tu as un overflow, si t'as pas de sécurité, l'équipement (la centrale inertielle ici) plante ou ne plante pas, s'il plante, on passe sur le redondant, qui plante pour la même raison. Si ça ne plante pas, tu envoie des données erronées. Dans les deux cas il faut détruire le lanceur.
Si tu as activé la sécurité, tu détectes l'overflow, soit tu sais pas le gérer, tu déclares que tu as planté, tu passes sur le redondant, il a fait aussi un overflow, tes deux équipements sont plantés. Tu détruis le lanceur. Ou alors tu détectes l'overflow, et tu sais le gérer. Mais c'est quoi la gestion ? De dire au lanceur de faire demi-tour ?
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: J'y crois pas.
Posté par Grunt . Évalué à 8.
Tu fais tout exploser avant que le soft plante. Comme ça, le soft n'a jamais planté, l'honneur est sauf.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: J'y crois pas.
Posté par Krunch (site web personnel) . Évalué à 9.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: J'y crois pas.
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 6.
Tu peux avoir le meilleur concept du monde, si tu dépasses de ton tableau en C, tu risques un trou de sécurité.
Si tu dépasses en Caml, tu risques une erreur.
Bon, ben, tant qu'à utiliser un concept, quel qu'il soit, autant faire en sorte que le trou béant soit molletonné, plutôt que rempli de seringues usagées déposées par tes soins parce que t'es un homme un vrai qui code en C.
Tu peux faire les mêmes erreurs dans presque tous les langages. Simplement, dans certains comme le C, ces erreurs ont un coût et effet supplémentaire. Pourquoi vouloir à tout prix conduire une voiture dont l'accélérateur se bloque quand tu appuies trop fort dessus, alors que toute autre modèle roule aussi bien sans le risque de blocage ?
[^] # Re: J'y crois pas.
Posté par Etienne Bagnoud (site web personnel) . Évalué à 1.
Ta comparaison est foireuse. Ce serais plutôt pourquoi prendre une manuelle au lieu d'une automatique ou une avec ABS ou sans ABS. Perso je prends le train :-)
L'analogie avec ton accélérateur qui se bloque c'est dire qu'il y a un problème fonctionnel au langage, alors que le problème que tu pointais c'est l'absence de sécurité (ABS) ou de facilités (manuel vs automatique).
Ensuite un trou avec des "seringues usagées déposées par tes soins", à part essayer de faire passer les programmeurs C pour des héroïnomanes, je vois pas le rapport.
Les langages de "bas-niveau" te donne juste la possibilité de te tirer une balle dans le pied si tu le souhaites et si tu le manipules pas correctement. Mais le langage ne va pas te tirer dessus si tu ne lui demande pas. C'est pas parce j'ai un fusil automatique 700 coups/minutes chez moi que je me suis tiré dessus où tiré sur quelqu'un. Mais j'ai les outils pour le faire.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: J'y crois pas.
Posté par Maclag . Évalué à 9.
Si tu la laisses dans l'armoire, il n'y aura pas d'accident.
Un habitué des armes a juste moins de chance de provoquer l'accident q'un néophyte. Mais il y aura un accident!
Maintenant, si tu penses que le vétéran est assez expérimenté pour que l'espérance de temps avant accident se compte en siècles, pas de problème.
Ce qu'on essaie de te dire, c'est que tu peux faire des erreurs dans tous les langages.
En C, tu peux toutes les reproduire, et tu peux en faire d'autres en jouant avec ton pistolet tous les jours. Au bout de combien de temps y'aura-t-il un accident avec le pistolet spécifique au C?
[^] # Re: J'y crois pas.
Posté par Antoine . Évalué à 7.
Pour des acceptions assez amusantes du mot "demander" parfois.
Prenons le code suivant :
void myfunc(int x, int y)
{
assert (x >= 0 && y >= 0);
if (x + y < 0) { /* overflow détecté */ }
...
}
Le "if" peut être supprimé par l'optimiseur car l'overflow des opérations arithmétiques signées n'est pas défini par la norme.
Ce genre de choses, soit tu les connais par coeur à l'avance (et la norme C ne fait pas 15 pages), soit elles peuvent faire mal quand elles t'arrivent.
Comme tu le sous-entends, le programmeur parfait n'est pas touché par ce genre de problèmes (et à lire les thuriféraires du C, on a toujours l'impression qu'ils se prennent pour des programmeurs parfaits). Mais un peu d'humilité est recommandé, dans n'importe quel métier...
[^] # Re: J'y crois pas.
Posté par ckyl . Évalué à 8.
À mettre en relation avec le fait que dans un journal, presque 40 ans après la création du C, on en est encore à discuter de savoir si post incrémenter un entier dans une boucle for c'est bien ou pas...
[^] # Re: J'y crois pas.
Posté par Jux (site web personnel) . Évalué à 4.
[^] # Re: J'y crois pas.
Posté par bilboa . Évalué à 2.
moi je pense que c'est surtout les gens qui ne savent pas trop coder en C et qui privilegient les languages haut niveau pour tout et n'importe quoi. La nouvelle génération quoi :p
Comme on dit c'est juste la question de choisir le bon outil pour la tâche, pas d'utiliser le language qui à l'air le plus cool à un moment donné (ou autre raison superficielle du même type)
[^] # Re: J'y crois pas.
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: J'y crois pas.
Posté par boq . Évalué à 1.
http://nanoweb.si.kz/
[^] # Re: J'y crois pas.
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Les buffer overflow et autre injection de code s'est typique du C.
"La première sécurité est la liberté"
[^] # Re: J'y crois pas.
Posté par gato . Évalué à -1.
oui, ce n'est pas du tout le cas en php ou sql.
Ce Sidi, comment s'appelle ce noyau écrit en C, Nilux ? et cet environnement
de bureau, Mogne ? et ce serveur web, Chapach ? Quelle idée de les avoir
écrits en C, ils n'auront jamais de succès.
[^] # Re: J'y crois pas.
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Linux avec le bug du mappage de la page zéro, c'est bien à cause du comportement du C !
"La première sécurité est la liberté"
[^] # Re: J'y crois pas.
Posté par Christophe Casalegno . Évalué à -1.
Il faut le compiler avec StackGuard :)
[^] # Re: J'y crois pas.
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: J'y crois pas.
Posté par Christophe Casalegno . Évalué à 1.
# Sécurité ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 9.
static char *attrmimetype(char *file)
{
#ifdef HAVE_XATTR
static char buf[1024];
int i;
ssize_t sz;
if((sz = getxattr(file, "user.ash-mime-type", buf, sizeof(buf) - 1)) > 0)
goto found;
if((sz = getxattr(file, "user.mime-type", buf, sizeof(buf) - 1)) > 0)
goto found;
if((sz = getxattr(file, "user.mime_type", buf, sizeof(buf) - 1)) > 0)
goto found;
if((sz = getxattr(file, "user.Content-Type", buf, sizeof(buf) - 1)) > 0)
goto found;
return(NULL);
found:
for(i = 0; i < sz; i++) {
if((buf[sz] < 32) || (buf[sz] >= 128))
return(NULL);
}
buf[sz] = 0;
return(buf);
#else
return(NULL);
#endif
}
Bon, goto bien utilisé ça peut être pratique.
Cependant, renvoyer l'adresse d'une variable locale c'est pas bien, et c'est encore pire quand elle est statique. Quid d'appels consécutifs, parallèles ?
Les débutants utilisent la post-incrémentation et ne comprennent pas que ni sizeof ni return ne sont des fonctions.
Le copier-coller c'est mal, DRY qu'il y'en a qui disent.
Tiens, c'est pas documenté, donc on ne sait même pas qu'il faut copier 1024 - 1 caractère depuis le pointeur retourné dans un nouvel emplacement. Une fonction difficile à utiliser manipulant des chaînes conduit inexorablement à des problèmes de sécurité.
Et je n'ai regardé qu'une fonciton.
[^] # Re: Sécurité ?
Posté par beagf (site web personnel) . Évalué à 2.
Les débutants utilisent la post-incrémentation
Vu que dans le code, il n'y a qu'une seule post-incrémentation, je suppose que tu fais référence à celle qui est présente dans le for. À cet endroit, que tu fasse un post ou une pré-incrémentation, la sémantique est exactement la même et le compilateur choisira tout seul la meilleure manière de compiler, donc il n'y a rien à dire ici.
Et de manière plus générale, pendant longtemps la pré-incrémentation était globalement considérée comme plus rapide car elle ne nécessitait pas de garder de copie de l'ancienne valeur. Aujourd'hui ce n'est plus le cas. En général une post-incrémentation est plus rapide car elle introduit moins de dépendance dans les calculs. L'incrémentation peut-être faite en même temps que l'opération qui utilise l'ancienne valeur.
Donc, pour te corriger : "Les débutants (peut-être) et les bon programmeurs qui ont fais évoluer leurs convictions utilisent la post-incrémentation".
[^] # Re: Sécurité ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à -2.
À titre d'illustration, en C++, on surcharge classiquement l'opérateur de post-incrémentation ainsi (T étant un type quelconque) :
// Post incrémentation
T const operator ++(typename const & target)
{
T tmp(target) ;
++target ;
return tmp ;
}
// Pré incrementation
T const & T::operator ++(int)
{
// On fait l'incrémentation ici
return *this
}
On voit bien que la post-incrémentation devrait créer une copie temporaire à retourner (même si c'est un objet anonyme qui est créé, ça dépend des options d'optimisation).
L'incrémentation ne devrait pas être faire en même temps qu'une autre opération : le C ne garanti pas forcément un ordre d'exécution des instruction dans une même expression. Le choix est laissé à l'implémentation. Par exemple, dans l'expression suivante, le résultat est indéterminé par le standard C.
f(i++, i -=2) ;Donc non, la post-incrémentation est à proscrire sauf cas particuliers.
[^] # Re: Sécurité ?
Posté par ckyl . Évalué à 5.
Bref en mettant tes habitudes de côté et avec un peu de bonne fois tu peux aussi admettre qu'en C post-incrémenter dans une boucle ca change keud et ca n'a rien de sâle.
PS: Avec un bête grep qui doit manquer la moitié des occurences, je trouve 33757 post incrémentations dans une boucle dans les sources du 2.6.34.1. Tu postes un patch sur LKML pour nous divertir un peu ?
[^] # Re: Sécurité ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à -1.
Ça ne change effectivement pas grand chose, mais c'est quand même une mauvaise habitude (se reposer sur le compilateur pour compenser une mauvaise habitude).
Utiliser des noms de variables obscures ou ne pas documenter son code ne change non plus pas grand chose à l'exécution du code compilé. Ceci dit, ce ne sont pas de bonnes pratiques.
Quand au code du noyau, je n'y touche pas. Je n'ai pas le matériel ni l'expérience pour le modifier.
[^] # Re: Sécurité ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: Sécurité ?
Posté par Antoine . Évalué à 5.
[^] # Re: Sécurité ?
Posté par shbrol . Évalué à 2.
T const operator ++(typename const & target)Le deuxieme const semble de trop, non ?
[^] # Re: Sécurité ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: Sécurité ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: Sécurité ?
Posté par Antoine . Évalué à 2.
[^] # Re: Sécurité ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: Sécurité ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
// Post incrémentation
T const operator ++()
{
T tmp(*this) ;
++*this ;
return tmp ;
}
// Pré incrementation
T const & T::operator ++(int)
{
// On fait l'incrémentation ici
return *this
}
[^] # Re: Sécurité ?
Posté par beagf (site web personnel) . Évalué à 4.
Ici on parlait du C, donc...
De plus, même en C++ la post-incrémentation à du sens puisque une grosse partie ne concerne que les entiers sans operateurs surchargés, et donc reviens au même que pour le C.
Ceci dit, le compilateur n'est pas contraint d'optimiser, et une variable temporaire peut donc être générée lors de la post-incrémentation pour récupérer le résultat de la post-incrémentation.
Au contraire, le compilateur est contraint d'optimiser. Les dev du compilo ne vont bien sur pas mourir s'il n'optimise pas, mais c'est l'essence même du compilo d'optimiser.
Grace au bon niveau d'optimisation des compilos actuels, il est maintenant possible pour beaucoup d'algo d'écrire un code lisible avec une sémantique claire et de laisser le compilo optimser le tout, là ou avant on était obliger d'optimiser à la main et d'obtenir un code dur à maintenir.
Le fait d'utiliser une post-incrémentation dans un calcul est juste un moyen de faciliter la vie du compilo en lui indiquant que à cet endroit il y a moyen de faire deux calculs en même temps. Un jour, la réécriture de boucle aura suffisamment avancée pour que l'on puisse écrire de n'importe quelle manière, le compilo s'en apercevra tout seul et on pourra choisir l'option la plus lisible pour maintenir le code.
L'incrémentation ne devrait pas être faire en même temps qu'une autre opération : le C ne garanti pas forcément un ordre d'exécution des instruction dans une même expression.
Sauf que ton exemple n'est qu'un cas particulier ou en effet il ne faut pas le faire. Si tu prend l'exemple suivant :
dst[pdst++] = src[psrc++];
et que tu le met dans une boucle, utiliser la post-incrementation permet de faire l'affectation en même temps que les deux incrémentation, alors que la pre-incrémentation nécessiterait d'attendre que les deux incrémentation soient finie pour faire l'affectation.
Donc non, la post-incrémentation est à proscrire sauf cas particuliers.
Je maintien que non. La post-incrémentation n'est à proscrire que dans le cas très particulier ou tu fais du C++ avec des opérateur surchargés et donc sur des classes et pas des entiers et que tu utilise un mauvais compilateur.
De manière générale elle est souvent meilleur ou equivalent à la pre-incrémentation, et sur un rapide sondage (qui ne veut pas dire grand chose...) des codeurs autour de moi, à peu près tout le monde la trouve plus lisible.
[^] # Re: Sécurité ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à -1.
Le boulot du compilateur n'est pas d'optimiser. Le travail du compilateur c'est de traduire du code source en code machine. L'optimisation, c'est du bonus. Compter sur les optimisations du compilateur, c'est s'assurer d'écrire du code qui n'est pas portable pour un sous.
Le standard C ne garanti pas que l'incrémentation soit effectuée avant ou après l'affectation. C'est un détail d'implémentation laissé au concepteur du compilateur. C'est du code qui n'est pas portable.
Une des règles de base en programmation, c'est quand même d'éviter de faire plus d'une chose par ligne. Surtout en C.
[^] # Re: Sécurité ?
Posté par Hank Lords . Évalué à 3.
Non c'est faux. les règles de priorité s'appliquent, ++ (post ou pré incrémentation) à une plus grande priorité que = (affectation). Il n'y a aucune ambiguité (en C++ je ne sais pas).
[^] # Re: Sécurité ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à -2.
Paragraphe 6.5
Je cite:
“71) This paragraph renders undefined statement expressions such as
i = ++i + 1;
a[i++] = i;
”
Les règles de priorité s'est bien beau, mais elles sont là pour indiquer à l'implémenteur le comportement souhaitable. C'est comme l'évaluation fainéante : elle est courante, mais n'est absolument pas garantie par les normes du C.
[^] # Re: Sécurité ?
Posté par pasBill pasGates . Évalué à 7.
Par contre
k = i++ par exemple, ca aura la meme valeur sur _tous_ les compilos C qui respectent le standard, idem pour array[k++]=j++.
[^] # Re: Sécurité ?
Posté par ckyl . Évalué à 3.
Between the previous and next sequence point an object shall have its stored value
modified at most once by the evaluation of an expression.72) Furthermore, the prior value
shall be read only to determine the value to be stored.73)
Ce qui ne correspond en rien à ce dont on discute: dst[pdst++] = src[psrc++]; ou la post incrémentation en général. Ou alors il va falloir expliquer en quoi...
C'est marrant à chaque fois que tu parles de quelque chose, ou que tu essayes de te justifier tu changes complétement de sujet. C'est pas plus simple de dire "J'ai dit une connerie ca change rien en C" ?
Reconnaitre qu'on a tord et qu'on ne sait pas tout c'est un bon début pour faire un bon développeur. Bien meilleur que de brailler sur des points d'une importance plus que douteuse.
[^] # Re: Sécurité ?
Posté par MrLapinot (site web personnel) . Évalué à 2.
Unlike the bitwise binary & operator, the && operator guarantees left-to-right evaluation; there is a sequence point after the evaluation of the first operand. If the first operand compares equal to 0, the second operand is not evaluated.
(ISO/IEC 9899:1999, 6.5.13 § 4)
[^] # Re: Sécurité ?
Posté par beagf (site web personnel) . Évalué à 2.
Tu peux m'expliquer pourquoi ?
Le parcours d'un tableau est quand même une tache extrêmement courante et bien plus lisible avec des entiers qu'avec un itérateur.
Le boulot du compilateur n'est pas d'optimiser. Le travail du compilateur c'est de traduire du code source en code machine. L'optimisation, c'est du bonus. Compter sur les optimisations du compilateur, c'est s'assurer d'écrire du code qui n'est pas portable pour un sous.
Bien au contraire c'est son boulot et c'est même ça qui permet d'écrire du code portable. C'est le compilo qui s'occupe d'écrire les optimisation qui sont spécifique à l'architecture et qui fait que pour la majorité des cas le programmeur n'a pas en s'en occuper.
Si les compilos n'optimisait tous les soft un peu critiques devrait être écris en assembleur et il n'y aurait pas de langage de haut niveau. Le peu de code qu'il y aurait en C serait illisible et ne tournerait rapidement que sur quelques machines.
Ne pas utiliser un compilateur qui optimise correctement et ne pas tenir compte du fait qu'il optimise est actuellement une stupidité. Tu en tiens toi même surement compte ou alors tu n'utilise que très peu des fonctionalitées du C++.
Le standard C ne garanti pas que l'incrémentation soit effectuée avant ou après l'affectation. C'est un détail d'implémentation laissé au concepteur du compilateur. C'est du code qui n'est pas portable.
Si je reprend mon exemple :
dst[pdst++] = src[psrc++];On en à rien a battre que les incrémentations soient faites avant ou après l'affectation justement, c'est même ça qui permet au processeur de les faire en même temps.
La seule chose à ne pas oublier c'est qu'il ne faut pas utiliser plusieurs fois la même variable sur une ligne si on l'inclémente.
Une des règles de base en programmation, c'est quand même d'éviter de faire plus d'une chose par ligne. Surtout en C.
Des règles de base stupides il y en a des tonnes... Du style de pas faire des fonctions de plus de 10 lignes ou autre truc du même genre.
Et comme partout ce sont des conseils généraux et il faut savoir passer outre quand ça améliore la lisibilité du programme.
[^] # Re: Sécurité ?
Posté par 2PetitsVerres . Évalué à -1.
dst[pdst++] = src[psrc++];
On en à rien a battre que les incrémentations soient faites avant ou après l'affectation justement, c'est même ça qui permet au processeur de les faire en même temps.
T'est en train de dire que faire
dst[42] = dst[24];
ou
dst[43] = dst[25];
c'est pareil là non ? Permet moi d'en douter.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Sécurité ?
Posté par barmic . Évalué à 4.
> dst[pdst++] = src[psrc++];
est donc équivalent à
dst[12] = src[42];
Il n'y a aucune ambiguïté dans cette expression. La valeur de chaque entier est incrémenté après avoir était retournée.
De la même manière :
> dst[++pdst] = src[++psrc];
N'est pas non plus ambigue -> dst[13] = src[43];
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Sécurité ?
Posté par beagf (site web personnel) . Évalué à 3.
dst[42] = dst[24];
ou
dst[43] = dst[25];
c'est pareil là non ? Permet moi d'en douter.
Non, je suis en train de dire que l'on s'en fou que le compilo fasse :
dst[42] = src[24];psrc = psrc + 1;
pdst = pdst + 1;
où
psrc = psrc + 1;pdst = pdst + 1;
dst[42] = src[24];
Dans les deux cas cela reviens au même d'un point de vue sémantique. L'opérateur de post-incrémentation signifie que la valeur qui sera utilisée pour indexer le tableau est la valeur de la variable avant de faire l'incrémentation. Donc soit le compilateur fait l'incrémentation après l'indicage, soit il l'a fait avant et dans ce cas il doit conserver une copie de l'ancienne valeur.
Dans la pratique, pour le processeur récents, le compilateur va faire une sauvegarde des valeurs et ensuite placer les instructions pour l'affectation et les incrémentation. L'avantage c'est qu'il n'y a aucune dépendances entre l'affectation et les deux incrémentations, le compilateur peut donc faire les trois en même temps s'il à suffisamment d'unités de calculs libres à ce moment là. Et avec le renomage de registres dans le processeur c'est généralement la manière la plus efficace de coder cette opération.
La sémantique des pre/post-incrémentation en C en parfaitement claire et la seule chose à retenir dans un cas comme dans l'autre est qu'une variable pre/post-incrémentée ne doit être utilisée qu'une seule fois dans une expression.
[^] # Re:Sécurité ?
Posté par tesiruna . Évalué à -2.
[^] # Re: Sécurité ?
Posté par zetta . Évalué à 1.
N'importe quoi... Renvoyer l'adresse d'une variable locale est à banir, certes, le segfault est quasi assuré. Mais ce n'est pas pire lorsque la variable locale est déclarée en "static", c'est juste possible... Rien à voir...
Parler de problématiques d'appels parallèles et consécutifs alors que tu dis n'avoir regardé qu'une fonction est risible.
Note que je ne cherche pas à défendre ce programme que je ne connais pas et qui est peut-être bourré de bugs, mais ce genre de commentaire ciblé me hérisse le poil.
[^] # Re: Sécurité ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
C'est pire lorsque la variable est statique pour une simple raison : l'exécution du code aura encore plus l'aspect d'un code fonctionnel. Or, ici on voit très bien que la fonction est un piège à con, comme je l'ai déjà expliqué plus haut.
En quoi est-ce risible ?
Mon commentaire est uniquement destiné à mettre en perspective le prétendu focus sur la sécurité mis en avant dans la dépêche. Je suis persuadé qu'un audit approfondi apporterait de l'eau à mon moulin.
[^] # Re: Sécurité ?
Posté par fearan . Évalué à 3.
Alors la je regrette, il ne faut jamais renvoyer l'adresse d'une variable locale, sauf si elle est statique.
C'est tout l'intérêt de la variable statique.
Ensuite, il faut bien s'assurer de ne l'utiliser que sur une section critique, ou ne pas avoir d'accès concurrent.
Ici on a l'avantage de ne pas avoir de malloc ou free sur la variable, chose qui serait obligatoire si il se passait du static
L'inconvénient c'est qu'on monopolise 1ko de ram, même si on s'en sert pas.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Sécurité ?
Posté par fearan . Évalué à 2.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Sécurité ?
Posté par Krunch (site web personnel) . Évalué à 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re:Sécurité ?
Posté par tesiruna . Évalué à 1.
Il me semble que la variable statique ne sera allouée que lors du premier appel
à la fonction. Donc si tu n'utilises pas du tout la fonction, elle ne sera
jamais allouée.
[^] # Re: Re:Sécurité ?
Posté par 2PetitsVerres . Évalué à 3.
Par exemple :
$ cat test.c
#include <stdio.h>
static char *attrmimetype(char *str)
{
static char buf[1024];
sprintf(buf, str);
return buf;
}
int main(int argc, char * argv[]) {
if (atoi(argv[1]) == 42) {
char * plop;
plop = attrmimetype("toto\0");
printf(plop);
printf("\n");
}
return 0;
}
$ gcc -DSIZE=1024 -O0 -o test.1024 test.c
$ gcc -DSIZE=1 -O0 -o test.1 test.c
$ readelf -S test.1024 test.1 |grep bss -A1
[24] .bss NOBITS 00000000005009c0 000009a80000000000000420 0000000000000000 WA 0 0 32
--
[24] .bss NOBITS 00000000005009a8 000009a8
0000000000000008 0000000000000000 WA 0 0 4
La longueur du .bss (alloué au chargement) passe de 0x420 à 0x8 en changeant la variable de 1024 octets à 1. (je n'ai pas cherché à comprendre pourquoi le gain de place est plus grand que 1024, probablement un alignement ?)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Re:Sécurité ?
Posté par 2PetitsVerres . Évalué à 2.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Re:Sécurité ?
Posté par neologix . Évalué à 2.
Une variable statique va dans le segment data, ou dans le bss si elle n'est pas initialisée (du coup elle ne prend pas de place dans le binaire, mais la place est allouée lors du chargement en mémoire).
D'ailleurs je ne vois pas comment elle pourrait être allouée auto-magiquement à l'appel de la fonction (elle ne peut pas être stockée dans la pile, et il faudrait faire un appel à sbrk/mmap pour l'allouer dans le tas).
[^] # Re: Re:Sécurité ?
Posté par 2PetitsVerres . Évalué à 2.
faire pointer par défaut l'appel à la fonction vers une fonction allouant la variable statique puis surchargeant cet appel pour ne plus qu'il soit fait.
Schématiquement :
la_fonction :
call alloue_buf
code utilisant registre_x quand il a besoin de buf
alloue_buf :
buf = malloc 1024
ecrire registre_x <-- buf sur la première instruction de la_fonction
jmp la_fonction+offset
Mais c'est moche (et pose des problèmes de concurrence)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re:Re:Sécurité ?
Posté par tesiruna . Évalué à 2.
incertitude).
Je suis d'accord que ton explication a du sens, j'ai été trompé par l'idée qu'en
C++ le constructeur d'une variable statique ne sera exécuté que lors du premier
appel, donc que, j'imagine, toute variable statique n'est initialisée qu'au
moment du premier appel (à vérifier néanmoins).
Dont acte.
[^] # Re: Re:Re:Sécurité ?
Posté par shbrol . Évalué à 1.
[^] # Re:Re:Re:Sécurité ?
Posté par tesiruna . Évalué à 2.
[^] # Re: Re:Re:Sécurité ?
Posté par Krunch (site web personnel) . Évalué à 2.
$ cat t.c #include <stdio.h> #include <stdlib.h> static int s(int d) { static int zero; static int quarantedeux = 42; return d + zero + quarantedeux; } int main(int argc, char **argv) { printf("%d\n", s(atoi(argv[1]))); return 0; } $ cc -O0 -o t.so t.c $ nm t | egrep 'zero|qua' 0000000000600968 d quarantedeux.2396 0000000000600980 b zero.2395pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Re:Re:Sécurité ?
Posté par Troy McClure (site web personnel) . Évalué à 3.
[^] # Re: Sécurité ?
Posté par lendemain . Évalué à 2.
[^] # Re: Sécurité ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
En C, une bonne pratique consiste à demander au client (le code qui utilise la fonction) d'initialiser une zone mémoire et de fournir un pointeur sur cette zone avec la taille. Ça évite de prendre la responsabilité d'allouer de la mémoire, ou d'utiliser ce genre de bricolage.
Ne pas prendre la responsabilité d'allouer de l'espace mémoire permet de laisser au client le choix de l'allocateur, du type de mémoire (automatique ou dynamique), etc.
Et effectivement, en passant, si à chaque invocation l'application doit initialiser de la mémoire automatique statique pour une centaine de fonctions, ça va commencer à faire cher l'optimisation précoce.
[^] # Re: Sécurité ?
Posté par Krunch (site web personnel) . Évalué à 4.
> laisser au client le choix de l'allocateur, du type de mémoire (automatique ou
> dynamique), etc.
Heu, le gros problème du C c'est que tu dois te coltiner la gestion de la mémoire toi même justement et qu'il est facile de faire des erreurs. Si la fonction gère la mémoire à la place de l'appelant, ça fait beaucoup mois de possibilités d'erreurs.
Après, il y a des cas où utiliser un buffer static ne correspond pas aux besoins de l'appelant mais alors tu fais une variante fonction_r().
Quant à la sois disant perte de performance dûe à l'initialisation, charger un octet en mémoire (ou même 1024 octets) me semble passablement moins couteux que de faire un malloc().
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Sécurité ?
Posté par vpo . Évalué à 3.
Les optimisations du compilo peuvent supprimer des returns si bien que le debug en mode pas à pas ne permettra plus de pointer au bon endroit dans le code source d'origine.
# Philosophie UNIX
Posté par MarbolanGos (site web personnel) . Évalué à 3.
On peut aussi ne pas avoir connaissance de ce document alors j'en parle.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.