Journal Apple, le SSL les goto et les accolades

Posté par flagos le 23 février 2014 à 10:45. Licence CC By‑SA.

Étiquettes : aucune

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 patrick_g (site web personnel) le 23 février 2014 à 11:03. Évalué à 10.

Analyse et commentaires intéressants ici :

https://www.imperialviolet.org/2014/02/22/applebug.html

et aussi ici :

http://utcc.utoronto.ca/~cks/space/blog/programming/IndentationProblem
- [^] # Re: Something was horribly wrong with SSL/TLS in iOS
  
  Posté par Zenitram (site web personnel) le 23 février 2014 à 11:18. É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 claudex le 23 février 2014 à 11:34. É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 Zenitram (site web personnel) le 23 février 2014 à 11:54. Évalué à 2. Dernière modification le 23 février 2014 à 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 claudex le 23 février 2014 à 12:01. É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 Zenitram (site web personnel) le 23 février 2014 à 12:08. É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 claudex le 23 février 2014 à 12:27. É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 JGO le 24 février 2014 à 11:56. É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 calandoa le 06 mars 2014 à 17:01. É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 JGO le 06 mars 2014 à 17:43. É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 chimrod (site web personnel) le 23 février 2014 à 11:07. Évalué à 10. Dernière modification le 23 février 2014 à 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 Firwen (site web personnel) le 23 février 2014 à 11:26. Évalué à 2. Dernière modification le 23 février 2014 à 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 CrEv (site web personnel) le 23 février 2014 à 11:45. É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 rewind (Mastodon) le 23 février 2014 à 12:18. É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 Meku (site web personnel) le 23 février 2014 à 12:53. É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 rewind (Mastodon) le 23 février 2014 à 13:47. É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 Gof (site web personnel) le 23 février 2014 à 16:21. É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 rewind (Mastodon) le 23 février 2014 à 19:15. É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 Gof (site web personnel) le 23 février 2014 à 21:36. É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 rewind (Mastodon) le 24 février 2014 à 10:43. Évalué à 1. Dernière modification le 24 février 2014 à 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 Gof (site web personnel) le 24 février 2014 à 11:47. É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 rewind (Mastodon) le 24 février 2014 à 12:07. É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 tyoup le 26 février 2014 à 08:16. É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 Gof (site web personnel) le 26 février 2014 à 10:03. É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 tyoup le 27 février 2014 à 20:38. Évalué à 1.
        
        Intéressant. Du coup je déteste un peu moins C++ :-)
        
        [^] # Re: Le cas goto
        
        Posté par lmg HS (site web personnel) le 07 mars 2014 à 10:54. É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 Claude SIMON (site web personnel) le 23 février 2014 à 21:43. É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.
        
        Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
        
        [^] # Re: '-fno-rtti' et exceptions.
        
        Posté par Claude SIMON (site web personnel) le 23 février 2014 à 21:51. Évalué à 1. Dernière modification le 23 février 2014 à 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…
        
        Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
        
        [^] # Re: '-fno-rtti' et exceptions.
        
        Posté par Zylabon le 23 février 2014 à 23:46. É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 rewind (Mastodon) le 24 février 2014 à 10:09. É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 rewind (Mastodon) le 24 février 2014 à 10:05. É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 Gof (site web personnel) le 24 février 2014 à 10:25. É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 reynum (site web personnel) le 24 février 2014 à 21:26. Évalué à -1. Dernière modification le 24 février 2014 à 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 Gof (site web personnel) le 24 février 2014 à 23:46. É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 reynum (site web personnel) le 25 février 2014 à 19:39. É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 reno le 23 février 2014 à 15:44. É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 gst le 23 février 2014 à 12:19. É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 Firwen (site web personnel) le 23 février 2014 à 12:37. Évalué à 9. Dernière modification le 23 février 2014 à 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 gst le 23 février 2014 à 12:57. É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 Firwen (site web personnel) le 23 février 2014 à 13:16. É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 CrEv (site web personnel) le 23 février 2014 à 14:24. É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 barmic le 23 février 2014 à 22:24. É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 CrEv (site web personnel) le 24 février 2014 à 10:02. É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 barmic le 24 février 2014 à 10:25. É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 CrEv (site web personnel) le 24 février 2014 à 14:34. É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 Firwen (site web personnel) le 24 février 2014 à 22:17. É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 CrEv (site web personnel) le 25 février 2014 à 08:30. É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 zul (site web personnel) le 23 février 2014 à 13:24. Évalué à 2.
        
        Est-ce vraiment plus clair / extensible que l'utilisation de goto ?
        
        [^] # Re: Le cas goto
        
        Posté par gst le 23 février 2014 à 13:46. É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 YBoy360 (site web personnel) le 24 février 2014 à 07:02. Évalué à -3.
        
        Surtout que la gestion des exceptions en c++, c'est loin d'être gratuit.
        
        [^] # Re: Le cas goto
        
        Posté par Zenitram (site web personnel) le 24 février 2014 à 08:16. É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 barmic le 24 février 2014 à 09:02. É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 rewind (Mastodon) le 24 février 2014 à 10:14. É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 freem le 24 février 2014 à 11:17. É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 pasBill pasGates le 24 février 2014 à 11:19. Évalué à 8.
        
        Ca sert a pouvoir utiliser le mot break , qui fait office de goto
        
        [^] # Re: Le cas goto
        
        Posté par freem le 24 février 2014 à 11:48. É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 CrEv (site web personnel) le 24 février 2014 à 14:35. É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 calandoa le 06 mars 2014 à 17:08. É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 tyoup le 06 mars 2014 à 19:25. Évalué à 1.
        
        "Great programmers write baby code" ?
      - [^] # Re: Le cas goto
        
        Posté par barmic le 07 mars 2014 à 09:38. É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 Guillaum (site web personnel) le 23 février 2014 à 11:43. Évalué à 9. Dernière modification le 23 février 2014 à 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 CrEv (site web personnel) le 23 février 2014 à 11:51. É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 Christie Poutrelle (site web personnel) le 23 février 2014 à 13:21. Évalué à 1. Dernière modification le 23 février 2014 à 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 CrEv (site web personnel) le 23 février 2014 à 14:22. É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 Antoine le 23 février 2014 à 15:21. É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 KiKouN le 24 février 2014 à 14:32. É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 totof2000 le 24 février 2014 à 17:09. É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 GuieA_7 (site web personnel) le 28 février 2014 à 12:25. É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 Astaoth le 23 février 2014 à 13:35. É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.
  
  Emacs le fait depuis 30 ans.
  - [^] # Re: Manque un warning "indentation"
    
    Posté par potate le 23 février 2014 à 14:33. Évalué à 3.
    
    http://en.wikipedia.org/wiki/Off-side_rule#Off-side_rule_languages
    Ça inclue des langages de prog et de balisage.
