Apple règle le bug Telugu, Réactions à la publication du 20/02/2018

[Lionel]

En fin de semaine dernière on apprenait que des caractères Telugu pouvaient faire planter nombre d'applications sur la plupart des systèmes d'exploitation d'Apple.

Pendant le week-end, des attaques malveillantes avaient commencé à se produire, en particulier via Twitter, cherchant à faire planter les produits Apple.
La société vient de réagir en proposant au public iOS 11.2.6, watchOS 4.2.3, tvOS 11.2.6, et macOS High Sierra 10.13.3 (supplémentaire) qui corrigent ce problème.


Lien vers le billet original

[ericb2]

@gigatoaster

Pour parler d'OpenOffice que je connais, la plupart du temps, ce sont des problèmes remontés par les utilisateurs. En effet, plus le nombre d'utilisateurs est important, et plus il est probable que quelqu'un passe par le cas qui pose problème. Mais ce n'est pas la seule possibilité. Une autre façon de trouver des bugs, c'est par exemple en créant des fichiers "corrompus" avec une méthode donnée. Exemple : dans un fichier .odt, on ajoute du bruit dedans, de façon aléatoire. Ensuite, on essaye de l'ouvrir et de l'utiliser. C'est ce que faisant thb pour les fichiers Impress. ça a plutôt bien fonctionné, car il a trouvé quelques problèmes sérieux de cette façon (et dont la résolution ne fût pas si simple).

@Lionel : au sujet de "corriger le bug avant qu'il ne se reproduise", je me permets d'ajouter que la plus grosse difficulté de celui qui essaye de corriger est d'arriver à faire la différence entre le quoi (le "what") et le pourquoi (le "why" ). Corriger le what revient à mettre un pansement sur une jambe de bois, et on n'a rien corrigé. Et on n'est jamais sûr d'avoir vraiment corrigé le why. Souvent parce que le plus difficile est de comprendre le mécanisme du bug, de le reproduire avec certitude, et d'en donner une solution qui n'amène pas d'autres problèmes.

Pour citer un cas d'école (c'est rarement aussi simple, mais l'exemple qui suit est symbolique): si dans mon code, je trouve un pointeur NULL (une adresse non définie)**, que fais-je la plupart du temps ?

1. si l'adresse n'est pas définie, je n'exécute pas un bloc donné ?

2. j'essaye de savoir pourquoi cette valeur n'est pas définie (et je corrige, bien sûr) ?

**En C, dans un programme quand on a une adresse égale à 0, c'est qu'on a oublié de la définir. C'est comme si on envoyait du courrier à quelqu'un mais sans mettre l'adresse sur l'enveloppe, alors que le contenu est bien dans l'enveloppe. Lors de la création du binaire, le compilateur est sympa, il nous prévient avec un avertissement ("warning") qu'une adresse n'est pas définie et lui attribue la valeur zéro. En fonctionnement, quand on essaye d'écrire à l'adresse 0 (notée 0x0) on n'a pas le droit, et ça donne un "crash" : le programme s'arrête. Celui qui débugue, teste toujours si quelque chose vaut 0 ou pas (c'est la base).

Edit : typos


--
qɔᴉɹə
L'association EducOOo : http://www.educoo.org
https://github.com/ebachard

Ce message a été modifié par ericb2 - 20 Feb 2018, 08:50.

[ungars]

@gigatoaster

Pour parler d'OpenOffice que je connais, la plupart du temps, ce sont des problèmes remontés par les utilisateurs. En effet, plus le nombre d'utilisateurs est important, et plus il est probable que quelqu'un passe par le cas qui pose problème. Mais ce n'est pas la seule possibilité. Une autre façon de trouver des bugs, c'est par exemple en créant des fichiers "corrompus" avec une méthode donnée. Exemple : dans un fichier .odt, on ajoute du bruit dedans, de façon aléatoire. Ensuite, on essaye de l'ouvrir et de l'utiliser. C'est ce que faisant thb pour les fichiers Impress. ça a plutôt bien fonctionné, car il a trouvé quelques problèmes sérieux de cette façon (et dont la résolution ne fût pas si simple).

