Le bogue du 0 - Page 1

0 0 0 0 0

Hmm moche... Corrigé !

Merci !

C'était quoi exactement ce bogue ? Je voyais rien dans le post initial, hier ^

Bah, c'était justement ça le bogue !
La mise en forme sur un zéro le faisait disparaître.

C'était causé par une superbe feature de PHP qui a des comportements assez piégeux lors des conversions de type. Quand on fait if ($machin), la chaine de caractère '0' est considérée comme équivalente au booléen false (parce que considérée comme égale, au type près, au nombre 0 qui lui-même est équivalent à false). D'habitude j'utilise uniquement des comparaisons strictes pour éviter de tomber dans ce genre de piège, mais dans la partie qui s'occupe de la mise en forme des sujets il y avait un petit oubli. Le code qui vérifie s'il y a du texte à l'intérieur d'une balise (sinon inutile de la rendre) ressemblait à $text ? '<b>' . $text . '</b>' : '' donc quand le texte était '0' la balise était ignorée.

Un bien beau langage que voilà

chapo d'avoir trouvé ca si vite O_o

Boh, on en est plus à l’irrégularité près avec PHP

Heureusement que Flanker est en train de réécrire yN en Python !!!

(merci pour l'explication ^^ )

et la ce sera le bug du 0² !

"le", tu plaisantes, il en trouve des kilos

N'importe quoi, on ne vous a pas parlé du projet top secret sur lequel je travaille, yN++ en C++/Qt sous licence Affero GPL?

Ah mince, maintenant que j'en ai parlé, ce n'est plus un secret, donc le projet est annulé, désolé.

(Attention, le post ci-dessus n'est pas à prendre au sérieux. yN++ n'existe pas, malheureusement. )

Ouf, pendant un moment j'y ai presque cru !

Zeph (./13) :
Ouf, pendant un moment j'y ai presque cru !

Ça ne vaut pas, toi, tu es au courant des secrets derrière yN.

Kevin Kofler (./12) :
(Attention, le post ci-dessus n'est pas à prendre au sérieux. yN++ n'existe pas, malheureusement. )

Dommage ! Il y aurait eu pléthore de buffer overflows, on aurait pu rooter le serveur, décompiler le code et enfin découvrir à quoi servent ces mystérieux gems

kernel ou nostub?

Les buffer overflows, on n'en a généralement que si on code en C ou si on code en C++ comme si c'était du C. Si tu n'utilises que des QByteArray et QString qui s'agrandissent dynamiquement avec append, tu ne vas jamais déborder.

Apparemment Qt est codé comme si c'était du C alors :
http://lists.qt-project.org/pipermail/announce/2015-April/000067.html
« The issues exposed included denial of service and buffer overflows leading to heap corruption. It is possible the latter could be used to perform remote code execution. »

Moralité, à partir du moment ou le langage n'est pas memory safe, même avec la meilleure volonté du monde il peut y avoir des bugs, donc des buffer overflows, donc des serveurs troués.

surtout dans un univers non-managé

Ce sont des débordements en lecture, ça va planter l'application et c'est tout. Et c'est dans du code très bas niveau, les chargeurs d'image, qui travaillent directement sur des buffers.

enlarge your string

squalyl (./22) :
enlarge your string

</thread>