Un nouveau serveur httpd : Ashd, A Sane HTTP Daemon

Posté par (page perso) . Modéré par tuiu pol.
Tags :
25
22
sept.
2010
Linux
Ashd est un serveur HTTP conçu selon la philosophie Unix : simplicité et modularité. Ashd (A Sane HTTP Daemon) est écrit en langage C, sous licence GPLv3 et vient d'annoncer sa sortie officielle en version 0.1. Il se compose d'un ensemble de programmes simples ayant chacun un rôle bien déterminé. Ashd a été pensé selon 4 piliers fondateurs :
  • 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)...
  • # Principe intéressant

    Posté par . Évalué à 10.

    On peut envisager la distribution des modules sur plusieurs machines de façon scalable, c'est plutôt sympa.
    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 (page perso) . Évalué à 6.

      Pour avoir besoin de scaler un serveur http statique, il faut taper TRES, TRES fort. La première réponse est de passer au CDN, et donc à la répartition géographique. Ce qui passe par le DNS.
      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 (page perso) . Évalué à 4.

        J'hésite.
        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

  • # Quelle soudaine productivité !

    Posté par . Évalué à -10.

    Vous qui n'avez presque rien publié depuis la création de votre compte, le 25 décembre 2003, vous voilà tout à coup bien prolifique, monsieur !
    • [^] # Pas si innocent

      Posté par . Évalué à 3.

      peut-etre que des evenements recents ont soudainement donne envie a notre ami de rattraper sa reputation
      • [^] # Re: Pas si innocent

        Posté par (page perso) . Évalué à -7.

        Effectivement, voici ce que j'ai par ailleurs posté.

        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.

        http://www.quaremme.be/

        • [^] # Re: Pas si innocent

          Posté par . Évalué à 5.

          Tu l'as déjà dis tout ça : http://linuxfr.org/comments/1164511.html#1164511
        • [^] # Re: Pas si innocent

          Posté par (page perso) . Évalué à 7.

          Franchement, on s'en branle.

          La dacabale (qui n'existe pas) va durer longtemps ?
        • [^] # Re: Pas si innocent

          Posté par (page perso) . Évalué à 9.

          Ça valait franchement la peine de tout recopier au lieu de filer un lien ? -_-'
        • [^] # Re: Pas si innocent

          Posté par (page perso) . Évalué à 9.

          Bon y en a marre ....

          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 . Évalué à 1.

      D'un autre côté, il ne fait que reprendre une note de son blog...
      • [^] # Re: Quelle soudaine productivité !

        Posté par (page perso) . Évalué à 10.

        Personne n'avait l'air de beaucoup parler de ce nouveau serveur sur le web, et je me suis dit que linuxfr avait sans doute un lectorat plus important que mon propre blog qui pouvait être intéressé par ce nouveau venu qui me semblait une initiative méritant d'être connue.
    • [^] # Re: Quelle soudaine productivité !

      Posté par (page perso) . Évalué à 5.

      le mieux, c'est peut-être de lui lâcher la grappe, sinon, cela va te coller aux mains.
    • [^] # Re: Quelle soudaine productivité !

      Posté par . Évalué à 10.

      Ca vous dirait de lui lâcher les basks et de parler de la news.

      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 . Évalué à 3.

        C'était un compliment. J'en ajoute un autre : je n'ai pas trouvé une seule faute d'orthographe dans cette news.
        • [^] # Re: Quelle soudaine productivité !

          Posté par (page perso) . Évalué à 9.

          >>> C'était un compliment. J'en ajoute un autre : je n'ai pas trouvé une seule faute d'orthographe dans cette news.

          C'est un compliment à l'adresse des relecteurs/modérateurs ?
          • [^] # Re: Quelle soudaine productivité !

            Posté par . Évalué à -2.

            Je me disais aussi. Ben bravo les relecteurs/modérateurs alors.
            • [^] # Re: Quelle soudaine productivité !

              Posté par . Évalué à 1.

              Tu pourrais préciser le fond de ta pensée ? Parce tous les posts sur lesquels il s'exprime ne me paraissent pas plus truffés d'erreurs que d'autres, moi y compris.

              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 . Évalué à 4.

                Finalement j'explique. Je fais un compliment sur l'orthographe de la news. Patrick_g fait un clin d'œil du genre peut-être le mérite en revient-il aux relecteurs. Je rebondis sur cette saillie en feignant une certitude à ce sujet. Je n'alourdis pas la blague en la rendant explicite par des remarques dissipant l'ambiguïté ou par des smileys.

                Et voilà. 'culer un mouton...
    • [^] # Re: Quelle soudaine productivité !

      Posté par (page perso) . Évalué à 8.

      AHMA, ce serait peut être plus intéressant de se préoccuper et de parler de ce nouveau-venu dans le milieu des serveurs web, que de l'auteur non ?
  • # Micro-noyau et copies mémoires

    Posté par (page perso) . Évalué à 9.

    On peut comparer Ashd à Hurd / MINIX (micro-noyau) et Apache à Linux (monolithique). J'avais lu que Hurd a de gros problèmes de performances car les données doivent être copiées d'un processus à l'autre (bien qu'il semble que ces problèmes soient spécifiques au micro-noyau GNU Mach et que les autres genre L4 sont moins pires). Je me demande comment ça se passe pour Ashd qui vante la séparation de processus comme qualité en matière de sécurité.

    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 (page perso) . Évalué à 6.

      > J'avais lu que Hurd a de gros problèmes de performances car les données
      > 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 (page perso) . Évalué à 6.

        Bon allez, j'ai ouvert sendfile.c : la fonction passdata() lit le fichier avec read par bloc de 64 Ko, puis écrit dans stdout avec write(). Bref, les données sont bien recopiées entre sendfile et htparser.
      • [^] # Re: Micro-noyau et copies mémoires

        Posté par . Évalué à 1.

        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.

        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 (page perso) . Évalué à 1.

      Je me posais exactement la même question. De mon point de vue naïf, j'ai pas l'impression que ce serveur soit prêt pour gérer une montée en charge significative.

      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 (page perso) . Évalué à 5.

    Qu'est ce que AssHoleDaemon (c'est le premier truc auquel j'ai pensé en voyant l'acronyme Ashd) apporte de plus par rapport aux Nginx, Cherokee et consorts (à part la page web digne d'une bonne vieille manpage) ? Il y'a une multitude de projets de serveurs web simples et modulaires.
    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 (page perso) . Évalué à 1.

      En fait pas du tout : je suis tombé dessus complètement par hasard. J'essaierai de le tester dans les prochaines semaines.
    • [^] # Re: Désolé

      Posté par (page perso) . Évalué à 5.

      Qu'est ce que AssHoleDaemon (c'est le premier truc auquel j'ai pensé en voyant l'acronyme Ashd) apporte de plus par rapport aux Nginx, Cherokee et consorts (à part la page web digne d'une bonne vieille manpage) ?

      À 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 . Évalué à 2.

        En fait, il me semble (après un survol rapide du code) que ashd utilise des sortes de coroutines : plusieurs contextes d'exécutions dans une même thread noyau (voir les fichiers lib/mt*.{c,h}). J'ai déjà vu cette technique dans une bibliothèque dont j'ai malheureusement oublié le nom :-( . Ça utilise les fonctions getcontext(2) et setcontext(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 (page perso) . Évalué à 2.

          L'utilisation de {g,s}etcontext() au niveau applicatif me semble assez douteuse (autant abstraire ça dans une bibliothèque de threading) mais différentes techniques permettant de servir plusieurs clients par thread sont détaillées sur http://www.kegel.com/c10k.html

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

          • [^] # Re: Désolé

            Posté par . Évalué à 2.

            D'autant plus que c'est pas supporté partout. Par exemple linux/arm ne le supporte pas.
            • [^] # Re: Désolé

              Posté par . Évalué à 1.

              La page de man indique même que getcontext/setcontext ne sont plus spécifiés dans la norme POSIX.1-2008 suite à des problèmes de compatibilité comme tu l'indiques, et recommandes de passer par les threads POSIX en remplacement.
      • [^] # Re: Désolé

        Posté par . Évalué à 1.

        pour la montée en charge, il y a epoll() qui remplace avantageusement select() ; c'est utilisé sur les serveurs de google.
  • # J'y crois pas.

    Posté par (page perso) . Évalué à 2.

    > Ashd (A Sane HTTP Daemon) est écrit en langage C
    > * 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 . Évalué à 9.

      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.

      Moi j'attends toujours de voir ca dans le monde reel et pas sur des micro-benchmarks.
      • [^] # Re: J'y crois pas.

        Posté par (page perso) . Évalué à 5.

        Rien à voir avec HTTP mais tout de même un peu dans le sujet. J'utilise comme relais de courriel qpsmtpd qui est écrit en Perl, a des performance plus que correct (gère si mes souvenirs sont bons apache.org) et surtout le code est modifiable, extensible très facilement. Bref, c'est du bonheur comparé à Postfix ou Exim pour ne reprendre que ces deux là.
        • [^] # Re: J'y crois pas.

          Posté par . Évalué à 10.

          a) Desole, mais Perl et "modfiable, extensible tres facilement" dans la meme phrase ca ne va pas :)
          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 (page perso) . Évalué à 5.

            L'avantage du C dépendra beaucoup du type de logiciel.

            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).
          • [^] # Re: J'y crois pas.

            Posté par (page perso) . Évalué à 3.

            Je n'ai jamais modifié le fonctionnement d'un logiciel écrit en C sur ma distribution.

            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 . Évalué à 4.

              Peut-etre, mais c'etait pas la question, on parlait performance...
            • [^] # Re: J'y crois pas.

              Posté par . Évalué à 6.

              > 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é).

              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 (page perso) . Évalué à 4.

        Mon WM est en haskell, très rapide, peu voire pas boggué. Jamais vu le moindre segfault…
        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 (page perso) . Évalué à 1.

          Ben, quand les RFC sont bien écrites, les syntaxes abnf correctes tu peux recoder un protocole en 3 mois avec un bon développeur dans C, C++, java ou ruby .

          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 (page perso) . Évalué à 3.

      Toutafé, le C pour le web c'est mal et pas secure. Yaka voir http://undeadly.org/ qui est plein de gens qui comprennent rien à la sécurité.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: J'y crois pas.

      Posté par (page perso) . Évalué à -2.

      Le langage utilisé n'a rien à voir avec la sécurité et je pense que le protocole est suffisamment simple pour être traité avec un langage de "bas-niveau". C'est pas parce que c'est codé en php, par exemple, que c'est automatiquement plus sûr.

      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

      • [^] # Re: J'y crois pas.

        Posté par (page perso) . Évalué à 10.

        Le langage utilisé n'a rien à voir avec la sécurité

        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.
      • [^] # Re: J'y crois pas.

        Posté par (page perso) . Évalué à 6.

        >Le langage utilisé n'a rien à voir avec la sécurité

        Le langage est très certainement seulement une partie de la réponse mais surement pas « rien ». Tout le monde sait que la sécurité c'est plus un processus qu'un produit mais le choix d'un langage fait sans nul doute partie intégrante de ce processus.

        Les différents langages offrent une multitude de concept favorisant la sécurité ou pas. Les objectifs de C ne sont certainement pas la sécurité (pas de vérification des débordements, pas - ou très peu - de vérification des types, gestion de mémoire jamais sure, ...) mais l'efficacité et le caractère bas niveau. Le C est clairement une réussite pour ces buts.

        Si on regarde des langages tels que Ada, Haskell, eiffel, OCaml, etc., on voit immédiatement que la sécurité a été prise en compte :
        - Vérification des types (Certains permettent néanmoins de passer outre) ;
        - Vérification des bornes des tableaux (Certains permettent néanmoins de passer outre) ;
        - Allocation de mémoire controllée ;
        - ...

        >et je pense que le protocole est suffisamment simple pour être traité avec un langage de
        >"bas-niveau".

        Le protocole n'est effectivement pas le plus complexe des protocoles. Mais le RFC fait quand même 176 pages ( http://tools.ietf.org/html/rfc2616 ) et dépend d'autres RFC (URL, MIME, charset, ...). L'écriture d'un serveur Http potable et secure est bien plus complexe qu'il n'y parait à première vue. Le contexte d'exécution (accessible au monde) et plein de petites subtilités font que cela peut très mal se passer :
        - Échappement divers ;
        - Buffer overflow via post et autres ;
        - Droits d'accès ;
        - Injections diverses ;
        - DOS ;
        - ...

        Si en plus, on doit s'ajouter les problèmes langages cela devient très vite très très complexe... Donc, il vaut mieux mettre tous les atouts de son coté et un langage adapté est indéniablement un atout.
        • [^] # Re: J'y crois pas.

          Posté par (page perso) . Évalué à 3.

          Le langage n'a rien à voir avec la sécurité, je persiste et signe.

          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 (page perso) . Évalué à 6.

            Le langage n'a rien à voir avec la sécurité, je persiste et signe.

            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 (page perso) . Évalué à 3.

              Peut-être c'est trop fort le "rien à voir". Mais en même temps remettre en cause un projet sur la base c'est trop fort aussi.

              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 (page perso) . Évalué à 4.

                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. Personnellement je le trouve extrême (mais pas complètement dénué de sens) : si j'avais à choisir un langage pour écrire un logiciel pareil, les problèmes de sécurité potentiels induits par l'utilisation du langage seraient un facteur à prendre en compte mais certainement pas le plus important.
                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 (page perso) . Évalué à 2.

                  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!

                  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 . Évalué à 4.

                    Le bug d'Ariane : on a une erreur, on désactive;
                    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 . Évalué à 2.

                      Pour avoir discuter avec des gens pas trop loin de la conception de la fameuse central inertiel, le problème est que le dépassement en question à pour moi bien levé une exception mais surtout le bignou est partie en auto test en balançant des infos sur le bus non invalide et qui on été mal interprété (genre 0x55 0xAA).

                      "La première sécurité est la liberté"

                      • [^] # Re: J'y crois pas.

                        Posté par . Évalué à 2.

                        De mémoire, la première centrale a signalé l'exception, ça a été pris en compte, mais quand ça a commencé a prendre les données de la deuxième (qui avait planté aussi) ça les as interprété comme bonnes. Mais à partir du moment où les équipements nominaux et redondants sont morts, et que ce sont des équipements vitaux, de toute façon, c'est fini. Et l'exception vue par la centrale, ce n'est pas l'exception Ada, mais l'exception matérielle (de mémoire)

                        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 . Évalué à 2.

                          C'était du reuse Ariane 4. Manque de bol l'enveloppe de vol n'était pas la même et l'accélération ou la vitesse horizontal n'était dans le même range.

                          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 . Évalué à 4.

                    Oui enfin tes analyses elles ne valent pas grands chose..

                    > 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 . Évalué à 2.

                  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!

                  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 (page perso) . Évalué à 2.

                    Je ne connais pas le contexte d'exécution dans le cas du vol 501 et je dis sûrement une connerie mais toutes les exceptions ne sont pas critiques. Un overflow n'est pas forcément fatal suivant là où il se déclenche et on peut tout à fait retomber sur ses pattes à un niveau d'exécution en dessous.
              • [^] # Re: J'y crois pas.

                Posté par . Évalué à 6.

                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).
                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 . Évalué à 8.

                  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 ?
                  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 (page perso) . Évalué à 9.

                  Bah tu arrêtes tout et tu attaches un debugger.

                  pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

          • [^] # Re: J'y crois pas.

            Posté par (page perso) . É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.

            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 (page perso) . Évalué à 1.

              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 ?

              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 . Évalué à 9.

                N'importe quel statisticien te dira que si tu manipules une arme chargée tous les jours, il y aura un accident tôt ou tard, mais il y a aura, à terme, un accident, c'est une certitude.

                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 . Évalué à 7.

                Mais le langage ne va pas te tirer dessus si tu ne lui demande pas.

                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 . Évalué à 8.

                  > (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...

                  À 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 (page perso) . Évalué à 4.

        J'aurais pas pris php comme exemple d'un langage plus sûr que le C :)
        • [^] # Re: J'y crois pas.

          Posté par . Évalué à 2.

          ouais vivement un server web modulaire en php ! ;)

          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 . Évalué à 4.

        C'est tout de même beaucoup plus facile de faire des grosses conneries dans certain langage: en C, typiquement.

        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 . Évalué à -1.

          > Les buffer overflow et autre injection de code s'est typique du C.

          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 . Évalué à 2.

            Quel rapport entre succès et sécurité ?

            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 (page perso) . Évalué à -1.

          >Les buffer overflow et autre injection de code s'est typique du C.

          Il faut le compiler avec StackGuard :)
  • # Sécurité ?

    Posté par (page perso) . Évalué à 9.

    Fichier ashd/src/sendfile.c (je suis tombé sur ce fichier en tentant de compiler le bousin)

    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 (page perso) . Évalué à 2.

      Je suis d'accord avec toi sur le fait que ce code est particulièrement laid, par une chose dans ton commentaire me fais tiquer :

      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 (page perso) . Évalué à -2.

        C'est vrai que j'ai tendance à plus faire du C++ que du C, et donc la pré-incrémentation a du sens. 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.

        À 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 . Évalué à 5.

          En gros pour justifier ta bafouille tu parles de C++ alors que tu critiques du code C, et après fais une jolie diversion qui n'a pas grand chose à voir avec la post-incrémentation (change ton i++ en i *=4 et c'est parreil).

          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 (page perso) . Évalué à -1.

            J'ai dit, à titre d'illustration. Parce que c'est plus simple de montrer une implémentation de operator++ que de parler d'assembleur.

            Ç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 . Évalué à 4.

              Ce genre d'optimisation cela reste du hack. Et c'est bien un boulot de compilateur.

              "La première sécurité est la liberté"

              • [^] # Re: Sécurité ?

                Posté par . Évalué à 5.

                Ça me rappelle des "demomakers" qui codaient en C comme ils codaient en assembleur (ils faisaient gaffe à écrire "x << 2" au lieu de "x * 4", etc.). À côté de ça, ils utilisaient des algos pourris de complexité quadratique...
        • [^] # Re: Sécurité ?

          Posté par . Évalué à 2.

          T const operator ++(typename const & target)

          Le deuxieme const semble de trop, non ?
          • [^] # Re: Sécurité ?

            Posté par (page perso) . Évalué à 2.

            J'ai surtout oublié de remplacer entièrement mon typename T par T. Par contre, le deuxième const dans quel sens ?
          • [^] # Re: Sécurité ?

            Posté par (page perso) . Évalué à 2.

            Quel boulet, j'ai oublié de virer le deuxième paramètre entièrement. Au temps pour moi.
            • [^] # Re: Sécurité ?

              Posté par . Évalué à 2.

              Où l'on voit que c'est super simple de surcharger un opérateur en C++.
              • [^] # Re: Sécurité ?

                Posté par (page perso) . Évalué à 2.

                C'est surtout que je ne connais pas tout les prototype de surcharge par cœur. Vu que c'est à utiliser avec parcimonie. Il n'y a vraiment que dans l'implémentation d'un itérateur que la surcharge des opérateurs d'incrémentations et de décrémentation (qui sont de toute façon particuliers) où ils sont utiles. Et puis bon, j'en écrit pas tout les jours des itérateurs :)
        • [^] # Re: Sécurité ?

          Posté par (page perso) . Évalué à 2.

          Il fallait lire
          // 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 (page perso) . Évalué à 4.

          C'est vrai que j'ai tendance à plus faire du C++ que du C, et donc la pré-incrémentation a du sens.

          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 (page perso) . Évalué à -1.

            En C++ on n e devrait utiliser que rarement l'incrémentation des entiers.

            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 . Évalué à 3.

              > 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.

              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 (page perso) . Évalué à -2.

                http://www.open-std.org/JTC1/SC22/WG14/www/standards (c'est un draft de C99, mais ils ne sont jamais loin du contenu qui tien lieu de standard, et c'est compatible avec les C précédents).

                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 . Évalué à 7.

                  Rien a voir, les cas que tu cites sont tres specfiques (i est situe plusieurs fois dans la meme expression), et la spec ne dit pas quel comportement avoir dans _ce cas precis_ (est-ce que le 2eme i reflete la valeur modifiee ou originale, ...)

                  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 . Évalué à 3.

                  Tu ne cites pas le paragraphe textuellement par ce que les gens se rendraient compte que tu racontes n'importe quoi ?

                  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 (page perso) . Évalué à 2.

                  Je ne sais pas ce que tu appelles « évaluation fainéante » mais si tu fais allusion aux opérateurs || et &&, dont seul le membre gauche est évalué quand il est vrai ou faux (respectivement), alors tu te trompes : le standard précise ce comportement explicitement.


                  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 (page perso) . Évalué à 2.

              En C++ on n e devrait utiliser que rarement l'incrémentation des entiers.

              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 . Évalué à -1.

                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.


                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 . Évalué à 4.

                  Mettons pdst=12 et psrc=42

                  > 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];

                  Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                • [^] # Re: Sécurité ?

                  Posté par (page perso) . Évalué à 3.

                  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.


                  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;


                  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 . Évalué à -2.

                Ton esprit a l'air aussi embrouillé que ton expression.
    • [^] # Re: Sécurité ?

      Posté par . Évalué à 1.

      > renvoyer l'adresse d'une variable locale c'est pas bien, et c'est encore pire quand elle est statique

      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 (page perso) . Évalué à 2.

        Le segfault n'est pas assuré, bien au contraire.

        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 . Évalué à 3.

      > Cependant, renvoyer l'adresse d'une variable locale c'est pas bien, et c'est encore pire quand elle est statique.

      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 . Évalué à 2.

        oups je voulais dire c'est l'un des intérêt d'une variable static, l'autre étant de pouvoir conserver des états, mais pose le même problème en cas d'exécution parallèles

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

        • [^] # Re: Sécurité ?

          Posté par (page perso) . Évalué à 3.

          Dans le sens où la fonction elle-même est static, il n'y a pas vraiment de possibilité pour quelqu'un qui n'a pas de visibilité dans la fonction elle-même de l'utiliser de manière concurrente (ou alors de manière indirecte mais alors j'ose espérer que la non-réentrance est documentée).

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re:Sécurité ?

        Posté par . Évalué à 1.

        > L'inconvénient c'est qu'on monopolise 1ko de ram, même si on s'en sert pas.

        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 . Évalué à 3.

          Non, la variable statique doit être dans une zone .bss. Elle ne prend pas de place dans le binaire, mais une fois qu'il est chargé, elle prend toute la place dès le début.

          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 000009a8
          0000000000000420 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 . Évalué à 2.

            Il faut remplacer le 1024 dans le code par SIZE, évidemment. (et ne pas exécuter la version test.1 avec 42 en argument)

            Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

        • [^] # Re: Re:Sécurité ?

          Posté par . Évalué à 2.

          Tu es sûr de toi ?
          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 . Évalué à 2.

            Pour l'allouer auto-magiquement à l'appel de la fonction, il y a éventuellement une solution, le compilateur pourrait faire comme pour les bibliothèques dynamiques (par contre, ça poserait de gros problèmes en cas d'appels concurrents à la fonction) :
            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 . Évalué à 2.

            Effectivement j'admets que je me suis planté (le « Il me semble » montrait mon
            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 . Évalué à 1.

              Faut pas confondre, en C++, l'initialisation de la variable par le constructeur et l'allocation mémoire nécessaire pour le stockage de la variable en question. Si les deux opérations se produisent généralement au meme endroit, ce n'est pas obligatoire.
            • [^] # Re: Re:Re:Sécurité ?

              Posté par (page perso) . Évalué à 2.

              j'imagine, toute variable statique n'est initialisée qu'au moment du premier appel (à vérifier néanmoins). Arrête d'imaginer et vérifie. Les variables static initialisées à autre chose que 0 vont dans la section data au lieu de BSS (comme indiqué par neologix et GLMF#2^7) :
              $ 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.2395

              pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: Sécurité ?

        Posté par . Évalué à 2.

        une variable static dans une fonction, c'est une variable global avec seulement une visibilité dans la dite fonction.
      • [^] # Re: Sécurité ?

        Posté par (page perso) . Évalué à 2.

        La variable locale statique n'a aucun intérêt, si ce n'est d'introduire des bogues avec des variables globales cachées.

        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 (page perso) . Évalué à 4.

          > 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.

          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 . Évalué à 3.

      Dans le dev embarqué, plusieurs return dans une même fonction ce n'est pas bien.

      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 (page perso) . Évalué à 3.

    C'est bien de renvoyer vers l'article Wikipédia mais quand il existe un document (en anglais) qui est quand même plus détaillé et un peu plus pro on peut s'en servir : http://marmaro.de/docs/studium/unix-phil/
    On peut aussi ne pas avoir connaissance de ce document alors j'en parle.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.