- [^] # Re: Manque un warning "indentation"
  
  Posté par freem le 24 février 2014 à 11:24. É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 Blackknight (site web personnel, Mastodon) le 26 février 2014 à 15:05. É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
  - [^] # Re: Manque un warning "indentation"
    
    Posté par Zylabon le 26 février 2014 à 16:10. Évalué à 2.
    
    Comme lisp ?
    
    Please do not feed the trolls
    - [^] # Re: Manque un warning "indentation"
      
      Posté par Meku (site web personnel) le 26 février 2014 à 21:15. Évalué à 2.
      
      Ou Ada.
      - [^] # Re: Manque un warning "indentation"
        
        Posté par tyoup le 27 février 2014 à 08:42. Évalué à 3.
        
        ou Perl ?
        
        [^] # Re: Manque un warning "indentation"
        
        Posté par barmic le 04 mars 2014 à 23:19. Évalué à 2.
        
        Bon exemple, perl à une construction pour les cas léger/simple :
        
        i=1 if (cond);
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
      - [^] # Re: Manque un warning "indentation"
        
        Posté par Blackknight (site web personnel, Mastodon) le 28 février 2014 à 10:32. Évalué à 2.
        
        Touché :D
        En plus, comme on n'a pas le droit aux blocs vides sans le préciser au compilo, c'est rien que du bonheur :D
# Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés chez Apple…

Posté par Altor le 23 février 2014 à 11:57. É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 flagos le 23 février 2014 à 14:12. É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 Zenitram (site web personnel) le 23 février 2014 à 14:59. Évalué à -1. Dernière modification le 23 février 2014 à 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 Antoine le 23 février 2014 à 15:27. É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 Zenitram (site web personnel) le 23 février 2014 à 15:58. Évalué à 4. Dernière modification le 23 février 2014 à 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 Thomas Douillard le 23 février 2014 à 18:00. É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 barmic le 23 février 2014 à 22:41. É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 Thomas Douillard le 23 février 2014 à 22:54. É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 barmic le 24 février 2014 à 09:29. Évalué à 5.
        
        Pour moi quand on parle de « faire une analyse systématique du code », ce n'est pas lancer une fois un outil (par hasard ?) en se donnant pour objectif de supprimer tous les warnings qu'on voit. Ça c'est faire de l'analyse à l'arrache.
        
        « Faire une analyse systématique du code » ça n'est pas une question d'outil mais de workflow.
        
        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 Thomas Douillard le 24 février 2014 à 12:39. Évalué à 3.
        
        Pour moi aussi, ça tombe bien.
        
        [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés
        
        Posté par Gof (site web personnel) le 24 février 2014 à 00:26. É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 Albert_ le 24 février 2014 à 10:42. É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 Zenitram (site web personnel) le 24 février 2014 à 10:56. É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 flagos le 24 février 2014 à 14:32. É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 gouttegd (site web personnel) le 24 février 2014 à 15:41. É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 flagos le 24 février 2014 à 15:56. É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 claudex le 24 février 2014 à 18:48. Évalué à 3.
        
        Si c'est ca, il reporte upstream, et c'est au projet de voir ce qu'il fait de ce patch.
        
        C'est ce qu'il a fait sur une liste de diffusion du projet, il n'a eu aucun retour négatif.
        
        « 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: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés
        
        Posté par Zenitram (site web personnel) le 24 février 2014 à 18:51. Évalué à 3. Dernière modification le 24 février 2014 à 18:52.
        
        Mais pas positif non plus, et pas inclus chez eux non plus.
        Pour toi, une non réponse négative est un "allez-y les gars!"?
        Si l'upstream n'inclu pas tous les patchs directs sans se poser de question, ce n'est pas pour rien.
        
        [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés
        
        Posté par claudex le 24 février 2014 à 18:58. Évalué à 2.
        
        Si je me souviens bien, la réponse qu'il a eu, c'est « Je ne vois pas de problème », c'est quand même plutôt positif.
        
        « 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: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés
        
        Posté par flagos le 24 février 2014 à 19:03. Évalué à 3.
        
        C'est au projet d'intégrer son patch ou non, et le mainteneur attend une nouvelle release vérifiée et qualifiée, s'il ne peut pas faire lui même cette vérification.
        
        La il s'est juste fendu d'un mail ("hey les gars j'ai un warning"), pas de réponse, j'envoie quand même. Ca ne rend pas son patch vérifié et validé.
        
        [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés
        
        Posté par Moonz le 25 février 2014 à 10:05. Évalué à 5.
        
        En matière de sécurité, on a une obligation de résultat.
        
        Avec de tels principes je crois que tu peux désinstaller 99% des logiciels sur ta machine (allez, je te laisse cat, mais sans shell pour l’exécuter ça va être rigolo).
        
        [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés
        
        Posté par flagos le 25 février 2014 à 11:00. Évalué à 2.
        
        Ben tu as quoi ? SSL, SSH, les navigateurs, ftp, le kernel ? Les autres applis reposent beaucoup sur des libs qui assurent pour elles l'implémentation des choses sensibles… Au final, tu dois pas avoir masse de paquets un peu touchy.
        
        C'est moi qui idéalise ou bien ?
        
        [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés
        
        Posté par Moonz le 25 février 2014 à 15:36. Évalué à 2.
        
        La grande majorité des failles c’est pas dans des trucs « évidemment » sensibles, c’est des sprintf mal gérés par exemple, et ça arrive dans toutes les applications.
        
        D’autant plus que se linker à une lib qui fait les choses correctement ne garantit pas que tu utilises correctement la lib toi-même (gestion de l’IV/salt dans les opérations crypto par exemple).
        
        [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés
        
        Posté par xcomcmdr le 24 février 2014 à 18:29. É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 barmic le 24 février 2014 à 11:18. Évalué à 2.
        
        Tu illustre exactement ce que je dis là. 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 Thomas Douillard le 24 février 2014 à 12:44. É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 barmic le 24 février 2014 à 13:12. É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 Zenitram (site web personnel) le 24 février 2014 à 13:21. Évalué à 1. Dernière modification le 24 février 2014 à 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 Thomas Douillard le 24 février 2014 à 13:24. É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 Zenitram (site web personnel) le 24 février 2014 à 13:30. Évalué à -2. Dernière modification le 24 février 2014 à 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 Thomas Douillard le 24 février 2014 à 13:40. Évalué à 4.
        
        Faut pas confondre excuse et explication.
        
        [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés
        
        Posté par Albert_ le 24 février 2014 à 13:32. É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 Zenitram (site web personnel) le 24 février 2014 à 13:38. Évalué à -1. Dernière modification le 24 février 2014 à 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 totof2000 le 24 février 2014 à 17:28. É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 pasBill pasGates le 24 février 2014 à 18:05. É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 Zenitram (site web personnel) le 24 février 2014 à 18:47. Évalué à 3. Dernière modification le 24 février 2014 à 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 allcolor (site web personnel) le 24 février 2014 à 20:19. É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 totof2000 le 25 février 2014 à 10:56. É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 barmic le 25 février 2014 à 23:06. É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 totof2000 le 26 février 2014 à 10:53. É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 Zenitram (site web personnel) le 26 février 2014 à 11:03. Évalué à -2. Dernière modification le 26 février 2014 à 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 barmic le 26 février 2014 à 11:17. É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 Albert_ le 26 février 2014 à 11:31. É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 Zenitram (site web personnel) le 26 février 2014 à 11:37. É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 Albert_ le 26 février 2014 à 12:23. Évalué à 3. Dernière modification le 26 février 2014 à 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 barmic le 26 février 2014 à 15:49. É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 Albert_ le 26 février 2014 à 16:07. É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 barmic le 26 février 2014 à 16:15. É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 barmic le 26 février 2014 à 15:45. É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 Albert_ le 26 février 2014 à 16:10. Évalué à 0.
        
        Et cela ne te pose pas probleme?
        
        Et quand je vois ce genre de nouvelle je soupconne que tu te trompes et que "certains" clients de Apple sont "tres" legerement interesse par la securite.
        
        http://www.bloomberg.com/news/2013-05-17/apple-mobile-devices-approved-for-use-on-u-s-military-networks.html
        
        [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés
        
        Posté par barmic le 26 février 2014 à 16:17. Évalué à 1.
        
        Et cela ne te pose pas probleme?
        
        Tu n'a pas compris que je ne donne pas mon avis ? Je dis juste que Debian est sur un pied d'égalité avec Apple.
        
        Et quand je vois ce genre de nouvelle je soupconne que tu te trompes et que "certains" clients de Apple sont "tres" legerement interesse par la securite.
        
        Et elle a de la valeur cette vérification vue qu'elle laisse passer la qualité dont on parle ici ?
        
        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 totof2000 le 25 février 2014 à 10:55. É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 estvrai, cela tend a montrer que de mauvaises pratiques se sont banalisés
        
        Posté par Juke (site web personnel) le 25 février 2014 à 11:41. Évalué à 6.
        
        Rien à voir. Debian n'a pas la sécurité comme objectif principal affiché
        
        et Apple ?
        
        [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés
        
        Posté par barmic le 25 février 2014 à 22:59. Évalué à 2.
        
        Si on parle de sécurité par exemple, […]
        
        Ça veut dire quoi « parler de sécurité », il y a des cas où tu dis sincèrement la sécurité je m'en cogne ? C'est pas une fonctionnalité la sécurité, c'est pas un but au soit. Si ça l'était alors il suffit de ne rien faire (pas de fonctionnalité, pas de surface d'attaque, 100 % sécurisé).
        
        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 barmic le 24 février 2014 à 23:50. É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 totof2000 le 25 février 2014 à 10:47. É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 barmic le 25 février 2014 à 22:56. É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 groumly le 24 février 2014 à 13:40. É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 barmic le 24 février 2014 à 14:00. É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 diorcety le 23 février 2014 à 19:35. É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 Albert_ le 24 février 2014 à 16:14. Évalué à 0.
        
        Les lyncher cela serait pas mieux? Puis ca resterait dans le theme integriste/religieux.
        
        [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés
        
        Posté par fearan le 04 mars 2014 à 10:18. Évalué à 2.
        
        ah non pour ces cas la il faut les pendre deux fois, je les pends et les repens ;)
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés
        
        Posté par barmic le 23 février 2014 à 22:37. É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 claudex le 23 février 2014 à 22:55. Évalué à 6.
        
        Quand c'est de l'OpenSource on accepte que la qualité soit pas au rendez-vous.
        
        C'est de l'opensource aussi dans ce cas.
        
        uis on passe à autre chose
        
        Quand est-ce qu'on passe à autre chose ? Le problème qu'a eu Debian revient toujours sur le tapis actuellement et régulièrement.
        
        « 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: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés
        
        Posté par Albert_ le 24 février 2014 à 16:16. Évalué à 0.
        
        Tu n'a pas compris. Quand c'est de l'OpenSource on accepte que la qualité soit pas au rendez-vous.
        
        http://linuxfr.org/users/flagos/journaux/apple-le-ssl-les-goto-et-les-accolades#comment-1522335
        
        Et mon experience comme decrit dans le message "que tu ne comprends pas" et exactement l'inverse et etre beaucoup plus exigeant avec des benevoles qu'avec des professionels.
        
        [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés
        
        Posté par Moonz le 24 février 2014 à 09:26. Évalué à 9. Dernière modification le 24 février 2014 à 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 barmic le 24 février 2014 à 09:32. Évalué à 4.
        
        suivre des bonnes pratiques (éliminer des warning d’outils d’analyse)
        
        J'appelle pas ça une bonne pratique. Lorsqu'on a un warning il faut soit :
        
        configurer l'outil pour supprimer ce warning
        
        indiquer à l'outil que ce cas précis n'est pas un problème
        
        corriger le problème dans le code
        
        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 CrEv (site web personnel) le 24 février 2014 à 09:49. Évalué à 5.
        
        Le résultat final ce n'est pas justement d'éliminer ce warning ?
        
        [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés
        
        Posté par barmic le 24 février 2014 à 09:54. Évalué à 1.
        
        Ce n'est pas l'objectif. Si l'objectif c'est de supprimer le warning, tu commente le code et ça marche à tous les coups.
        
        L'objectif de l'analyse c'est de découvrir des bugs, pas de supprimer des warnings (c'est pas simple).
        
        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 CrEv (site web personnel) le 24 février 2014 à 09:58. Évalué à 5.
        
        Nan mais ce que je veux dire c'est qu'à mon avis ce que tu décris comme bonne pratique (ie comment traiter un warning) est ce qu'ils voulaient faire (même si ça c'est mal passé). C'est pas supprimer un warning pour supprimer un warning mais gérer le problème (et lorsqu'il n'est plus là le warning doit avoir disparu)
        
        [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés
        
        Posté par Albert_ le 24 février 2014 à 10:39. É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 Prosper le 24 février 2014 à 10:50. Évalué à 1.
        
        Alors que toi tu es tellement respectueux de tout ce qui se rapporte à Microsoft, Apple ou autres boites qui fait du proprio ….Mmmm wait
        
        [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés
        
        Posté par Albert_ le 24 février 2014 à 10:54. Évalué à -4. Dernière modification le 24 février 2014 à 10:57.
        
        Rassure moi, je suis bien sur linuxfr, non?
        
        J'ai eu peur deux secondes et j'ai cru que m'etre trompe de site et avoir atteri sur Applefr ou windowsfr…
        
        Si j'etais sur une des ces deux sites et que je me mette a insulter les utilisateurs de l'os en question comme le fais zenitram ou autre, je comprendrais de me faire jeter mais vois tu je ne vais JAMAIS sur ces sites la.
        
        ps: et puis tu va passer du temps pour trouver des insultes gratuites de ma part sur les utilisateurs.
        
        [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés
        
        Posté par Zenitram (site web personnel) le 24 février 2014 à 11:02. Évalué à -2.
        
        J'ai eu peur deux secondes et j'ai cru que m'etre trompe de site et avoir atteri sur Applefr ou windowsfr…
        
        En quoi ça te légitime à insulter les autres qui utilissent un autre OS?
        
        a insulter les utilisateurs de l'os en question comme le fais zenitram ou autre,
        
        C'est rigolo que le commentaire que tu pointes parle de "amateur de Linux ou pas".
        Mais bon, tu as dû mettre des oeilères et zapper ces 2 petits mots qui n'iraient pas dans ce que tu veux me faire dire…
        
        [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés
        
        Posté par Albert_ le 24 février 2014 à 11:05. Évalué à -1.
        
        Montre moi un seul poste ou j'insulte les utilisateurs de ces systemes.
        
        [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés
        
        Posté par groumly le 24 février 2014 à 13:42. Évalué à 4.
        
        Yen a tout plein ici:
        http://linuxfr.org/users/albert_/comments
        
        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 Albert_ le 24 février 2014 à 15:29. Évalué à -5.
        
        Ah tiens la apple fan qui vient troller ici quelle surprise.
        
        C'est joli de mettre un lien, c'est bien tu sais faire un copier coller de hyperlien. Dommage que tu ne puisses pas trouver un seul message ou j'insulte les utilisateurs d'un OS pour la seule et unique raison qu'ils utilisent cet OS.
        
        Tu sais que au lieu de manger des pommes tu devrais manger des carottes, il parait que cela rend aimable.
        
        [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés
        
        Posté par zebra3 le 24 février 2014 à 17:02. Évalué à 2.
        
        Dommage que tu ne puisses pas trouver un seul message ou j'insulte les utilisateurs d'un OS pour la seule et unique raison qu'ils utilisent cet OS.
        
        Ben pas besoin de chercher loin, je trouve que ça, ça ressemble à une insulte parce qu'il utilise des Mac :
        
        Tu sais que au lieu de manger des pommes tu devrais manger des carottes, il parait que cela rend aimable.
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés
        
        Posté par Albert_ le 24 février 2014 à 20:23. Évalué à -2.
        
        On parle des utilisateurs generiques pas des personnes qui m'insulte a chaque fois que je poste. Mais merci de me dire que des que je mange une pomme j'insulte un utilisateur Apple… C'est mon boss qui va etre content de savoir ca.
        
        [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés
        
        Posté par barmic le 24 février 2014 à 11:20. Évalué à 5.
        
        Rassure moi, je suis bien sur linuxfr, non?
        
        Donc ça interdit toute autocritique et ça oblige à considérer les autres comme méchants et les libristes comme gentils ?
        
        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 Reihar le 24 février 2014 à 11:44. Évalué à 1.
        
        http://applefr.org
        
        [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés
        
        Posté par Reihar le 24 février 2014 à 11:43. Évalué à -1. Dernière modification le 24 février 2014 à 11:44.
        
        Edit : Je me suis bêtement trompé de bouton répondre. Un modo peut il supprimer ce message ?
        
        [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés
        
        Posté par Zenitram (site web personnel) le 24 février 2014 à 11:00. Évalué à 1. Dernière modification le 24 février 2014 à 11:03.
        
        Bla bla on sait que tu destestes tout ce qui se rapporte a linux
        
        Ah le beau fanboy… Une critique, et te voila "qui déteste".
        Quelqu'un "qui de déteste pas" ne doit jamais oh grand jamais emettre la moindre critique.
        Triste monde binaire où dès que tu oses faire la moindre critique te voilà "qui déteste".
        
        Désolé de te décevoir, je ne déteste pas et j'utilise même Linux et ton commentaire est pure invention juste pour ne pas discuter du sujet. Aux dernières nouvelles, j'ai un très bon contact avec mon packageur Debian, mais tu peux toujours lui poser la question si tu ne me crois pas (mais bon, il est moins bianire que toi, pire il est aussi packageur de la distro du mal qu'est Ubuntu).
        
        [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés
        
        Posté par Albert_ le 24 février 2014 à 11:03. Évalué à -3. Dernière modification le 24 février 2014 à 11:06.
        
        Tu veux dire que c'est ta premiere critique sur linux et l'ecosysteme libre?
        
        En est tu vraiment certain?
        
        Je vais te rafraichir la memoire:
        
        http://linuxfr.org/users/elessar/journaux/debian-adopte-systemd-comme-init-par-defaut#comment-1520662
        
        edit: je te laisse troller et m'insulter j'ai un peu autre chose a faire qu'a perdre mon temps avec toi.
    - [^] # Re: Si tout cela est vrai, cela tend a montrer que de mauvaises pratiques se sont banalisés
      
      Posté par groumly le 23 février 2014 à 21:23. É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 gentildemon le 24 février 2014 à 22:43. É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 Zenitram (site web personnel) le 25 février 2014 à 07:17. Évalué à -10. Dernière modification le 25 février 2014 à 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 CrEv (site web personnel) le 25 février 2014 à 08:51. É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 groumly le 25 février 2014 à 09:58. É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 flagos le 25 février 2014 à 10:04. Évalué à 10. Dernière modification le 25 février 2014 à 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 woprandi le 26 février 2014 à 00:24. Évalué à 4.
        
        Tu deviens vraiment fatiguant là
# Code défensif

Posté par Xaapyks le 23 février 2014 à 13:42. É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 flagos le 23 février 2014 à 14:16. É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 dave_null (site web personnel) le 23 février 2014 à 16:12. Évalué à 10.
    
    Il y a des fusées qui ont explosées pour moins que ça.
  - [^] # Re: Code défensif
    
    Posté par Gof (site web personnel) le 23 février 2014 à 16:36. É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 chimrod (site web personnel) le 23 février 2014 à 18:04. É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 Gof (site web personnel) le 23 février 2014 à 22:06. É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 chimrod (site web personnel) le 24 février 2014 à 06:45. Évalué à 1. Dernière modification le 24 février 2014 à 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 Gof (site web personnel) le 24 février 2014 à 10:35. É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 mael le 24 février 2014 à 13:48. É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 gnx le 24 février 2014 à 14:36. É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 freem le 24 février 2014 à 15:03. É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 Gof (site web personnel) le 24 février 2014 à 15:13. É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 moi1392 le 24 février 2014 à 15:55. É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 Gof (site web personnel) le 24 février 2014 à 16:27. É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 moi1392 le 24 février 2014 à 16:47. É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 Gof (site web personnel) le 24 février 2014 à 23:59. Évalué à 2. Dernière modification le 25 février 2014 à 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 CrEv (site web personnel) le 24 février 2014 à 16:48. É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 Gof (site web personnel) le 25 février 2014 à 00:23. É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 CrEv (site web personnel) le 25 février 2014 à 08:33. É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.