protection mémoire
-
a) Le prinptemps arrive… faut jeter les vieux trucs!
b) rah Fab! arrête avec ton histoire de pile que tu nous ressors à tous les posts :-p
Il est facile de trouver des applis où il est impossible de savoir la pile consommée à un moment t de son exécution.
Le cas simple (et je le connait bien pour cause…) est le langage de script où le programeur du langage ne peut pas connaitre à l’avance ce le l’utilisateur va en faire… et ce dernier ne va pas s’occuper de savoir ce qu’est la pile, puisque l’actraction du langage donné le cache.
Un simple exemple récursif peut faire exploser une pile.
Certe on peut répondre à cela que les programeurs (qq soit le niveau auquel il accéde au-dit langage) n’ont qu’à faire que de l’itératif… mais n’est-ce pas un peu restrictif et exagéré?
c) une protection mémoire fiable doit se faire de façon hard, on est tous d’accord.
Pour maintenant ordonner les protections existantes que faire? simplement se poser la question: que voulons-nous protéger dans la mémoire?
Fab (encore…) a lancé le mot au début « statistiquement »: nous ne sommes pas obligé de tout protéger donc. Cela me permet de dire: il n’y a pas de bonnes ou de mauvaises protections, tout dépend de se qu’on en attend (un peu comme les OS tient
)d) j’ai mal aux dents
non rien (trompage de thread)
Le cas simple (et je le connait bien pour cause…) est le langage de script où le programeur du langage ne peut pas connaitre à l’avance ce le l’utilisateur va en faire… et ce dernier ne va pas s’occuper de savoir ce qu’est la pile, puisque l’actraction du langage donné le cache.
Très mauvais exemple puisque c’est exactement le cas où il doit n’y avoir aucun problème.
L’interpréteur du script connait sa propre implémentation, la pile qu’il utilise pour exécuter le script et la manière de l’étendre au moment opportun. Et s’il n’y a plus de mémoire, il arrête l’exécution ou fait échouer le truc en cours.
Dans tous les autres cas, c’est un bug quelque soit l’OS.
henes a écrit :
Très mauvais exemple puisque c’est exactement le cas où il doit n’y avoir aucun problème.
L’interpréteur du script connait sa propre implémentation, la pile qu’il utilise pour exécuter le script et la manière de l’étendre au moment opportun. Et s’il n’y a plus de mémoire, il arrête l’exécution ou fait échouer le truc en cours.
Dans tous les autres cas, c’est un bug quelque soit l’OS.
Ah mais tu pars donc du prostula: « Totale abstraction ».
Ce qui n’est pas une obligation… et personne ne l’impose.
Là tu dis « si une exception arrive au bas niveau elle ne doit pas être vu par l’utilisateur »
Autant tu défends le principe codeur=responsable.
Moi j’ajoute tous=responsable.
Ansi l’exemple devient bon. Car le fait que l’utilisateur voir le pb, lui permet de corriger le pb. Sans cela il ne devient pas responsable car c’est par l’erreur que l’on apprend.
Je suis donc pour garder l’erreur de dépassement de pile
PS: justement gérer la pile dynamiquement c’est pas toi qui disais que c’était « beurk » ?
PPS: et puis c’est pas MOS pour ne citer que lui qui permet de géré « facilement » un dépassement de pile… ça plante et puis c’est tout. Bug OS ?
Si tu veux garder l’erreur alors il faut au moins que l’interpréteur vérifie la pile restante et avertisse l’utilisateur, plutôt que de crasher comme une merde
Et une fois que c’est fait, étendre la pile prend 2 lignes de toute façon…
Et cela permet de changer l’implémentation de l’interpéteur un jour.
PS: gérer la pile dynamiquement dans une chaîne maîtrisée de A à Z montre que l’on n’a aucune idée de ce que l’on fait. Mais ce n’est pas le cas ici.
PPS: pas compris.
PPPS: un algorithme récursif est un bug dans la majorité des cas
henes a écrit :
PS: gérer la pile dynamiquement dans une chaîne maîtrisée de A à Z montre que l’on n’a aucune idée de ce que l’on fait. Mais ce n’est pas le cas ici.
juger n’est pas démontrer
henes a écrit :
PPS: pas compris.
pas grave
PPPS: un algorithme récursif est un bug dans la majorité des cas
certe, je ne dit pas l’inverse… je n’aime juste pas le totalitarisme, majorité != totalité
henes a écrit :
juger n’est pas démontrer
C’est juste un fait, rhoo.
Dans un truc dont on connait les paramètres d’entrée et l’implémentation, il est possible de calculer ou de mesurer la pile utilisée, une fois pour toute. Pas besoin d’ensuite la tester de partout…
ouai certe, mais c’est bon que pour des petits programmes ça.
A oublier quand on gére un soft en dev. depuis 10 ans et où plus de 500 developpeurs sont passés dessus. Ce genre de cas, le « on connait » n’est plus aussi simple.
De plus je ne parle même pas de la quantité de paramètres d’entrée/sortie.
Donc Henes… oui il y a des solutions pour tous problèmes.
Non il n’y a pas de solution unique à tous problèmes
… sinon il n’y aurait plus de job en info!
baaaah tas de gamins !
Encore encore !
- Vous devez être connecté pour répondre à ce sujet.
