Et pourquoi dans des cas aussi simples ne pas faire de warning pour avertir, sans optimiser?
Parce que la plupart du temps le compilateur a raison de supprimer le code. Sauf quand il a tort. Il ne va pas faire un warning pour chaque boucle simple qu'il optimise, sinon on est pas rendu (mais on peut lui dire de générer un rapport si on veut savoir ce qu'il a fait ...). Dans le cas de la fonction qui agit sur un mot de passe, je dirais que 9 fois sur 10, le memset est réellement inutile car il ne s'agit pas de code ni de données sensibles.
Est-ce car les cas réels ne sont pas aussi simples?
Je me sers d'une boucle à peine plus compliquée que la première donnée pour faire des micro-benchmarks (j'accumule dans une variable acc que j'affecte ensuite à un pointeur pacc pour empêcher le compilateur de supprimer le code).
Concernant le deuxième exemple, je l'ai emprunté à Marc Espie, qui s'en servait sur fr.comp.lang.c pour donner un exemple de suppression automagique (car memset est une fonction standard, donc le compilateur « sait » comment elle fonctionne, quand il peut se permettre de la virer, etc.) de code de la part de gcc. C'est un « vrai » code dans le sens où je pense qu'il est légitime de vouloir nettoyer la mémoire quand on est un peu obsédé niveau sécurité.
Dans la vraie vie, avec des codes réels, il y a plein de cas où le compilateur supprime avec raison tout un tas de trucs en se disant « au final c'est pareil ». Sauf quand c'est pas vrai.
[^] # Re: Je ne comprends pas
Posté par lasher . En réponse à la dépêche Exploit local dans le noyau Linux 2.6.30. Évalué à 3.
Parce que la plupart du temps le compilateur a raison de supprimer le code. Sauf quand il a tort. Il ne va pas faire un warning pour chaque boucle simple qu'il optimise, sinon on est pas rendu (mais on peut lui dire de générer un rapport si on veut savoir ce qu'il a fait ...). Dans le cas de la fonction qui agit sur un mot de passe, je dirais que 9 fois sur 10, le memset est réellement inutile car il ne s'agit pas de code ni de données sensibles.
Est-ce car les cas réels ne sont pas aussi simples?
Je me sers d'une boucle à peine plus compliquée que la première donnée pour faire des micro-benchmarks (j'accumule dans une variable acc que j'affecte ensuite à un pointeur pacc pour empêcher le compilateur de supprimer le code).
Concernant le deuxième exemple, je l'ai emprunté à Marc Espie, qui s'en servait sur fr.comp.lang.c pour donner un exemple de suppression automagique (car memset est une fonction standard, donc le compilateur « sait » comment elle fonctionne, quand il peut se permettre de la virer, etc.) de code de la part de gcc. C'est un « vrai » code dans le sens où je pense qu'il est légitime de vouloir nettoyer la mémoire quand on est un peu obsédé niveau sécurité.
Dans la vraie vie, avec des codes réels, il y a plein de cas où le compilateur supprime avec raison tout un tas de trucs en se disant « au final c'est pareil ». Sauf quand c'est pas vrai.