Journal Apple, le SSL les goto et les accolades

Posté par . Licence CC by-sa
Tags : aucun
30
23
fév.
2014

Apple a annonce une faille SSL. Le correctif a été publié pour iOS, il est en cours côté OS X. MacG nous en apprend plus sur cette faille.

http://www.macg.co/os-x/2014/02/ssl-une-faille-majeure-dans-ios-et-os-x-80069

La faille se situe au niveau de la vérification de l'identité du correspondant. Le code incriminé est le suivant:

static OSStatus

SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,

uint8_t *signature, UInt16 signatureLen)


OSStatus err;

...

if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)

goto fail;

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)

goto fail;

goto fail;

if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)

goto fail;

...


fail:

SSLFreeBuffer(&signedHashes);

SSLFreeBuffer(&hashCtx);

return err;

}

On peut voir que les 2 goto a la suite entraine une non vérification de tous les tests qui suivent pour retourner un élément non initiliase.

Si l'erreur semble basique, on peut se demander comment elle a pu passer jusqu'à l'utilisateur. Cette faille soulève pas mal de questions:

  • utilisation du goto
  • aucune accolade, toujours piegeux dans un code critique
  • analyse du code mort
  • vérification fonctionnelle

Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés chez Apple et que le code crade y est accepté.

  • # Something was horribly wrong with SSL/TLS in iOS

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

    • [^] # Re: Something was horribly wrong with SSL/TLS in iOS

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

      extern int f();
      int g() {
      int ret = 1;
      goto out;
      ret = f();
      out:
      return ret;
      }
      If I compile with -Wall (enable all warnings), neither GCC 4.8.2 or Clang 3.3 from Xcode make a peep about the dead code.

      ah ouais quand même… Et après on se fou de la gueule du compilo de Microsoft (qui lui met un "warning C4702: unreachable code")?

      (Thanks to Peter Nelson for pointing out the Clang does have -Wunreachable-code to warn about this, but it's not in -Wall.)

      Il y a de drôles de notions du mot "all" chez certains…


      Après, la critique sur le code d'Apple est facile, faire mieux sur des millions de lignes peut être plus difficile (hein Debian? ;-) )

      • [^] # Re: Something was horribly wrong with SSL/TLS in iOS

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

        Il y a de drôles de notions du mot "all" chez certains…

        -Wall n'a a jamais été tous les Warning, mais seulement This enables all the warnings about constructions that some users consider questionable, and that are easy to avoid (or modify to prevent the warning), even in conjunction with macros. En gros, il s'agit de mettre dedans toutes les warnings que tout le monde devrait suivre, pas tous les warnings existants. D'ailleurs, il y -Wextra pour en ajouter. Et Clang se voulant quasiment compatible avec GCC, c'est logique qu'il ne rajoute pas des warning dans les options existante de GCC.

        (hein Debian? ;-) )

        C'est justement le problème inverse, c'est pour que les outils d'analyse de code arrête de gueuler que le bug a été introduit.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Something was horribly wrong with SSL/TLS in iOS

          Posté par (page perso) . Évalué à 2. Dernière modification le 23/02/14 à 11:55.

          pas tous les warnings existants.

          ben… "all" quand même, c'est vachement trompeur.
          Pour info, chez Microsoft ce warning est dans /W4 (warnings that are recommended for production purposes + informational warnings) et bien évidement avec /Wall ("all" voulant dire "all" : all /W4 warnings and any other warnings).
          Bref, ça reste bizarre ce "all", un mot simple et un resultat qui ne correpsond pas au mot utilisé.

          D'ailleurs, il y -Wextra pour en ajouter.

          Je n'ai aucun warning avec -Wextra et ce code.
          $ more a.cpp
          extern int f();
          int g() {
          int ret = 1;
          goto out;
          ret = f();
          out:
          return ret;
          }
          int main()
          {
          return 0;
          }
          $ g++ -Wextra a.cpp
          $ g++ --version
          g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)

          C'est un peu bizarre quand même.

          C'est justement le problème inverse, c'est pour que les outils d'analyse de code arrête de gueuler que le bug a été introduit.

          Ce n'est pas faux.
          Mais je pointais du doigt la possibilité de faire des erreurs, pas le pourquoi (la chasse aux warnings ne devant pas non plus faire des bugs)

          • [^] # Re: Something was horribly wrong with SSL/TLS in iOS

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

            Je n'ai aucun warning avec -Wextra et ce code.

            C'est normal, il n'y a plus de -Wunreachable-code dans GCC

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Something was horribly wrong with SSL/TLS in iOS

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

              Ben… Ca ne te dérange pas plus que ça (et était une question implicite dans mes autres réactions)?
              Perso, je trouve ça assez génant, ce genre de warning permet d'éviter des erreurs d'étourderie (genre… Le sujet discuté), et suis content que des compilos implémentent ce genre de warning, comme quoi avoir plusieurs compilos est utile.

              • [^] # Re: Something was horribly wrong with SSL/TLS in iOS

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

                Si c'est gênant mais c'est clairement documenté. Si tu veux ce genre d'analyse, il faut utiliser d'autres outils.

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Something was horribly wrong with SSL/TLS in iOS

                Posté par . Évalué à 7.

                Pour info, l'explication du retrait de -Wunreachable-code

                • « -Wunreachable-code is seriously broken, I suggest to remove its implementation completely. » gcc-patches, novembre 2009
                • « The -Wunreachable-code has been removed, because it was unstable: it relied on the optimizer, and so different versions of gcc would warn about different code. » gcc-help, mai 2011
                • [^] # Re: Something was horribly wrong with SSL/TLS in iOS

                  Posté par . Évalué à 1.

                  Assez exceptionnel ce thread dans le deux poids deux mesures…

                  N'importe quel bon compilateur se devrait d'indiquer un warning dans ce cas avec les options habituelles de compilation, mais bon, comme c'est Sacro-Saint-GCC, tout est pardonné !

                  La rhétorique utilisée est particulièrement croustillante : GCC ne l'indique pas, c'est parce qu'il n'y a plus d'option pour le faire, et si il n'y a plus d'option, c'est parce qu'on l'a retirée car elle était buguée. Donc, encore un bug de moins dans GCC le compilateur fantastique… pas comme ces grosses merdes de produits Microsoft et Apple. CQFD !

                  • [^] # Re: Something was horribly wrong with SSL/TLS in iOS

                    Posté par . Évalué à 2.

                    Je ne peux pas juger des produits Microsoft vu que je ne les utilise pas. Pour ce qui concerne des produits Apple, llvm est connu comme un compilateur rapide pour compiler et aux messages d'erreur clairs. Plein de gens l'utilisent sous linux pour développer, avant de passer à gcc pour le binaire final, vu que les binaires produits par gcc sont plus fiables et plus rapides (voir : Intel Linux Graphics Developers No Longer Like LLVM Phoronix, 8 février 2014 ; GCC vs. LLVM Clang Is Mixed On The Ivy Bridge Extreme, Phoronix, 13 octobre 2013). Il n'y a pas deux poids et deux mesures, mais des applications différentes pour des compilateurs différents. (C'est juste un peu chiant de devoir faire des #ifdef pour les fonctionnalités pas disponibles dans l'un ou l'autre compilateur.)

  • # Le cas goto

    Posté par (page perso) . Évalué à 10. Dernière modification le 23/02/14 à 11:10.

    Pour gérer les erreurs, employer un goto n'est pas une si mauvaise idée que ça. J'avais gardé un lien sur le site kerneltrap (qui semble mort à l'heure ou j'écris ce commentaire), mais disponible en archive qui explique ça.

    Après ça n'explique le reste, il est clair que ce genre de code se doit de passer dans des tests automatiques.

    • [^] # Re: Le cas goto

      Posté par (page perso) . Évalué à 2. Dernière modification le 23/02/14 à 11:31.

      Oui, voir des goto dans des libs en pure code C a rien de choquant. C'est plus que commun pour la gestion des erreurs et spécialement dans du code un peu agé.

      Un simple grep sur le code de libcurl, pris au hasard donne 348 occurences de goto dans le code. La pluspart sont utilisées pour la gestion d'erreurs.

      Même si je n'approuve pas, je peux comprendre pourquoi certains continue de l'utiliser. Une gestion propre des erreurs en C sans redondance de code n'est pas forcement triviale.

      • [^] # Re: Le cas goto

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

        Oui, voir des goto dans des libs en pure code C a rien de choquant. C'est plus que commun pour la gestion des erreurs et spécialement dans du code un peu agé.

        Et pour les langages qui n'ont pas de goto (ou alors quand on l'interdit) on peut faire la même chose avec un bloc contenant des break.
        En C++ (sur du code Adobe) il y avait un pattern assez classique à base de

        bool ok = false;
        do {
        
          // bla bla bla
        
          if (/* comportement pas glop */) {
            break;
          }
        
          // bla bla
        
          ok = true;
        } while(false);
        
        if(!ok) {
          // traitement des cas en erreur
          return k_fail;
        }

        C'est pas le comportement classique qu'on voit aujourd'hui avec toutes ces exceptions, mais c'est un système qui n'est pas si mal que ça.

        • [^] # Re: Le cas goto

          Posté par . Évalué à 6.

          J'ai toujours rêvé d'avoir un truc genre try/catch mais local à une fonction, c'est-à-dire qu'on doit faire le catch au même endroit que le throw (donc pas de gestion d'exception). Je trouve que ça permettrait de se débarrasser presque définitivement des goto. Et en plus, ça serait plus simple à lire et à comprendre.

          • [^] # Re: Le cas goto

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

            J'ai un peu de mal à voir ton idée. Tu pourrais nous écrire un exemple de à quoi ça pourrait ressembler ?

            • [^] # Re: Le cas goto

              Posté par . Évalué à 2.

              Pour reprendre l'exemple de CrEv :

              try {
              
                // bla bla bla
              
                if (/* comportement pas glop */) {
                  throw;
                }
              
                // bla bla
              
              } catch {
                // traitement des cas en erreur
                return k_fail;
              }

              Et pour reprendre l'exemple du journal :

              static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen) {
              
              
              OSStatus err;
              
              // ...
              
              try {
              
                if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) {
                  throw;
                }
              
                if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) {
                  throw;
                }
              
                if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) {
                  throw;
                }
              
              } catch {
              }
              
              SSLFreeBuffer(&signedHashes);
              SSLFreeBuffer(&hashCtx);
              
              return err;
              }
              • [^] # Re: Le cas goto

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

                Perso, je n'ai quasiment jammais utilsié les exceptions en C++.
                Mais si je devais, le code ressemblerais plus à ça:

                /* Check that everything is Ok, and throw in case of error */
                static void SSLVerifySignedServerKeyExchange(/* ... */) {
                {
                   std::vector<...> signedHashes = ...;
                   std::unique_ptr<...> hashCtx = ...;
                   //...
                   SSLHashSHA1.update(hashCtx, serverRandom));
                   SSLHashSHA1.update(hashCtx, signedParams));
                   SSLHashSHA1.final(hashCtx, hashOut));
                }

                Le problème des exceptions c'est que c'est que ça a un coût (en terme de taille du binaire par example). Pas mal de projets sont compilé avec -fno-rtti.

                Sans exception le C++ ressemble à ça:

                static OSStatus SSLVerifySignedServerKeyExchange(/* ... */) {
                  std::vector<...> signedHashes = ...;
                  std::unique_ptr<...> hashCtx = ...;
                  OSStatus err;
                
                  if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) 
                     return err;
                
                  if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
                     return err;
                
                  if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
                    return err;
                
                  return OSStatus::Success:
                  // no cleaning necessary
                }
                • [^] # Re: Le cas goto

                  Posté par . Évalué à 2.

                  Perso, je n'ai quasiment jammais utilsié les exceptions en C++.

                  Moi non plus, mais dans le cas que je décris, c'est juste un goto déguisé, comme peuvent l'être les break et autre continue. Donc, pas d'exception (au sens normal du terme) à gérer. Mais c'est vrai qu'il faudrait peut-être une autre syntaxe pour différencier des vrais exceptions.

                  • [^] # Re: Le cas goto

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

                    Mais c'est vrai qu'il faudrait peut-être une autre syntaxe pour différencier des vrais exceptions.

                    Pourquoi pas break ou goto ? :-)

                    • [^] # Re: Le cas goto

                      Posté par . Évalué à 1. Dernière modification le 24/02/14 à 10:43.

                      Pas break qui sert déjà à trop de choses (imagine que tu veuilles lancer une "exception locale" comme je décris au milieu d'une boucle, et bien ça ne marchera pas). Et goto, ben heu, voilà quoi.

                      Retrouver une syntaxe proche des exceptions ne me choquerait pas, mais ça ne serait pas possible pour ne pas casser la "compatibilité" entre C et C++. Si je devais vraiment me creuser la tête, je proposerais peut-être check (pour try), fail (pour catch), discard (pour throw).

                      • [^] # Re: Le cas goto

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

                        Et goto, ben heu, voilà quoi.

                        Eh voilà quoi ? Quel est le problème avec goto ?

                        Pour rappel, le fameux article de Dijkstra Go To Statement Considered Harmful date de 1965, avant la création du C, a une époque où GOTO était utilisé à la place de boucle ou de fonctions.

                        En BASIC, il n'y avais pas d'accolades pour délimiter les IFs, donc on avais droit qu'a mettre un goto après

                        18500 IF  n = 0  THEN GOTO 19300

                        C'est ce GOTO là qui est critiqué, car il ne permet pas de facilement lire un programme. Le goto fail; au contraire facilite la lecture du programme.

                        • [^] # Re: Le cas goto

                          Posté par . Évalué à 4.

                          Ha mais on peut continuer à critiquer le goto. Je suis tout à fait d'accord que son usage se justifie dans quelques cas bien identifié (grosso modo, les codes au cheminement complexe, comme les cas d'erreur du journal ou encore les parseurs), mais dans tous les autres cas, on a inventé des structures pour cacher les goto et avoir une sûreté supplémentaire, généralement parce qu'on a une portée (scope) différente et donc, on a des garanties sur la durée de vie des variables et tout ce genre de chose.

                          Pour moi, on pourrait continuer à inventer des structures pour les cas restants. Le goto fait partie d'une ancienne boîte à outils qui n'est plus guère compatible avec les techniques modernes. Si on prend juste le fait de déclarer les variables au plus près de leur première utilisation, c'est compliqué avec des goto, parce qu'on n'a pas le droit de passer par dessus une déclaration de variable.

                    • [^] # Re: Le cas goto

                      Posté par . Évalué à 2.

                      Là où je m'interroge avec goto en C++, c'est au niveau du détricotage de la pile, appel des destructeurs, tout ça. Est-ce que l'utilisation de goto ne peut pas mener à des comportements indéfinis voire des failles dans la gestion de la mémoire ? Est-ce vraiment compatible et cohérent avec le reste du langage ?

                      J'avoue je fais un blocage sur C++, je l'évite comme la peste, et j'ai donc la flemme de chercher des réponse par moi-même :-).

                      • [^] # Re: Le cas goto

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

                        Les destructeurs sont exécutés quand tu quittes la scope d'un objet. (que ce soit avec break, return ou goto)
                        Et il n'est pas possible de faire un goto qui contourne l'initialisation de variable avec un constructeur (erreur de compilation si tu essayes)

                        http://stackoverflow.com/questions/7334952/will-using-goto-leak-variables

                        • [^] # Re: Le cas goto

                          Posté par . Évalué à 1.

                          Intéressant. Du coup je déteste un peu moins C++ :-)

                      • [^] # Re: Le cas goto

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

                        goto est pertinent en C pour collecter les ressources en cas de problèmes.
                        Pour gérer les ressources, en C++ on part sur le RAII. On n'a plus besoin d'imposer une approche SESE (Single Entry Single Exit) où l'on factorise la collecte des ressources (cas nominaux et cas exceptionnels/erreurs).

                        A partir du moment où les ressources sont surveillées, et que l'on n'est plus dans du SESE only, libre à nous de remonter des exceptions (préférables car l'impact est nul sur les chemins nominaux avec les compilateurs d'aujourd'hui, et que les erreurs ne peuvent pas être ignorées, et qu'en cas de soucis, les perfs on s'en fout) ou de continuer à remonter les codes d'erreurs à la main (ce qui va impacter les performances vu que l'on va avoir un if toutes les 2-3 lignes pour tester chaque appel de fonction et remonter en cas de soucis—enfin, si on veut écrire un code robuste).

                        De la lecture sur ces sujets: http://alexandre-laurent.developpez.com/cpp/retour-fonctions-ou-exceptions/

                • [^] # '-fno-rtti' et exceptions.

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

                  De mémoire, pour ce que j'en ai compris, -fno-rtti ne désactive pas les exceptions. Les d'informations relevant du mécanisme de runtime type identification nécessitées par ces dernières étant de toute façon générées, -fno-rtti ou pas.

                  Freelance en ingénierie informatique.

                  • [^] # Re: '-fno-rtti' et exceptions.

                    Posté par (page perso) . Évalué à 1. Dernière modification le 23/02/14 à 21:53.

                    Et si l'on veut absolument ne pas utiliser les exceptions C++ (ou que l'on veut disposer de quelque chose de comparable en C), on peut utiliser la bibliothèque standard setjmp pour les simuler, mais j'ignore si c'est rentable par rapport aux exceptions en terme de coûts…

                    Freelance en ingénierie informatique.

                    • [^] # Re: '-fno-rtti' et exceptions.

                      Posté par . Évalué à 2.

                      Je vois pas trop comment marche les exceptions en C++, mais setjmp et longjmp sont imbattables, ils ne font que quelques dizaines de store pour l'un et load pour l'autre.

                      Please do not feed the trolls

                      • [^] # Re: '-fno-rtti' et exceptions.

                        Posté par . Évalué à 10.

                        Sur la plupart des architectures, les exceptions sont gratuites au sens où il n'y a pas de code supplémentaire qui est exécuté si aucune exception n'est levée. Et pour les autres, ça utilise setjmp/longjmp donc je dirais plutôt que les exceptions sont imbattables en C++.

                  • [^] # Re: '-fno-rtti' et exceptions.

                    Posté par . Évalué à 5.

                    Je pense qu'il voulait dire -fno-exceptions qui supprime toute la gestion des exceptions. Le -fno-rtti empêche de faire des dynamic_cast (entre autre).

                  • [^] # Re: '-fno-rtti' et exceptions.

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

                    Ta mémoire est meilleure que la mienne :-)
                    J'avais en tête que -fno-rtti désactive les exception. Mais gcc et clang génèrent les RTTI (run-time type information) pour les classes utilisées dans les exceptions même si -fno-rtti est activé. [url]
                    Mais bon, les projets auquel je pense sont aussi compilés avec -fno-exceptions.

                • [^] # Re: Le cas goto

                  Posté par . Évalué à -1. Dernière modification le 24/02/14 à 21:29.

                  C'est moi qui ne comprend pas bien ? Ou ton code

                  static OSStatus SSLVerifySignedServerKeyExchange(/* ... */) {
                    std::vector<...> signedHashes = ...;
                    std::unique_ptr<...> hashCtx = ...;
                    OSStatus err;
                  
                    if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) 
                       return err;
                  
                    if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
                       return err;
                  
                    if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
                      return err;
                  
                    return OSStatus::Success:
                    // no cleaning necessary
                  }

                  fait un beau leak memory ?
                  Il me semble qu'il manque les

                  SSLFreeBuffer(&signedHashes);
                  SSLFreeBuffer(&hashCtx);

                  En cas d'erreur justement.
                  Car c'est bien là la seule utilité du goto dans le code initial ou du catch zarbi de rewind c'est vider la mémoire allouée si quelque chose ne ce passe pas bien.

                  kentoc'h mervel eget bezan saotred

                  • [^] # Re: Le cas goto

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

                    C'est la magie du C++. Regarde au début de la fonction : on a affaire a des vector et unique_ptr qui libèrent automatiquement la mémoire.

                    • [^] # Re: Le cas goto

                      Posté par . Évalué à 3.

                      Ok génial encore un truc que je ne connaissais pas en C++.

                      C'est moi qui ne comprend pas bien ?

                      Donc c'était bien ça, je ne comprenais pas bien ! :-D

                      kentoc'h mervel eget bezan saotred

          • [^] # Re: Le cas goto

            Posté par . Évalué à 1.

            Personnellement je pense que les exceptions avec la gestion du scope est ce qu'il y a de ´moins pire´ cf http://dlang.org/exception-safe.html

        • [^] # Re: Le cas goto

          Posté par . Évalué à -4.

          on peut faire la même chose avec un bloc contenant des break.

          on peut même faire encore plus poussé pour la gestion des erreurs:

          int err = 1;
          do {
           if (setup1_failed())
              break;
           err++;
           if (setup2_failed())
              break;
           err++;
           // etc.. then finally:
           err = 0; // all good
          while (0);
          
          switch (err) {
           case 0: return 0; // ou break
           case X: clean_setup"X-1"();  
           // etc
           case 3: clean_setup2();
           case 2: clean_setup1();
           case 1: break;
           default: // "unhandled" err
          }
          return err;
          • [^] # Re: Le cas goto

            Posté par (page perso) . Évalué à 9. Dernière modification le 23/02/14 à 12:42.

            on peut même faire encore plus poussé pour la gestion des erreurs

            Oui enfin, autant en C ce genre de chose est acceptable. Autant en C++ ça l'est beaucoup moins.

            Le C++ gère les scopes, et le traitement d'action différées en sortant d'un bloc peut être fait de manière safe ET performante par un Scope Guard object( http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Scope_Guard )

            1- Ça a l'avantage d'être "exception safe" et de nettoyer correctement l'état courant même si une exception est levée dans un autre scope.
            2- Ça evite toute erreur eventuelle "d'oublie" si un autre point de retour est ajouté dans le fonction.
            3 - c'est beaucoup plus propre et concis, surtout en C++11 ou avec boost ( BOOST_SCOPE_EXIT http://www.boost.org/doc/libs/1_54_0/libs/scope_exit/doc/html/scope_exit/alternatives.html )

            Mettre des patterns à grand coup de loop et break an C++, c'est bien souvent ne pas connaitre C++.

            • [^] # Re: Le cas goto

              Posté par . Évalué à 2.

              Oui enfin, autant en C ce genre de chose est acceptable. Autant en C++ ça l'est beaucoup moins.

              oui mais c'est bien pour du C que je donnais l'exemple ;)
              J'aurais pu préciser mais je pensais que c'était explicite.

              • [^] # Re: Le cas goto

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

                Yoi non mais CrEv oui

                En C++ (sur du code Adobe) il y avait un pattern assez classique à base de

            • [^] # Re: Le cas goto

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

              Mettre des patterns à grand coup de loop et break an C++, c'est bien souvent ne pas connaitre C++.

              Pourquoi ? Je trouve quand même ça plutôt lisible et simple à comprendre.
              Les liens que tu donnes m'ont pas vraiment donné envie trop verbeux, trop complexes ;-) Mais bon, je creuserai un peu plus, ça a l'air intéressant.

              • [^] # Re: Le cas goto

                Posté par . Évalué à 4.

                Le RAII est une base du C++ tout de même. Les concepts sont les même.

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: Le cas goto

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

                  Pas de problème avec ça.
                  Mais en général ça ne se limite pas à de la libération de ressource. Il peut y avoir plein de choses à traiter sur le cas d'erreur, du log, des traitements spécifiques, etc.
                  Et là quand je vois ça (http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Scope_Guard) ou le ON_BLOCK_EXIT je me dis que c'est bien lourd pour un truc qui se fait facilement avec un do et un break, même si c'est pas la "bonne" façon de faire.

                  • [^] # Re: Le cas goto

                    Posté par . Évalué à 10.

                    Et là quand je vois ça (http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Scope_Guard) ou le ON_BLOCK_EXIT je me dis que c'est bien lourd pour un truc qui se fait facilement avec un do et un break, même si c'est pas la "bonne" façon de faire.

                    Moi c'est quand je vois le ce code là :

                    https://linuxfr.org/users/flagos/journaux/apple-le-ssl-les-goto-et-les-accolades#comment-1522135

                    Que j'ai peur.

                    • On perd énormément en lisibilité. On fait un gros hack sale avec une boucle pour contourner une limitation du langage.
                    • On perd en maintenabilité. Si tu as une boucle dans ton traitement ce n'est plus un simple break qu'il faut utiliser. On utilise des cas particuliers qui doivent être maintenu (le while(0)). Tu peut facilement avoir un outil d'analyse statique qui t'explique que ta boucle ne sert à rien car la condition est toujours fausse…

                    En effet c'est simple dans le sens ou on fait le truc avec sa bite et son couteau, mais ça cache une complexité à l'usage qui n'est pas à négliger à mon avis. Je suis d'accord que le ScopeGuard est loin d'être parfait parce qu'il a tendance à séparer dans 2 endroits trop distincts le code et la gestion d'erreur, de plus je ne sais pas si tu n'arrive pas facilement à des undefined behaviour en cas par exemple d'exception dans le destructeur.

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: Le cas goto

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

                      Moi c'est quand je vois le ce code là  que j'ai peur.

                      là je suis d'accord, trop complexe pour pas grand chose.
                      Si je peux je rechercherais bien un vrai exemple parce que justement c'était une solution simple, claire et lisible.

                      ça cache une complexité à l'usage

                      L'exemple que tu prend peut-être, mais la version simple non.

                      il a tendance à séparer dans 2 endroits trop distincts le code et la gestion d'erreur

                      Exactement, et je trouve que ça devient justement peu lisible. Surtout si tu veux faire une gestion d'erreur dans plusieurs méthodes tu fais comment ? Combien de scope guard il va falloir implémenter ?

                      • [^] # Re: Le cas goto

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

                        Exactement, et je trouve que ça devient justement peu lisible. Surtout si tu veux faire une gestion d'erreur dans plusieurs méthodes tu fais comment ? Combien de scope guard il va falloir implémenter ?

                        Tu n'en fait qu'un en template ou tu utilises un lambda.

                        Mais le scope guard ne sert pas directement à reporter des erreurs, le scope guard te permet de gérer proprement le nettoyage des ressources (les SSL_clean* dans l'example du dessus. Encore mieux, il te permet de garantir que tes ressources seront dés allouées dans l'ordre inverse où elles ont été allouées… te permettant justement de "Juste" retourner ton erreur sans avoir à te préoccuper de désallouer/nettoyer quoi que ce soit.

                        • [^] # Re: Le cas goto

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

                          Mais le scope guard ne sert pas directement à reporter des erreurs, le scope guard te permet de gérer proprement le nettoyage des ressources

                          Oui, et c'est aussi ce qui fait que ce n'est pas totalement comparable (ni ne peut vraiment remplacer) la solution à coup de do while(false) et break.
                          Le scope guard gère la libération des ressources, le do while sert à faciliter le traitement des erreurs.

                          Mais ça reste intéressant ;-)

          • [^] # Re: Le cas goto

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

            Est-ce vraiment plus clair / extensible que l'utilisation de goto ?

            • [^] # Re: Le cas goto

              Posté par . Évalué à 1.

              du tout. Pour moi c'est quasi exactement équivalent, modulo l'utilisation de la variable err. (Personnellement je préfère la version avec goto pour ces cas là.)
              C'était pour montrer une manière équivalente, mais sans goto (directement visible) donc.

              • [^] # Re: Le cas goto

                Posté par . Évalué à -3.

                Surtout que la gestion des exceptions en c++, c'est loin d'être gratuit.

                • [^] # Re: Le cas goto

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

                  Mais vu que comme leur nom l'indique, ce sont des exceptions, on se fout un peu de son prix tant que le prix lors d'un fonctionnement normal est rapide.

                • [^] # Re: Le cas goto

                  Posté par . Évalué à 3.

                  Il faut voir tes objectifs. Le coût d'une exception peut être bien faible fasse à une perte de lisibilité du code. C'est un choix à faire.

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: Le cas goto

                  Posté par . Évalué à 3.

                  Surtout que la gestion des exceptions en c++, c'est loin d'être gratuit.

                  Tout dépend de ce que tu appelles gratuit. Si c'est à l'exécution, si, c'est gratuit sur pas mal d'architecture. Si tu parles en terme de maintenance, c'est pas pire qu'autre chose et parfois, c'est plus simple (dans le cas de parser par exemple, où on peut arrêter à n'importe quel moment).

          • [^] # Re: Le cas goto

            Posté par . Évalué à 1.

            Juste une question, à quoi diable sert cette boucle ou l'on ne passe de toute façon qu'une seule fois?

            Si c'est pour le scope, autant juste mettre les accolades, sans boucle, ça revient au même, sauf qu'au moins, le WTF est plus simple à détecter lors d'une lecture rapide (what? des accolades sans instruction conditionnelle?) et l'intérêt de ces accolades plus évident pour quelqu'un avec une connaissance moyenne du C et/ou C++ ( ah, ça doit être pour générer un scope artificiel, et donc nettoyer les variables! ).

            Personnellement, ça m'arrive pour isoler des blocs de code que je sais que je ne réutiliserais pas ailleurs (donc les mettre dans un fonction séparée est inutile voire un remède pire que le mal), et qui utilisent des variables/objets coûteux qui ne sont utilisés réellement que lors de la moitié de la fonction, ainsi que pour réutiliser des variables bateau mal nommées ( genre it pour les itérateurs ).

            • [^] # Re: Le cas goto

              Posté par . Évalué à 8.

              Ca sert a pouvoir utiliser le mot break , qui fait office de goto

              • [^] # Re: Le cas goto

                Posté par . Évalué à 2.

                Oh… pas faux. Merci, je penserai peut-être à utiliser ce genre d'astuce un jour du coup, si j'ai à nouveau recours au C.

              • [^] # Re: Le cas goto

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

                Oui c'est uniquement pour cette raison.
                C'est sur que si {} formait un bloc dans lequel on peut placer un break ça serait plus cool :-)

        • [^] # Re: Le cas goto

          Posté par . Évalué à 3.

          J'adore cette manière de raisonner :
          « - Chef ! Chef ! Voici les dernières statistique des accidents sur le chantier : l'utilisation du marteau a provoqué 5% d'accidents, alors que celui de la clef anglaise, seulement 0,6%.
          - J'ai une super idée (normal, je suis chef) : interdisons aux ouvriers de planter des clous avec un marteau et forçons les à le faire avec une clef anglaise !
          - Vous êtes un génie, chef ! »

          • [^] # Re: Le cas goto

            Posté par . Évalué à 1.

            "Great programmers write baby code" ?

          • [^] # Re: Le cas goto

            Posté par . Évalué à 2.

            « - Chef ! Chef ! Voici les dernières statistique des accidents sur le chantier : l'utilisation du marteau a provoqué 5% d'accidents, alors que celui de la clef anglaise, seulement 0,6%.
            - Pourquoi ils utilisent un marteau ? Si c'est pour planter des clous le pistolet à clous est moins dangereux (note pour ceux qui regarde les films hollywoodiens : un pistolet à clou a des sécurité pour ne pas planter de clous s'il n'est pas appuyer contre un mur) »

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Manque un warning "indentation"

    Posté par (page perso) . Évalué à 9. Dernière modification le 23/02/14 à 11:46.

    Beaucoup de bugs pourrait être évités avec un warning/erreur qui vérifie la consistance de l'indentation, et c'est bien plus simple à implémenter qu'un outil qui vérifie le code mort. Ici il y a un goto qui n'est pas correctement indenté.

    Cela pourrait aussi sauver le cas horrible de :

    for/if/while(...)      ;
       // block toujours executé
    

    C'est le débat python versus le reste du monde et l'indentation significative qui ressort ;)

    (edit: toutes mes excuses, c'est le débat du second lien)

    • [^] # Re: Manque un warning "indentation"

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

      Ou simplement passer par une étape de "respect" de styleguide.

      Le pire dans le genre c'est quand j'ai vu un code du genre :

      // méthode à 13 paramètres
      
      // bla bla
      
      for(myIntVectorIterator = myIntVector.begin(); myIntVectorIterator != myIntVector.end(); myIntVectorIterator++) if(plop) {
        // un bloc bien long
        //...
        //...
        //...
        //...
      } else {
        //...
        //...
      }

      La première fois lorsque je suis arrivé sur le else j'ai failli vomir.

      D'ailleurs en python ça aurait donné quoi ? Une double indentation ? Juste impossible ?

      • [^] # Re: Manque un warning "indentation"

        Posté par (page perso) . Évalué à 1. Dernière modification le 23/02/14 à 13:23.

        Pourquoi ça ne pourrait pas être possible?

        for myvalue in mylist:
            if plop:
                # Code bien long...
            else:
                # ...
        

        Ou alors j'ai pas compris ta question?

        • [^] # Re: Manque un warning "indentation"

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

          Dans l'exemple le truc c'est qu'il y a un for (bien long) suivi, sur la même ligne et sans accolades d'un if.
          Donc en général on ne lit pas le if (trop long à droite), on commence à descendre le contenu sous 1 niveau d'indentation jusqu'à tomber sur un else et non l'accolade fermante du for.

          Et je me demandais juste si c'était possible en python d'avoir le for et le if sur la même ligne et le contenu du if avec un seul niveau d'indentation ou non (ce qui est super crade).

          • [^] # Re: Manque un warning "indentation"

            Posté par . Évalué à 3.

            Non, ce n'est pas possible :

            >>> for x in y: if x: pass
              File "<stdin>", line 1
                for x in y: if x: pass
                             ^
            SyntaxError: invalid syntax
            
        • [^] # Re: Manque un warning "indentation"

          Posté par . Évalué à 2.

          On peut avoir le même problème en python. else: étant un début de bloc valide à la suite d'un for. Il suffit juste d'oublier un tab. On aurait donc :

          for myvalue in mylist:
              if plop:
                  # Code bien long...
          else:
              # ...
          

          On peut d'ailleurs reproduire un comportement comme le goto avec break. Ce qui est pas mal dans le cas du traitement d'une liste.

          for i in list:
              if err1:
                  break;
              if err2:
                  break;
              if err3:
                  break;
              # traitement normal
          else:
              # traitement erreur
          
          • [^] # Re: Manque un warning "indentation"

            Posté par . Évalué à 5.

            C'est une des raisons pour lesquelles je n'aime pas trop Python : ce genre de problème m'est arrivé plusieurs fois suite à des suppression ou ajouts de blocs dans le code. Là ou un langage classique m'aurait sorti qu'il manque une } ou un end, Python a bien compilé/exécuté le code et j'ai mis des heures à trouver le problème.

          • [^] # Re: Manque un warning "indentation"

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

            Il y a un problème avec ton 2ème exemple. On rentre dans le bloc else d'un for (ou d'un while) à la fin de l'itération, sauf si on est sorti avec un break justement. Ton bloc else ne peux donc pas être le traitement d'erreur tel que présenté.

    • [^] # Re: Manque un warning "indentation"

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

      C'est le débat python versus le reste du monde et l'indentation significative qui ressort ;)

      Le Haskell aussi utilise l'indentation significative si je ne m'abuse.

      Opera le fait depuis 10 ans.

    • [^] # Re: Manque un warning "indentation"

      Posté par . Évalué à 1.

      Si tu aimes ce genre de choses, je te suggère l'utilisation conjointe de astyle et de diff dans un script, avec un return -1 si le diff détecte une différence. Script collé dans ton outils favori de compilation. En plus ça ne gérera pas que l'indentation ( en fonction des paramètres d'astyle ).

      Personnellement, j'aime avoir une indentation à mon goût et unifiée, mais comme toutes les règles ont des exceptions, il m'arrive de violer mes propres règles. Un warning à chaque fois m'emmerderait plus qu'autre chose. La seule option valable dans cette situation, c'est un -Wunreachable-code, code déjà dit. D'ailleurs, je le pensais inclus dans -Wall… m'en vais l'ajouter à tous mes CMakeLists.txt du coup. Merci à celui qui à souligné cette absence.

    • [^] # Re: Manque un warning "indentation"

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

      L'autre possibilité, c'est d'utiliser un langage qui interdit l'absence de délimiteur de bloc.
      Pour moi, ça a toujours été une hérésie que de rendre les accolades facultatives.
      Du coup, je mets toujours des accolades

  • # Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés chez Apple…

    Posté par . Évalué à 3.

    …et que le code crade y est accepté.

    Non mais mouarf, tu es un vrai [:metaExpert] toi non ?

    • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

      Posté par . Évalué à 8.

      Justement non. Et c'est ce qui me choque. Je suis pas expert mais rien que des bonnes pratiques de base aurait du détecter ce souci. Pratiques que l'on applique par ailleurs sur du code beaucoup moins sensible.

      Donc oui, je réitère, cette faille est révélatrice: ce n'est pas qu'un problème d'étourderie, c'est un manque de méthode.

      • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

        Posté par (page perso) . Évalué à -1. Dernière modification le 23/02/14 à 15:00.

        Ca manque de cours de religion…
        Que celui qui n'a jamais péché jette la première pierre !

        Après, on se demande pourquoi pas mal de gens font du closed source même quand il ne font aucun usage commercial, ce commentaire est révélateur des gens qui ont la critique facile et qui coupent pas mal d'envies de montrer du code.

        Pour jouer : montre-nous quelques milliers de lignes de code de ton cru, on pourra te descendre de la même manière que tu le fais sur les autres.

        • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

          Posté par . Évalué à 10.

          La question n'est pas de faire des bêtises mais précisément d'avoir des méthodes systématiques (outils d'analyse ou revues de code, par exemple) qui évitent à ces bêtises de se retrouver en production. Ce qui, dans le cadre du coeur de business d'une multinationale extrêmement puissante, est inexcusable.

          En revenir à "tout le monde fait des erreurs" et "montre-nous ton code", c'est totalement à côté de la plaque.

          (le même genre de bêtise systématique, mais dans un projet communautaire, est la fameuse bourde de Rasmus Lerdorf : http://www.reddit.com/r/programming/comments/jsudd/you_see_rasmus_lerdorf_creator_of_php_wrecking/
          )

          • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

            Posté par (page perso) . Évalué à 4. Dernière modification le 23/02/14 à 15:59.

            qui évitent à ces bêtises de se retrouver en production. Ce qui, dans le cadre du coeur de business d'une multinationale extrêmement puissante, est inexcusable.

            C'est quand même étonnant que quand il s'agit de Debian (par exemple, remplacer Debian par tout autre projet adoré par un certain nombre de personne squattant les forums), il y a plus rarement ce genre d'attaque. Par contre si il s'agit de Ubuntu, PHP, Apple et quelques autres produits haï par ces mêmes personnes, toute erreur devient rapidement inexcusable.

            Perso, je trouve que si les exemples donnés sont inexcusables, il n'y a pas de mots assez forts en français pour l'erreur de Debian (qui concernait l'accès à n'importe quelle machine vu que SSH est installé par défaut quasiment partout) et que tout le monde aurait dû quitter Debian tellement la fautre est pire qu'inexcusable et ça n'aurait jamais oh grand jamais dû arriver et ça aurait dû casser toute confiance dans le projet. (multinationale ou pas, on s'en fout ça n'a rien à voir avec le sujet discuté et ne sert qu'à chercher à excuser ceux qu'on aime avec tout ce qui peut passer).

            2 poids, 2 mesures.

            • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

              Posté par . Évalué à 9.

              Tu en fais une affaire personnelle, je vois pas ce qu'il y a de personnel là dedans. Oui, Debian a et devrait avoir plus d'outils pour attraper les erreurs. Mais il y a énormément d'acteurs dans une distributions Linux qui sont pas forcément coordonnés et mettre ce genre d'outils en place dans un contexte pareil n'est évidemment pas trivial.

              Là contrairement à Debian qui est transparente dans son organisation on est face à une boîte noire question organisation, je crois qu'on est en droit de se demander comment ce code à pu passer en prod sans être passé par un outil d'analyse statique ou sans que l'erreur qu'il a retourné soit traîtée correctement.

              On sait tous que l'erreur soit humaine, c'est un peu pour ça qu'on attend qu'elle soit rattrapée derrière dans un géant du logiciel depuis tant d'année … l'exception ne doit pas remonter si haut.

              • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                Posté par . Évalué à 5.

                Là contrairement à Debian qui est transparente dans son organisation on est face à une boîte noire question organisation, je crois qu'on est en droit de se demander comment ce code à pu passer en prod sans être passé par un outil d'analyse statique ou sans que l'erreur qu'il a retourné soit traîtée correctement.

                Alors que pour Debian on sait pourquoi elle est passée, qu'il n'y a pas d'analyse statique, donc on a pas à se le demander, c'est ça ? Le truc simple, totalement trivial, qu'Apple ne fait pas, Debian ne le fait pas non plus, il s'en approche un peu avec le travail de Sylvestre Ledru, mais on est pas encore dans les analyses systématiques dont il est questions plus haut. Et je ne suis pas sûr que le travail de Sylvestre aurait permis d'éviter la fameuse erreur de Debian. Ça fait des années que ça a eu lieu et on a tout juste un début de solution, pour un problème qui semble trivial à certains plus haut…

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                  Posté par . Évalué à 3.

                  Toi t'as oublié le début de mon message.

                  évidemment l'analyse statique a ses inconvénients genre on peut pas tout prévoir et il y a des faux positifs, je suis pas sur qu'il y ait un warning genre "fonction constante inutile" qui aurait pu attraper l'erreur de Debian, mais dans ce cas là un "warning : unreachable code" je m'en suis déja pris, et ça date pas d'hier. Avoir une politique d'entreprise genre "on fait pas passer de code avec des warnings en prod" (sauf dans des cas très particuliers) me parait pas idiot dans une boîte de cette taille.

                  Ça me fait penser à ces bugs qui reviennent de temps en temps genre au changement d'année t'as toujours un équipement qui plante à cause d'un cas foireux de changement d'années … wtf les gars, vous avez encore pas testé correctement ce code des dates qu'on sait que ça va foirer et que c'est un nid à bug quand on le réimplémente à l'arrache ? À force faut responsabiliser un peu, ça devrait plus arriver.

                • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

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

                  Alors que pour Debian on sait pourquoi elle est passée, qu'il n'y a pas d'analyse statique

                  Si on parle de la même faille, le problème est justement qu'il y a eu analyse (dynamique) avec valgrind et le patch qui corrigeait les warnings a introduit la faille.

                  Les outils d'analyse (statique ou dynamique) aident, mais ne sont pas non plus un remède miracle. Ils ont des faux positifs et des faux négatifs.

                • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                  Posté par . Évalué à 3.

                  L'enorme difference entre Debian et Apple se situe essentiellement dans le compte en banque et je trouve tres facile et tres tres petit de venir se foutre de la gueule de personne dediant une partie de leur temps libre a developper et packager un OS et tout en tas de logicile libre et gratuit et de defendre une boite qui a des milliards en caisse et qui pourrait donc tres facilement payer des centaines de developpeurs pour verifier des bouts de code aussi critique que SSL…

                  • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

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

                    compte en banque (…) leur temps libre

                    On parle de sécurité. Ces différences n'ont rien à faire dans la discussion, si ce n'est faire la démonstration que le sgens cherchent n'importe quelle excuse hors sujet pour pardonner plus facilement à ceux qu'ils aiment sans s'interresser le moins du monde à avoir de l'objectivité dans la critique sur le sujet discuté.

                    • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                      Posté par . Évalué à 9.

                      On parle de sécurité.

                      Ca je suis entièrement avec toi. Il est inacceptable de publier une lib censé implémenter du SSL si ce n'est pas fait sérieusement. Si on a pas le budget ou les connaissances pour le faire sérieusement, on ne le fait pas. Et cela vaut pour Apple comme pour Debian.

                      Dans le cas d'Apple, le sentiment que ca me donne est qu'il n'y a derrière aucun coding-rule, aucune relecture, aucune vérification sérieuse, aucune analyse de code. Rien. Le pissage de code et c'est envoyé cash à l'utilisateur. La merde est arrivée alors que c'est le flow normal de travail et que rien ne pouvait la filtrer. Ca n'est pas correct, c'est de la responsabilité d'Apple, car comme tu dis, "On parle de sécurité".

                      Dans le cas de Debian, ce qui n'est pas normal, c'est que le mainteneur est intervenu hors workflow du projet. A mon sens, une distrib n'a pas a faire des patchs à chaud sur ce genre de libs. Mais je suppose (du moins j'espère !) qu'un tel flow existe au sein du projet, même si c'est fait par des bénévoles ! Après peut-être faudrait il que les projets fournissent une suite de tests pour que les mainteneurs puissent vérifier que rien n'a rien régressé au moment du packaging ?

                      • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

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

                        Après peut-être faudrait il que les projets fournissent une suite de tests pour que les mainteneurs puissent vérifier que rien n'a rien régressé au moment du packaging ?

                        Ça tombe bien, c’est que font les développeurs de OpenSSL. Le mainteneur n’a qu’à faire make test après la compilation pour vérifier que le patch qu’il a cru bon d’appliquer sur les sources n’a pas cassé trop de choses.

                        Dans le cas de la faille qui nous intéresse, toutefois :
                        – je n’ai aucune idée si Kurt Roeckx a testé son patch ainsi, ni plus généralement si cela fait partie du « workflow » Debian de systématiquement exécuter ces suites de test quand elles existent ;
                        – même s’il l’a fait, je ne suis pas sûr que ces tests soient capables de détecter un problème aussi subtil que celui introduit par son patch : comment teste-t-on qu’un générateur de nombres aléatoires produit bien des nombres « suffisamment » aléatoires ?

                        • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                          Posté par . Évalué à 6.

                          Ça tombe bien, c’est que font les développeurs de OpenSSL. Le mainteneur n’a qu’à faire make test après la compilation pour vérifier que le patch qu’il a cru bon d’appliquer sur les sources n’a pas cassé trop de choses.

                          C'est très bien alors.

                          – même s’il l’a fait, je ne suis pas sûr que ces tests soient capables de détecter un problème aussi subtil que celui introduit par son patch : comment teste-t-on qu’un générateur de nombres aléatoires produit bien des nombres « suffisamment » aléatoires ?

                          Alors il ne faut pas laisser au mainteneur croire que faire un make test est suffisant pour valider le binaire ! Si c'est trop compliqué à tester alors il ne faut pas laisser un mainteneur produire des patchs qu'il ne pourra pas qualifier ensuite. Si c'est ca, il reporte upstream, et c'est au projet de voir ce qu'il fait de ce patch.

                          La pour le coup, je rejoints complètement Zenitram. En matière de sécurité, on a une obligation de résultat. C'est donc très important que les projets et leurs packageurs communiquent bien.

                      • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                        Posté par . Évalué à 3.

                        Dans le cas de Debian, ce qui n'est pas normal, c'est que le mainteneur est intervenu hors workflow du projet. A mon sens, une distrib n'a pas a faire des patchs à chaud sur ce genre de libs

                        Ce genre de patch ne serait jamais arrivé sur Arch (tant que ça compile/fonctionne, on y touche surtout pas). ;-)

                        ------------> []

                        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                  • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                    Posté par . Évalué à 2.

                    Tu illustre exactement ce que je dis . C'est comme si tu nous disais que bon avec le noyau linux il y a des bugs, mais faut comprendre c'est développé par des bénévoles pas par une société comme Microsoft qui est coté en bourse.

                    Personnellement je pense que c'est une erreur quelque soit le contexte dans le quel, elle a était commise. Je ne me vois pas me foutre de la gueule de celui qui a écris ce code pour Apple comme je ne me vois pas me moquer des contributeurs de Debian.

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                      Posté par . Évalué à 4.

                      On parlait de Workflow au dessus, c'est un peu le problème : on ne doit pas attribuer l'erreur à celui qui a écrit le code, mais en l'occurence comme un bug du workflow. La responsabilité est partagée, c'est justement là ou on attend une firme comme Apple en tant qu'organisation, ça devrait tout simplement pas être possible, que ce soit un patch corrigé à l'arrache ou pas, qu'il ne repasse pas par une étape de validation du code qui détecte qu'il y a des problèmes à ce code.

                      • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                        Posté par . Évalué à 4.

                        c'est justement là ou on attend une firme comme Apple en tant qu'organisation

                        Alors qu'un projet libre, c'est normal qu'ils fassent ça à l'arrache ?

                        Est-ce qu'on doit avoir le même niveau de qualité sur un projet libre et sur un projet privateur ?
                        Dis autrement est-ce que le fait qu'un projet soit libre fait qu'il a une qualité en deçà qu'un projet non-libre ?

                        Personnellement, je suis pour le logiciel libre et je pense que le logiciel libre permet des projets de très grande qualité donc le critère libre/non-libre des logiciels ne change en rien mes exigences.

                        Utiliser le coté libre pour argumenter sur une qualité moindre (ou prendre comme argument le coté privateur d'un logiciel pour avoir un niveau d'exigence supérieur c'est pareil), c'est ne pas prendre au sérieux le LL. Si des gens ici pensent ainsi, il ne faut pas s'étonner que les décideurs pressés préfèrent payer des licence de logiciels privateurs en se disant que c'est moins pire.

                        Ça me fait penser à la polémique entre Con Kolivas et Ingo Molnár au sujet de l'ordonnanceur du noyau.

                        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                        • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                          Posté par (page perso) . Évalué à 1. Dernière modification le 24/02/14 à 13:22.

                          En l'occurence, ici on a deux cas libres, la différence étant "communautaire" contre "commercial" (dans le sens "entreprise").
                          Mais ça ne change pas le sens de ta remarque : clairement, ce genre d'excuse est un super argument à reprendre pour les anti-logiciels libres (pour la plupart communautaires, donc l'amalgame sera rapidement fait) pour dire "nous, c'est un entreprise derrière donc c'est mieux même si c'est non libre"

                          Ou comment se tirer une balle dans le pied. A éviter si on veut un mimimum que les logiciels libres (communautaires) soient pris pour autre chose que des jouets pour gamin attardé.

                        • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                          Posté par . Évalué à 1.

                          Je cherche en aucune manière à dédouanner Debian, même si il y a des différences organisationnelles évidentes, je vois pas pourquoi on est encore là dessus.

                          • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                            Posté par (page perso) . Évalué à -2. Dernière modification le 24/02/14 à 13:32.

                            Parce qu'on frappe à fond sur Apple ici, alors que c'est moins horrible qu'avec Debian sur lequel on avait pas autant tapé.
                            C'est un exemple pour montrer le "2 poids, 2 mesures". Aucunement une attaque dirigée contre Debian n'en déplaise à ceux qui ne veulent pas essayer de comprendre qu'ils jugent en fonction de ce qu'ils aiment (et que là, horrible, on rappelle un mauvais épisode de leur protégé).

                            Dans les deux cas, c'était une erreur à la con, mais comme c'est Apple ce sont des incompétants (ou carréménent : c'état voulu, étonnant que ce genre de phrase ne soit pas sortie pour Debian…) comme ça, alors que pour Debian on va chercher n'importe quelle excuse hors sujet pour ne pas dire la même chose.

                          • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                            Posté par . Évalué à 1.

                            Les personnes comme zenitram sont 1000 fo9is plus exigentes envers un logiciel libre qu'il ne le sera jamais avec un logiciel proprietaire ou une boite produisant ce systeme.

                            Ce n'est pas nouveau et je suis persuade que toutes les peronnes ayant un jour installe un logiciel libre et gratuit chez quelqu'un et que ce logiciel a eu un bug ou une fonctionnalite manquante (ou differente) a entendu "mais c'est vraiment de la merde ton truc" alors que dans le meme temps ils acceptent sans aucun probleme les crash de windows, les changements de pagination (voir les documents foireux) de Microsoft Office ou les problemes de securites de Apple (pour reprendre le sujet du journal).

                            Il vaut mieux etre conscient de cela, la merde payante a toujours meilleurs gout que le boeuf bourguignon fait maison (suffit de voir le succes de McDo pour s'apercevoir que c'est partout pareil).

                            • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                              Posté par (page perso) . Évalué à -1. Dernière modification le 24/02/14 à 13:41.

                              Les personnes comme zenitram sont 1000 fo9is plus exigentes envers un logiciel libre qu'il ne le sera jamais avec un logiciel proprietaire ou une boite produisant ce systeme.

                              Ou comment inventer un personnage plutôt que de chercher à comprendre la personne.
                              Désolé d'aplliquer la même exigence aux deux, ta perception vient uniquement du fait qu'il y a un produit qui te plait plus à toi et du coup tu le prends mal.
                              Tu "oublies" que j'utilise Linux quand il répond à mon besoin (et il le fait dans cetains cas). Bam.

                              la merde payante a toujours meilleurs gout que le boeuf bourguignon fait maison

                              C'est surtout plus rapide à être servi. Très bon exemple, car on peut le reprendre pour ce que tu aimes (quand je vois les commentaires de ce journal, je suis content d'avoir un OS où ça juste marche, l'OS n'est pas parfait mais je n'ai pas besoin de passer 2 heures pour pouvoir jouer, tous comme le boeuf bourguignon fait maison mais me prend 2 heures à faire, tu as du temps pour ça et tu aimes ça c'est bien mais ne fait pas de ton plaisir de faire à manger ou débugguer une généralité).


                              Bref, on voit surtout le refus d'essayer de comprendre l'autre en imaginant qu'il doit forcément aimer la même chose que soit.

                              • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                                Posté par . Évalué à 3.

                                Personnellement je vois une différence de taille : un produit Apple, je le paye (enfin non, je ne le paye pas mais si j'étais client, je le payerais). Pas une Debian. Rien que pour ça je suis plus exigeant vis à vis d'Apple que de Debian par exemple. Et c'est normal pour n'importe quoi d'autre : je serai plus exigeant d'un meccano pro qui touche à ma voiture et qui me facturera la main d'oeuvre bien chère, alors que si c'est un ami ou mon neveu qui répare ma voiture, je le serai beaucoup moins.

                                Est-ce si difficile à comprendre ?

                                • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                                  Posté par . Évalué à 5.

                                  Oui et non.

                                  Oui je comprends que l'on soit moins exigeant de Debian car c'est un projet de volontaires qui donnent un truc gratuit.

                                  Mais non, il ne faut des lors pas s'amuser a comparer le projet Debian et Apple ou autre. Quand on compare, c'est au meme niveau d'exigence.

                                  Quand t'es une boite qui veut des serveurs par exemple, tu ne vas pas te mettre a dire "ok eux ils ont des failles mais ils sont gratuits donc je prends quand meme", tu veux une solution sure.

                                • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                                  Posté par (page perso) . Évalué à 3. Dernière modification le 24/02/14 à 18:50.

                                  Est-ce si difficile à comprendre ?

                                  est-ce si difficile à comprendre que dans ce cas on considère Debian comme un jouet et à ne jamais mettre en prod car des gens considèrent que comme c'est gratuit on a un passe-droit sur la sécurité?

                                  Je comprend de plus en plus pourquoi des gens disent que la seule distro gratuite autorisée soit CentOS (car calqué sur le niveau de sécurité d'un truc payant), vu l'importance que des gens accordent à la sécurité dès que c'est gratuit. C'est super pour les anti-logiciels libres (car souvent gratuit "donc c'est de la merde ne prenez pas")

                                  Désolé, je considère le libre (et Debian) comme quelque chose qui mérite plus que cette considération "c'est fait par un pote pas doué donc la qualité pourrie est acceptable".
                                  Le but est d'avoir une machine qui marche, pas une truc troué, quelque soit son prix (=gratuit ou pas).

                                  Désolé d'avoir le même niveau d'exigence indépendament de données tierces (comme le prix). Je suis prèt à le descendre pour le prix en terme de fonctionnalités, mais pas en terme de sécurité car c'est ma "vie" (informatique) qui est en jeu.
                                  Je constate que toi tu es prêt à mourir d'un accident de voiture "car c'est le pote qui a bricolé la voiture, je lui pardonnerai", pas moi : la sécurité de la voiture passe avant le prix du mécano. Tu as donné un bel exemple de différence entre toi et moi, mais ne considère pas que les autres ont aussi si peu de considération pour leur vie.

                                  • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

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

                                    Je suis d'accord que l'on doit avoir la même exigence, et cela est donc encore moins excusable lorsque ton cousin à 4 mains, fait mieux et plus sécurisé que ton mécano très cher… le résultat est le même si ils se sont planté sur la sécu… mais y en a un qui s'est fait payer très cher au passage, donc si des excuses devaient être trouvée… mais avec des si.

                                    • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                                      Posté par . Évalué à 3.

                                      Merci pour ce commentaire : c'est plutôt ça que je voulais dire. Dans ce cas précis, Apple a fait moins bien qu'un amateur alors qu'ils disposent de moyens pour faire beaucoup mieux.

                                      • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                                        Posté par . Évalué à 2.

                                        […] ils disposent de moyens pour faire beaucoup mieux.

                                        Ça n'est pas mon avis et je pense que c'est là que ce situe un certain clivage dans le libre. AMHA faire du bon logiciel n'est pas une histoire d'argent mais de workflow, tu peut mettre en place un worflow pertinent avec un projet communautaire ou avec une entreprise, mais l'un n'a pas plus de facilité pour le faire que l'autre.

                                        Donc pour moi non, Apple dispose de moyens pour faire de la qualité, mais n'a pas forcément plus de moyens que Debian (évidement il faut comprendre que tout ne se résume pas à l'argent).

                                        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                        • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                                          Posté par . Évalué à 2.

                                          comprendre que tout ne se résume pas à l'argent

                                          Mais l'argent te permet de mettre en place un workflow efficace plus facilement. Tu peux payer pour mettre en place des ressources matérielles, logicielles et humaines pour gérer ces problèmes, tandis que si tu n'as pas d'argent, tu devras compter sur des bénévoles, des dons ou du mécénat.

                                          • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                                            Posté par (page perso) . Évalué à -2. Dernière modification le 26/02/14 à 11:04.

                                            Mais l'argent te permet (…)

                                            L'argent n'arrive pas la comme ça parce que les caisses en sont remplies (si elles sont remplies, c'est justement parce que ce n'est pas dépensé quand un gars perdu dit "allez, files-en"), il faut une volonté.
                                            Et on revient à ce commentaire.
                                            L'argnent ne permet pas tout, il faut aussi les gens (motivés etc).

                                            tu devras compter sur des bénévoles, des dons ou du mécénat.

                                            Ce n'est pas le sujet.
                                            Tu parles de moyens, on parle de résultat.
                                            Encore une fois, si je meurs parce que les freins ont laché, que ce soit fait par des bénévole ou par un garagiste, je m'en fou complet, le résultat est problématique (et si le bénévole dit qu'il peut faire les freins, j'attends à ce que ça marche comme pour celui qui fait payer, sinon qu'il dise qu'il ne peut pas faire aussi bien. Tu veux dire que tu imagine Debian moins bien?)
                                            Les moyens, ce sont le problème de celui qui fait, et tout ce que tu dis est que Debian peut légitimement (de ton point de vue) avoir une qualité pourrie "car pas d'argent", et ben ce n'est pas mon point de vue : d'abord les fonctionnalités, ensuite le prix, et pas l'inverse.

                                            Et surtout, c'est être méchant envers Debian qui fait du bon voire meilleur boulot qu'Apple sur certains points, argent ou pas.

                                          • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                                            Posté par . Évalué à 0.

                                            L'argent pose peut être autant de problème qu'il n'en résous. La qualité ça coûte chère, donc pour avoir les ressources d'Apple dont tu parle tant il faut réfléchir beaucoup avant de savoir si un investissement vaut le coût. Dans ce contexte, on ne fait pas les choses pour la qualité du code, mais pour pouvoir le vendre, donc si un gain de qualité n'est pas directement visible par les utilisateurs il n'y a pas de raison d'investir de l'argent dedans. Il faut maintenir un niveau de sécurité suffisant pour ne pas perdre de la crédibilité à ce niveau là c'est tout. Au contraire pour tout ce qui est expérience utilisateur, là l'investissement est tout de suite visible par l'utilisateur et c'est ce qu'il va acheter.

                                            Donc je ne vois pas en quoi Apple est mieux armé que Debian pour avoir une bonne sécurité.

                                            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                            • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                                              Posté par . Évalué à 1.

                                              Donc je ne vois pas en quoi Apple est mieux armé que Debian pour avoir une bonne sécurité.

                                              Je sais pas par exemple si Debian vient te voir et te demande de bosser pour eux pour … 0€ et que Apple vient te voir et te propose de bosser pour eux opur 100 000€. Je me demande qui est le mieux place pour te faire bosser pour son projet…

                                              C'est vrai que c'est tres surfait le pouvoir de l'argent. Tout le monde sait que la planete ne tourne que grace a l'amour…

                                              • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

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

                                                Tu ignores volontairement les mots les plus importants de son commentaire.
                                                "savoir si un investissement vaut le coût."

                                                Quand au 0 euro de Debian, ils n'ont qu'à vendre leur produit ou chercher un business-model qui va bien (ça se vendra si le seul interêt de la distro n'est pas sa gratuité)

                                                Faut aussi arrêter un peu avec ces "les pauvres petits qui n'ont pas de sous", ce n'est pas le sujet. Si il y a un besoin, les gens y mettront le prix autant que pour Apple (par dons ou sponsoring du taf à faire)

                                                • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                                                  Posté par . Évalué à 3. Dernière modification le 26/02/14 à 12:24.

                                                  Moi je suis tout de meme impressionne par toi. Tu es la premiere personne que je connaisse qui ne fait aucune erreur, qui connait tout sur tout et surtout encore plus impressionant qui n'introduit JAMAIS de bug dans ses logiciels.

                                                  Rien que pour ce dernier point je pense qu'il ne faudrait pas attendre ta mort pour te faire entrer au pantheon.

                                                  ps: je te signale que je n'ai absolument pas critique Apple sur ce probleme, l'erreur est humaine et les bugs sont legions. Par contre je pense que Apple a tres legerement plus les moyens, entre autre financier, pour mettre des developpeurs sur des trucs aussi ingrats que la revision de code. En tout cas bien plus de moyens que Debian que ce soit humains ou financier.

                                                  • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                                                    Posté par . Évalué à 1.

                                                    ps: je te signale que je n'ai absolument pas critique Apple sur ce probleme, l'erreur est humaine et les bugs sont legions. Par contre je pense que Apple a tres legerement plus les moyens, entre autre financier, pour mettre des developpeurs sur des trucs aussi ingrats que la revision de code. En tout cas bien plus de moyens que Debian que ce soit humains ou financier.

                                                    S'ils ont autant de moyens financier c'est parce qu'ils ne le dépensent pas dans des choses qu'ils ne vendent pas à l'utilisateur. Donc ils ne le dépense pas trop pour de la sécurité. Le problème quand tu es un projet financier comme ça c'est que tu cours toujours vers la rentabilité et que ça diminue la qualité. Je vais le remettre en gras pour que tu le vois : Le problème quand tu es un projet financier comme ça c'est que tu cours toujours vers la rentabilité et que ça diminue la qualité. C'est bon tu l'a lu ?

                                                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                                    • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                                                      Posté par . Évalué à -6.

                                                      Ah c'est parceque Apple de depense pas qu'ils ont des milliards en caisse? C'est ca le secret.

                                                      Debian ces sales communistes glandeurs (voir carrement incapables) sont en fait de grand depensier c'est pour ca qu'ils ont pas eux des milliars en caisse.

                                                      C'est beau le capitalisme en fait, tu depenses pas et donc ton coffre fort se rempli d'or par osmose probablement.

                                                      • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                                                        Posté par . Évalué à 2.

                                                        Ah c'est parceque Apple de depense pas qu'ils ont des milliards en caisse? C'est ca le secret.

                                                        Non c'est parce qu'ils le dépensent uniquement dans l'objectif de garder/obtenir des clients. Pour le reste je te laisse à tes idées préconçues, mais si ça t'intéresse tu pourra lire ça (si tu ne lis pas mes commentaires, peut être que tu lis les liens que je donne, qui sait ?).

                                                        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                              • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                                                Posté par . Évalué à 2.

                                                Ouai, mais Apple ne fera pas ça pour un expert en sécurité, elle le ferra pour un spécialiste de l'UX.

                                                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                  • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                                    Posté par . Évalué à -2.

                                    est-ce si difficile à comprendre que dans ce cas on considère Debian comme un jouet et à ne jamais mettre en prod car des gens considèrent que comme c'est gratuit on a un passe-droit sur la sécurité?

                                    Rien à voir. Debian n'a pas la sécurité comme objectif principal affiché, même s'ils font de leur mieux pour garder leur distribution sure. Par contre dans le libre, je serais plus exigeant vis à vis d'OpenBSD par exemple car la sécurité est affichée comme objectif principal.

                                    Désolé, je considère le libre (et Debian) comme quelque chose qui mérite plus que cette considération "c'est fait par un pote pas doué donc la qualité pourrie est acceptable".

                                    Ce n'est pas ce que je voulais dire, même si c'est ce qui a pu paraitre dans mes propos. N'oublie pas que je n'ai pas forcément un point de vue aussi tranché que toi (ce n'est pas une insulte : je n'ai simplement pas d'autre mot qui me vient à l'esprit). Et il est clair que je n'utiliserais ni Debien , ni Linux dans certains cas. Si on parle de sécurité par exemple, j'aurais tendance à me tourner vers OpenBSD (peut-être même des solutions proprios basées sur OpenBSD).

                                • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                                  Posté par . Évalué à 6.

                                  C'est insultant envers le projet Debian (et tout les projets communautaires). Ils n'ont pas une qualité moindre et compensent largement l'argent (qui semble t’obnubiler) par la qualité des contributeurs et l'organisation interne. Elle n'est pas parfaite loin sans faux, mais ils ne font pas pire (régulièrement mieux) qu'un projet lucratif.

                                  Je comprends ton point de vu mais je le trouve insultant et paternaliste avec un projet (entre autre) qui n'a rien des amateurs avec les quels tu le compare.

                                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                  • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                                    Posté par . Évalué à 1.

                                    Je comprends ton point de vu mais je le trouve insultant et paternaliste avec un projet (entre autre) qui n'a rien des amateurs avec les quels tu le compare.

                                    Je suis peut-être allé un peu trop loin dans la comparaison. Je ne veux pas dénigrer Debian non plus, car je sais que le travail accompli est remarquable. Je voulais juste mettre en évidence que l'on est en droit d'être plus exigeant d'un service payant que d'un service gratuit. Et si on rest edans le libre, je serais beaucoup plus exigeant vis à vis de Canonical, RedHat, ou Suse pour leurs distributions par rapport à Debian dans le cas ou je paierais le service adéquat. Sinon quelle serait leur valeur ajoutée ?

                                    • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                                      Posté par . Évalué à 3.

                                      Ouai en fait tu montre que tu ne sais pas trop ce que paie les gens et tu fais des suppositions.

                                      Généralement :

                                      • dans le monde propriétaire, tu paie pour utiliser un logiciel, on te dis généralement explicitement dans le contrat qu'il y a des bugs et que le contrat n'implique pas de responsabilité de la part de la boite que tu es entrain de payer (c'est aussi dis dans la GPL)
                                      • dans le monde du libre et dans le monde propriétaire aussi d'ailleurs, tu paie pour un support c'est à dire que tu aie pour qu'il y ai des gens qui s'occupe de tes problèmes chose qui n'est pas garanti par un projet communautaire

                                      Celui qui veut se faire payer pour une garantie de sécurité fera long feu.

                                      Je ne dis pas que ça a un intérêt de payer ou que ça n'est pas des arnaqueurs juste que si tu crois payer de la sécurité, il vaut mieux que tu ne finisse pas décideur pressé tu risquerais d'avoir de jolies déconvenues.

                                      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                            • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                              Posté par . Évalué à 5.

                              T'es au courant que libsecurity est libre?

                              Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                            • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                              Posté par . Évalué à 2.

                              Les personnes comme zenitram sont 1000 fo9is plus exigentes envers un logiciel libre qu'il ne le sera jamais avec un logiciel proprietaire ou une boite produisant ce systeme.

                              Il est extrêmement exigeant (perso je trouve trop mais chacun son usage). Tu as l'impression qu'il l'ai pour le LL parce qu'on en parle plus par ici.

                              Ce n'est pas nouveau et je suis persuade que toutes les peronnes ayant un jour installe un logiciel libre et gratuit chez quelqu'un et que ce logiciel a eu un bug ou une fonctionnalite manquante (ou differente) a entendu "mais c'est vraiment de la merde ton truc" alors que dans le meme temps ils acceptent sans aucun probleme les crash de windows, les changements de pagination (voir les documents foireux) de Microsoft Office ou les problemes de securites de Apple (pour reprendre le sujet du journal).

                              Je vois pas le rapport. Mais si tu souhaite vraiment en parler. Plus tu t'investis dans quelque chose plus tu va avoir tendance à l'apprécier quelque soit sa qualité et le type d'investissement. Ça marche aussi avec les libristes qui passent du temps à prendre en main leur environnement. De plus choisir quelque chose qui n'est pas « normal » entraîne une responsabilité, donc ça ne donne pas envie de l'utiliser. Beaucoup préfèrent avoir les même problèmes que tout le monde que des problèmes éventuellement moins importants mais différents des autres.

                              Mais je ne comprends pas pourquoi tu parle de ça.

                              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

              Posté par . Évalué à 4.

              Il aurait fallu tous les pendre; haut et court bien entendu.

            • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

              Posté par . Évalué à 3.

              Tu n'a pas compris. Quand c'est de l'OpenSource on accepte que la qualité soit pas au rendez-vous. On parle vite fait des problèmes (on se félicite de la transparence), puis on passe à autre chose. Par contre on souligne bien les réussites Open Source et les défauts du propriétaire, comme ça magiquement ça fait de la publicité. :)

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

              Posté par . Évalué à 9. Dernière modification le 24/02/14 à 09:27.

              Heu, non, le cas est franchement différent :

              • Le bug de debian vient du fait d’essayer de suivre des bonnes pratiques (éliminer des warning d’outils d’analyse). Le bug d’Apple vient du fait de ne pas détecter/éliminer assez de warning
              • Le bug de debian n’aurait jamais pu être détecté par des tests unitaire/couverture de code. Le code Apple incriminé aurait dû (si on veut faire un code de qualité bien sûr) être couvert par un test unitaire, et ne l’a visiblement pas été.

              Le « scandale » que les gens font sur ce site vient du fait que l’erreur aurait dû être facilement détectée, pas du fait de son impact.

            • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

              Posté par . Évalué à -8.

              Bla bla on sait que tu destestes tout ce qui se rapporte a linux et que tu ne manques pas une occasion de venir insulter ces utilisateurs, les developpeurs et les packageurs, surtout ceux de Debian.

              Peut etre qu'il serait tant que tu te calmes sur le sujet ou va cracher ta bile sur un autre site.

        • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

          Posté par . Évalué à 10.

          Ben il a pas tort non plus, meme si la forme y est clairement pas.

          En l'occurence, 3 choses simples et 100% automatisees auraient attrape le probleme au moment du push:
          - analyze statique de clang sur chaque push
          - tests unitaires
          - des conventions des codages un peu moins debiles, couplees a un formattage de code automatique (que xcode n'a pas, malheureusement). Oui, ca fait un peu 30 ans qu'on sait qu'un if sans accolades cause exactement ce genre de problemes, un etudiant decouvre generalement caen premiere annee lors de son premier projet en c.

          Quand on considere la sensibilite de la lib en question, et la simplicite de faire une passe statique avec clang, on peut vraiment se demander pourquoi au moins le premier point n'a pas ete fait, et si ca a ete fait, pourquoi ca a ete ignore.

          Si en plus tu consideres que la faille a ete introduite en 2012 avec ios6, et ils ont meme plus l'excuse "on avait la moitie de la boite occupee a reecrire l'os" qu'ils auraient pu avoir avec ios7.
          Et ca confirme une fois de plus au passage que personne ne review le code open source, et que donc l'argument "with enough eyes all bugs are shallow" est bidon.

          Linuxfr, le portail francais du logiciel libre et du neo nazisme.

          • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

            Posté par . Évalué à 5.

            Si je suis plutôt d'accord avec toutes ces bonnes pratiques, ils faut voir que de grands projets ne l'applique pas…

            Par exemple, le noyau linux :
            - les accolades autour des blocs d'une ligne ne sont pas acceptées. C'est compensé par une indentation à 8 espaces qui est vérifié par un outil normalement.
            - les warnings ne sont pas corrigés (et je suis d'ailleurs pas sûr que l'option -Wall soit activée sur tout le code)
            - les tests unitaires sont plutôt rares si ce n'est inexistant.
            - le code compile uniquement avec gcc, on repassera pour la variété de compilateurs.

            Tout est basé sur la code review, mais ce n'est pas parfait.

            A noter cependant que quand un pattern de code buggué est trouvé, il y a des patchs Coccinelle (http://coccinelle.lip6.fr/) qui sont fait pour corriger les bugs similaires.

            • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

              Posté par (page perso) . Évalué à -10. Dernière modification le 25/02/14 à 07:18.

              les accolades autour des blocs d'une ligne ne sont pas acceptées.

              J'aime bien les gars qui balancent "les accolades, toujours, sinon ça pue" mais qui utilisent un noyau qui dit "les accolades, jamais si une ligne" (donc complètement l'inverse de leur super principes).

              Les "bonnes pratiques que tout le monde devriat faire" dépendent des gens, mais ceux qui critiquent pensent toujours que eux sont super parfait et ont les meilleures pratiques.

              • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

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

                J'aime bien les gars qui balancent "les accolades, toujours, sinon ça pue" mais qui utilisent un noyau qui dit "les accolades, jamais si une ligne" (donc complètement l'inverse de leur super principes).

                ?

                T'exagère un peu, non ?
                Tu compares des règles que certains disent vouloir pour le code et le fait que leur machine utilise un code dont l'équipe a d'autres règles. A moins d'utiliser ce dit code, ça change quoi ?
                Oui on peut critiquer leur choix mais de là à opposer les deux…

              • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                Posté par . Évalué à 10.

                'Tin, mais t'as vu la vierge ou quoi?
                Et si je pense que les bsd braces c'est plus lisible, ca m'interdit de naviguer sur un site en java qui tourne sur un runtime qui utilise un style different tant que t'y es?

                Oui, les if sans accolades, ca craint, on en a la preuve ici.
                T'as quelque chose a rajouter a ca, autre que tes sempiternelles hyper rationalisation sans queue ni tete que tu repetes sans cesse a qui veut ecouter (ou pas)?

                Linuxfr, le portail francais du logiciel libre et du neo nazisme.

              • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                Posté par . Évalué à 10. Dernière modification le 25/02/14 à 10:05.

                J'aime bien les gars qui balancent "les accolades, toujours, sinon ça pue" mais qui utilisent un noyau qui dit "les accolades, jamais si une ligne" (donc complètement l'inverse de leur super principes).

                Sauf que l'indentation est vérifiée par un outil. Et que du coup ca n'a aucune chance de passer en code review.

                Chaque projet choisit sa stratégie, selon ses moyens, l'essentiel étant que des étourderies de type "stagiaire de 1ere année" soit filtrée à un moment donné. Il s'agit pas de mettre des accolades juste pour mettre des accolades. Et coté Apple, il n'y a manifestement rien pour filtrer cela.

                Sinon, juste comme ca, on dirait que tu as petit sentiment d'infériorité envers les utilisateurs de Linux. Tu nous sors souvent des extrapolations assez farfelues sur les utilisateurs soit disant ultra-geeks de Linux (sérieux, ma grand mère utilise Linux….). D'où tu nous sors un tel complexe toi qui est pourtant par ailleurs assez mégalo ? Tu veux bien nous parler de ton enfance ? Des manchots te tapaient à l'école ?

              • [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés

                Posté par . Évalué à 4.

                Tu deviens vraiment fatiguant là

  • # Code défensif

    Posté par . Évalué à 10.

    Je vois surtout que c'est le genre d'erreur de merde que tout le monde peut éventuellement faire un jour ou l'autre.
    Le goto en lui-même n'est pas vraiment l'erreur ici je trouve.

    Le problème que je vois est que le code n'est pas défensif. Il aurait fallu faire en sorte que la valeur par défaut de type OSStatus, même non réaffectée soit interprétée comme une erreur (ou un bug) et récupérée par la fonction appelante…

    • [^] # Re: Code défensif

      Posté par . Évalué à 6.

      Utilisation du goto, mauvaise indentation, manque de tests, non initialisation de la variable d'erreur, non utilisation des accolades.

      Beaucoup de petites erreurs cumulées. Chacun est sensible différemment a ces erreurs. Au final, grosse conséquence puisque le code est une passoire.

      • [^] # Re: Code défensif

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

        Il y a des fusées qui ont explosées pour moins que ça.

      • [^] # Re: Code défensif

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

        Utilisation du goto

        Il n'y a rien de problématique avec l'utilisation des goto dans ce code.

        mauvaise indentation

        L'indentation est bonne dans le reste du project. C'est juste une ligne qui ne va pas.
        Peut être qu'ils aurais du avoir un bot qui vérifie l'indentation, C'est vrai.

        manque de tests

        Je ne sais pas s'ils ont des tests ou pas. Mais avoir un code testé à 100% est difficile voir impossible.

        non initialisation de la variable d'erreur

        Rien à voir avec cette faille.
        C'est vrai que c'est une mauvaise pratique mais ça n'a rien à voir.

        non utilisation des accolades

        Chacun ces goûts. On peux troller autant qu'on veut sur tab/espace, niveau d'indentation, acolade ou non.

        Beaucoup de petites erreurs cumulées

        C'est le cas de quasiment toutes les faille ou bugs. Je ne prendrais pas cet example comme une peuve de mauvaise pratique. Des bugs arrivent dans tout les projets.
        Peut être aussi que cette « erreur » est volontaire.

        • [^] # Re: Code défensif

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

          L'indentation est bonne dans le reste du project. C'est juste une ligne qui ne va pas.
          Peut être qu'ils aurais du avoir un bot qui vérifie l'indentation, C'est vrai.

          Non, aujourd'hui il y a des outils pour faire le reformatage du code de manière automatique (ne serait-ce que pour voir tout de suite ce qui change en cas de merge sur le VCS). Quand on voit ça en 2014, on se pose des questions sur la chaîne de développement…

          Je ne sais pas s'ils ont des tests ou pas. Mais avoir un code testé à 100% est difficile voir impossible.

          Ça montre clairement une absence de test. S'il y avait eu un test pour s'assurer que la fonction renvoie bien une bonne valeur si on passe en paramètre de bon argument (le test minimum), le code se serait vu tout de suite.

          Peut être aussi que cette « erreur » est volontaire.

          C'est la seule chose que je peut imaginer. À ce niveau de mauvaises pratiques, on peut appeler ça de l'incompétence; et je ne peux le concevoir de la part des devs d'Apple.

          • [^] # Re: Code défensif

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

            Ça montre clairement une absence de test.

            Non, juste une absence de test dans un cas bien particulier. (c-à-d un bon certificat bien signé, mais le site chiffré avec un autre certificat, si j'ai bien compris)

            S'il y avait eu un test pour s'assurer que la fonction renvoie bien une bonne valeur si on passe en paramètre de bon argument (le test minimum), le code se serait vu tout de suite.

            Il y avais peut être des tests qui test que la fonction renvoi OK quand tout est correct; des tests qui vérifient que la fonction renvoi une erreur quand la chaîne de certificats n'est pas bonne pour plein de raisons différentes, et d'autre tests, juste pas un test qui vérifie la condition en question. Bref, si tout les ifs sont testé sauf 1, ça fait quand même plus de 90% de couverture dans cette fonction ce qui n'est pas si mal. (Et dans ce cas un les pourrait même rapporté 100% de couverture puisque il les ifs non testé sont "mort". Et donc même une politique de 100% de couverture aurait laissé passer le bug)

            Je ne connais pas les pratiques de tests de chez Apple et si il y a vraiment des tests, mais cette faille n'est pas une preuve qu'il n'y ait pas de test.

            À ce niveau de mauvaises pratiques, on peut appeler ça de l'incompétence;

            C'est vrai que le bug est honteux. Et que les devs peuvent bien être gêné. Mais ça reste quelque chose qui peut arriver même au plus compétents avec des bonnes pratiques. Des bonne pratique permet de limiter le nombre de bugs, mais jmmais d'annuler complêtement le risque. Et vu le nombre de ligne de code que Apple maintiens, un bug arrive forcément de temps en temps.

            Oh, et rappelle toi que les bonnes pratiques ont aussi un coût. Et qu'il faut faire le calcul entre coût et risque.
            Un bot qui vérifie que l'indentation est correcte n'est pas trivial (plein de cas particuliers). Et en général les erreurs d'indentation ne sont facilement visibles par des humain qui peuvent les corrigé et n'ont normalement pas beaucoup d'impact.

            • [^] # Re: Code défensif

              Posté par (page perso) . Évalué à 1. Dernière modification le 24/02/14 à 06:46.

              Un bot qui vérifie que l'indentation est correcte n'est pas trivial (plein de cas particuliers). Et en général les erreurs d'indentation ne sont facilement visibles par des humain qui peuvent les corrigé et n'ont normalement pas beaucoup d'impact.

              man indent

              Je ne code pas en C mais je pense qu'il doit y avoir plein d'autres outils de ce genre. Appeler un programme externe lors de l'enregistrement du fichier n'est pas très compliqué à faire quand on travaille avec un bon éditeur.

              • [^] # Re: Code défensif

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

                Je connais indent, clang-format, et autres IDE. Mais ce n'est pas aussi simple que d'appeler un programme externe, car ces outils ne sont pas parfaits et demandent une review manuelle.
                Il y a toujours des cas particuliers, des #if, des macros spéciales, du code automatiquement génénrés, …

                En rapport avec le journal: http://llvm.org/bugs/show_bug.cgi?id=18938

        • [^] # Re: Code défensif

          Posté par . Évalué à 2.

          L'indentation est bonne dans le reste du project. C'est juste une ligne qui ne va pas.

          Hein ? Ce n'est pas juste une ligne. Tout le fichier est moisi. Je n'ai pas regardé les autres fichiers, je n'ai pas que ça à faire, mais je suppose que ça soit être dans le même style.
          Désolé, mais utiliser un mélange d'espaces et de tabulations (parfois sur la même ligne !), ce n'est pas de la "bonne indentation".
          Tu ajoutes à ça les accolades qui ne sont pas toujours placées au même endroit, et les espaces qu'on met ou pas (selon l'humeur) derrière les if, et non, je ne crois pas qu'on puisse dire que l'indentation est bonne dans le reste du projet.

          Je bosse sur un projet qui est très loin des considérations qu'Apple devrait avoir quand on touche à du code sensible comme celui-là, et pourtant, si je tombais sur un fichier indenté comme ça, ça me mettrait hors de moi.

          • [^] # Re: Code défensif

            Posté par . Évalué à 2.

            Ce n'est pas juste une ligne. Tout le fichier est moisi.

            Ah oui, il est gratiné ! J'en ai vu (et parfois commis) quelques uns, des pourris, mais celui-ci est dans le top.

            On peut ajouter à ce que tu as noté :
            -- la déclaration du retour des fonctions, présenté de 3 manières différentes ;
            -- utilisation de uint8_t, mais aussi de UInt16.

          • [^] # Re: Code défensif

            Posté par . Évalué à 2.

            Désolé, mais utiliser un mélange d'espaces et de tabulations (parfois sur la même ligne !)

            Je plussoie. D'ailleurs, c'est assez pénible d'aller lire l'implémentation de GNU de la STL, justement parce que c'est le foutoir de ce point de vue ( et comme j'utilise des tab à 2, et non 4 comme la majeure partie des gens… ).
            Quand on se dit qu'un simple hook sur l'action de commit du VCS suffirait à coller un coup d'astyle et donc avoir un code propret, c'est tout de même dommage.

          • [^] # Re: Code défensif

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

            J'admet que je n'avais pas regardé le reste du fichier, juste la fonction en question.

            C'est plutôt classique pour du code code qui date de 1999 et qui est passé par 3 style différents.

        • [^] # Re: Code défensif

          Posté par . Évalué à 2.

          non utilisation des accolades

          Chacun ces goûts. On peux troller autant qu'on veut sur tab/espace, niveau d'indentation, acolade ou non.

          En l'occurence, je ne trouve pas que le manque d'accolades soit une affaire de goût.
          Le C l'autorise, mais je trouve que c'est une mauvaise pratique, en tout cas, je ne laisse en aucun cas passer un code comme cela en revue chez moi.

          C'est le cas de quasiment toutes les faille ou bugs. Je ne prendrais pas cet example comme une peuve de mauvaise pratique. Des bugs arrivent dans tout les projets.

          C'est vrai que ça arrive dans tous les projets, même ceux ayant de bonnes pratiques (on en parle un peu dans les commentaires précédents, parait-il)
          Mais les mauvaises pratiques de code peuvent accentuer le problème et ajouter de nouvelles failles.
          Donc le "ça arrive même à ceux qui codent bien" est du même accabi que lorsque j'entends des gens dire "il a eu un cancer à 45 ans et il ne fumait pas, alors je m'en fou, je peux fumer 3 paquets par jours !"

          Peut être aussi que cette « erreur » est volontaire.

          Ça c'est un autre problème. Mais là encore, avec de bonnes pratiques, une erreur volontaire est plus difficile à dissimuler.

          • [^] # Re: Code défensif

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

            je ne trouve pas que le manque d'accolades soit une affaire de goût.

            Moi je trouve que c'est une affaire de goût. Est-ce une affaire de goût de savoir si c'est une affaire de goût ? :-)
            Certains projet ne laisse pas passer un code avec des accolades en trop en review. (ex: Qt)
            Et d'autres veulent des espaces, et d'autres veulent des tabs. Moi j'apelle ça une affaire de goût.

            Donc le "ça arrive même à ceux qui codent bien" est du même accabi que lorsque j'entends des gens dire "il a eu un cancer à 45 ans et il ne fumait pas, alors je m'en fou, je peux fumer 3 paquets par jours !"

            Je ne veux pas défendre les « mauvaises pratiques ».
            Je critique: « Oh une faille, c'est à cause des mauvaises pratiques, c'est vraiment des incompétants chez Apple ».
            Ce serait plutôt du même accabit que « Il a eu un cancer, donc c'est un con (car les fumeurs sont des cons) », qui est assez irrespectueux en plus d'être fallacieux.

            avec de bonnes pratiques, une erreur volontaire est plus difficile à dissimuler.

            On est d'accord. « plus difficlie », mais toujours possible. Donc l'existence d'une faille ne prouve pas que les pratiques sont mauvaises.

            • [^] # Re: Code défensif

              Posté par . Évalué à 4.

              Moi je trouve que c'est une affaire de goût. Est-ce une affaire de goût de savoir si c'est une affaire de goût ? :-)
              Certains projet ne laisse pas passer un code avec des accolades en trop en review. (ex: Qt)
              Et d'autres veulent des espaces, et d'autres veulent des tabs. Moi j'apelle ça une affaire de goût.

              La différence entre espaces et tab, la taille des espaces, la position des accollades, si les parentheses sont collées ou pas à ce qu'elle contiennent, je classe également tout cela dans le style.

              Mais le coup de ne pas mettre d'accolades lorsqu'il n'y a qu'une seule instruction avec un if, j'ai vraiment du mal.
              C'est vrai que tous les arguments auquels je pense, peuvent être appliqués aux autres cas, mais quand même, ça crée une différence artificielle entre les cas 1 et plusieurs instructions, et je trouve que c'est beaucoup plus sujet à erreur que les autres.

              Je ne veux pas défendre les « mauvaises pratiques ».
              Je critique: « Oh une faille, c'est à cause des mauvaises pratiques, c'est vraiment des incompétants chez Apple ».
              Ce serait plutôt du même accabit que « Il a eu un cancer, donc c'est un con (car les fumeurs sont des cons) », qui est assez irrespectueux en plus d'être fallacieux.

              Moi je dirais, il a eu un cancer, c'est vraiment pas cool pour lui. Mais son mode de vie n'était vraiment pas très sain, du coup c'est quelque chose qui lui pendait au nez plus qu'à d'autres !

              Sinon, la différence est que le type qui a un cancer, déjà c'est vraiment terrible pour lui et son entourage ! Mais ensuite, si cela viens de son tabagisme, c'est lui qui ne prenait pas soin de lui même, à moi il ne m'a rien fait et je n'ai pas de raisons de lui en vouloir ni de l'accabler plus !
              Là, on parle de professionnels qui vendent un produit, sans dire que c'est des cons, dans ce cas c'est plutôt de nous qu'ils se moquent, car c'est nous qui en patissons en utilisant leur produits au final. Ça terni leur réputation et la confiance qu'on leur octroi. (même si elle frisait déjà le zéro pour ma part)

              Après, il y a peut-être également une certaine frustration des gens ici car ils entendent souvent vanter apple et ses produits, alors ils se lâchent un peu…

              On est d'accord. « plus difficlie », mais toujours possible. Donc l'existence d'une faille ne prouve pas que les pratiques sont mauvaises.

              Ça n'est pas ce que j'ai dit, j'ai dit que cela réduisait les risques, et que statistiquement, je pense qu'il devrait y en avoir moins dans une grosse base de code si elle a été écrite en suivant de "bonnes pratiques" en terme de style mais aussi de technique de codage.
              Après, entre ce que je pense et la réalité…
              Pour reprendre l'analogie du cancer, il y a des gens qui ont un mode de vie très sain qui finissent malheuresement par en avoir un.

              (c'est beau les trolls sur la cigarette en plein débat sécurité des produit apple !! je suis fier de moi pour le coup !)

              • [^] # Re: Code défensif

                Posté par (page perso) . Évalué à 2. Dernière modification le 25/02/14 à 00:00.

                Mais son mode de vie n'était vraiment pas très sain

                Mais personne n'a dit que c'était un fumeur ou que son cencer à été causé par le fait qu'il fume !
                C'est là ou je veux en venir : Il ne faut pas tirer de conclusions hâtives.

                (De même, ne conaissant pas les pratiques chez Apple, cette faille ne permet pas de savoir si ils ont de si mauvaises pratiques)

                c'est beau les trolls sur la cigarette en plein débat sécurité des produit apple !! je suis fier de moi pour le coup !

                Tu fais bien :-) Et je maintiens que les accolades c'est une question de goût.

            • [^] # Re: Code défensif

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

              Certains projet ne laisse pas passer un code avec des accolades en trop en review. (ex: Qt)
              Et d'autres veulent des espaces, et d'autres veulent des tabs. Moi j'apelle ça une affaire de goût.

              C'est quand même des choses différentes.
              Autant espaces et tabs c'est "cosmétique". Autant les accolades c'est pas juste une histoire de style. En général ceux qui veulent toutes les accolades explicites sont déjà juste tombés au moins une fois sur un cas ou, par exemple lors d'une session de debug, qqn a rajouté une instruction sous un if (genre du log) et n'a pas compris pourquoi plus rien ne fonctionnait.
              Avec des accolades il n'y aurait jamais eu de problème.
              Pour ma part c'est pour cette raison que je met systématiquement des accolades, pas pour une histoire de style ou de goût, contrairement à l'indentation, à la position des accolades, aux tabs et espaces.

              • [^] # Re: Code défensif

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

                Un peu comme les points virgules en Javascript ? Ça reste un choix arbitraire sans grande importance. La preuve est que tout le monde fait différemment

                • [^] # Re: Code défensif

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

                  Un peu comme les points virgules en Javascript ?

                  Oui, aussi. Surtout lorsque tu ne maitrise pas tout la suite de compil et qu'un "minifieur" arrive sans analyser le code et fait juste de la concaténation, on arrive à de belles surprises (ou alors il faut user de stratagèmes qui vont s'assurer que ça fonctionne mais ça devient d'un crade…)

Suivre le flux des commentaires

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