@Lionel : au sujet de "corriger le bug avant qu'il ne se reproduise", je me permets d'ajouter que la plus grosse difficulté de celui qui essaye de corriger est d'arriver à faire la différence entre le quoi (le "what") et le pourquoi (le "why" ). Corriger le what revient à mettre un pansement sur une jambe de bois, et on n'a rien corrigé. Et on n'est jamais sûr d'avoir vraiment corrigé le why. Souvent parce que le plus difficile est de comprendre le mécanisme du bug, de le reproduire avec certitude, et d'en donner une solution qui n'amène pas d'autres problèmes.

Pour citer un cas d'école (c'est rarement aussi simple, mais l'exemple qui suit est symbolique): si dans mon code, je trouve un pointeur NULL (une adresse non définie)**, que fais-je la plupart du temps ?

1. si l'adresse n'est pas définie, je n'exécute pas un bloc donné ?

2. j'essaye de savoir pourquoi cette valeur n'est pas définie (et je corrige, bien sûr) ?

**En C, dans un programme quand on a une adresse égale à 0, c'est qu'on a oublié de la définir. C'est comme si on envoyait du courrier à quelqu'un mais sans mettre l'adresse sur l'enveloppe, alors que le contenu est bien dans l'enveloppe. Lors de la création du binaire, le compilateur est sympa, il nous prévient avec un avertissement ("warning") qu'une adresse n'est pas définie et lui attribue la valeur zéro. En fonctionnement, quand on essaye d'écrire à l'adresse 0 (notée 0x0) on n'a pas le droit, et ça donne un "crash" : le programme s'arrête. Celui qui débugue, teste toujours si quelque chose vaut 0 ou pas (c'est la base).

Edit : typos


--
qɔᴉɹə
L'association EducOOo : http://www.educoo.org
https://github.com/ebachard

Mais alors la faille est dans le compilateur C, qui devrait terminer en erreur.

[roseau]

@gigatoaster

Pour parler d'OpenOffice que je connais, la plupart du temps, ce sont des problèmes remontés par les utilisateurs. En effet, plus le nombre d'utilisateurs est important, et plus il est probable que quelqu'un passe par le cas qui pose problème. Mais ce n'est pas la seule possibilité. Une autre façon de trouver des bugs, c'est par exemple en créant des fichiers "corrompus" avec une méthode donnée. Exemple : dans un fichier .odt, on ajoute du bruit dedans, de façon aléatoire. Ensuite, on essaye de l'ouvrir et de l'utiliser. C'est ce que faisant thb pour les fichiers Impress. ça a plutôt bien fonctionné, car il a trouvé quelques problèmes sérieux de cette façon (et dont la résolution ne fût pas si simple).

@Lionel : au sujet de "corriger le bug avant qu'il ne se reproduise", je me permets d'ajouter que la plus grosse difficulté de celui qui essaye de corriger est d'arriver à faire la différence entre le quoi (le "what") et le pourquoi (le "why" ). Corriger le what revient à mettre un pansement sur une jambe de bois, et on n'a rien corrigé. Et on n'est jamais sûr d'avoir vraiment corrigé le why. Souvent parce que le plus difficile est de comprendre le mécanisme du bug, de le reproduire avec certitude, et d'en donner une solution qui n'amène pas d'autres problèmes.

Pour citer un cas d'école (c'est rarement aussi simple, mais l'exemple qui suit est symbolique): si dans mon code, je trouve un pointeur NULL (une adresse non définie)**, que fais-je la plupart du temps ?

1. si l'adresse n'est pas définie, je n'exécute pas un bloc donné ?

2. j'essaye de savoir pourquoi cette valeur n'est pas définie (et je corrige, bien sûr) ?

**En C, dans un programme quand on a une adresse égale à 0, c'est qu'on a oublié de la définir. C'est comme si on envoyait du courrier à quelqu'un mais sans mettre l'adresse sur l'enveloppe, alors que le contenu est bien dans l'enveloppe. Lors de la création du binaire, le compilateur est sympa, il nous prévient avec un avertissement ("warning") qu'une adresse n'est pas définie et lui attribue la valeur zéro. En fonctionnement, quand on essaye d'écrire à l'adresse 0 (notée 0x0) on n'a pas le droit, et ça donne un "crash" : le programme s'arrête. Celui qui débugue, teste toujours si quelque chose vaut 0 ou pas (c'est la base).

Edit : typos


--
qɔᴉɹə
L'association EducOOo : http://www.educoo.org
https://github.com/ebachard

Mais alors la faille est dans le compilateur C, qui devrait terminer en erreur.

un compilateur ça compile , il contrôle la syntaxe par rapport à une grammaire, il ne detectera jamais une erreur de logique