Gof a écrit 2224 commentaires

Déjà, bitcoin est fait pour des payements sur internet. Mais c'est vrai que rien n'empêche d'acheter une baguette.

Pour avoir déjà payer des bières en bitcoins, le dialogue est plutôt comme ça:

• Bonjour, je voudrais une baguette
• Voici, ça fait 1,5 €, comment voulez vous payer ? Cash ou bitcoin ?
• bitcoins s'il vous plait.

la boulangère appuie sur un bouton et montre un QR code avec la tablette. Le client scanne avec son smartphone et vois sur l'écran: « Payer xxx BTC = 1,5 € à xxxx. » Il clique sur « accepter » et 2 secondes plus tard, la boulangère vois sur son écran que le payement est accepté.

• Merci beaucoup et au revoir
• Au revoir et merci.

En même temps, les bitcoins ne représentent pas toute la richesse mondiale.

Bill Gates est plus riche que tous les bitcoins réunis. Et pourtant tu utilises Windows. Donc tu cautionnes pas le système ?

Ce qui me gêne, par contre, avec Bitcoin, c'est l'avantage déraisonnable qui est donné aux premiers entrants.

En quoi ça te gène ? Tu es jaloux ?
Ils ont su dans quoi investir et il y a aussi une part de chance.

Toi aussi tu pouvais investir au début, lorsque il y a eu une news sur linuxfr. Mais tu ne l'as pas fait, pourquoi ?

C'est comme les premiers qui ont investits dans Apple et Microsoft.
Ou un autre extrême, ceux qui gagne au lotto.

Le truc c'est que bitcoin n'est que une technologie. Il est possible de bâtir des des banques, des assurances et tout ça par dessus. Il y en a déjà qui se lancent, et ce n'est que le début.

À partir du moment ou les clients ont des comptes sur lesquels il déposent de l'argent, c'est un peu comme une banque, non?

Déjà, Mt.Gox n'a pas encore déclaré failitte, ils ont fait une demande pour une protection de faillite. Je ne connais pas le droit japonais, mais ça veux dire qu'ils ne sont pas obligés de payer leur dette le temps de mettre au point les finances.

Si je me souviens bien, c'est un peu comparable à ce qui est arivé à Mandrakesoft en 2002. Et on n'a pas déclaré que Linux était mort pour autant. Car oui, Mtgox n'est que une des entreprise autour de bitcoins, il y en a plein d'autres. Et donc le succès de bitcoin ne dépends pas d'une seule entreprise.

Car dans ton journal tu critique Bitcoin car MtGox à fait une bourde, mais tu ne peux pas extrapoler comme ça.

Pour les 700-800K bitcoins qui ont "disparus", on ne sait pas exactment si ils ont été perdus, volés, ou confisqués. Quoi qu'il en soit, il semblerais que l'entreprise ait fait part de négligence.

Est-ce que les autres plate-formes seront crédibles quand elles disent que c'est que la faute de l'autre?

Bah oui, puisque c'est la faute de l'autre.

Espérons que ça serve de leçon :

La leçon c'est que quand on dépose son argent dans une banque ou un site d'échange, il faut avoir confiance en ce dernier.

Par exemple, utiliser un échange sérieux comme https://bitcoin.de qui est en partenaria avec FIDOR Bank, une vrai banque avec de vrais assurances en cas de faillite, et une vrai protection des clients.
Il y a aussi le site français https://bitcoin-central.net qui à l'air sérieux.

virus qui commencent à se balader qui ont pour objectif de voler les Bitcoin de l'utilisateur

Ça montre juste le succès de bitcoin :-) Il y a des virus qui se balade pour voler les comptes paypals et les numéro de carte de crédit aussi. Et les Ransomware n'ont rien de nouveau.

il ne serait pas plus sain d'avoir un mot clé, je ne sais pas «nooverload», pour justement garantir à l'utilisateur que l'API est stable en terme d'overload, et qu'il peut faire des pointeurs de fonction de manière stable?

Tu peux rajouter dans ton .h

static_assert(&func, "This function should not have overloads");

Oui exactement.
Ajouter des overload n'est pas compatible source.

Autre exemple:

void func(Foo*);

///...
    func(0);

Si je rajoute un overload je peux avoir des erreur. (si on rajoute func(Bar*) on a un appel ambigu (erreur de compilation), si on rajoute func(int) une autre fonction est appelée (possible bug))

Ce qui aurais été bien aurais été de pouvoir utilisé attemptMessage dans bind directement comme ça:

repeatedly<ReadAccess>(bind(&QMailStore::attemptMessage, this, cref(id), &msg), "message(id)");

Mais ça ne marche pas car attemptMessage est overloadé et donc il faut faire un case explicite vers le bon type pour résoudre quelle overload on prends. Par example, ce qui est fait dans le code original.

Est-ce ce qu'il n'est vraiment pas spossible de faire tout ça plus simplement?

Si c'est possible, en utilisant C++11. Avec une fonction lambda, on peu se passer de bind:

repeatedly<ReadAccess>([&](MailStoreReadLock& l){ this->attemptMessage(id, &msg, l); },
                       "message(id)");

En mars 2011, Qt est cédé à Digia ;

C'est en avance de plus d'un an. C'est seulement en Septembre 2012 que Qt est cédé à Digia[1].
En mars 2011 Digia devient juste le revendeur officiels de la licence commerciale. Nokia reste propriétaire de Qt et continue son développement jusqu'en été 2012.

[1] http://qt.digia.com/About-Us/News/Digia-to-Acquire-Qt-from-Nokia/

Est-ce que c'est bien la définition locale d'un pointeur de fonction qui prends trois arguments et qui pointe sur l'adresse de la fonction attemptMessage ?

Presque.
C'est la définition locale d'un pointeur vers une fonction membre qui prends trois argument et qui pointe vers QMailStore::attemptMessage.

comment le compilateur c++ sait de quelle méthode attemptMessage il faut retrouver l'adresse

Vu que tu assignes vers un un pointeur qui a 3 arguments, il sait quelle overload choisir.

Ça serait magique

Juste du C++ :-)

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

https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby8

It's going to be an awful lot of work, with the result that not all systems will be supported, new bugs introduced and what's the gain for the end user exactly?
Total refactoring is not a solution. It's much better to improve what we have. Perhaps with some small refactorings specifically aimed at making Vim work better for users.

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

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.

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.

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.

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.

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.

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

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.

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.

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

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

Pourquoi pas break ou goto ? :-)