Je ne parle pas de libérer ce qui a été alloué par une autre. Le problème dont je parle est qu'il fallait libérer explicitement tout ce qui avait été alloué par une DLL parce à la fin de l'exécution d'un programme, la mémoire associée à la DLL n'était pas libérée comme sur un OS digne de ce nom.
Je parle d'un rapport de bug suivi d'une entrée dans la KB Microsoft. J'ai retrouvé hier soir dans mes notes que le truc a été patché dans la libcrt de VC++ version 6, mais je n'ai pas retrouvé le numéro de KB. Dès que je remets la main dessus (je n'ai pas que ça à faire), je te l'envoie.
Je ne vois pas trop de quoi vous parlez avec tout cela, mais cela me fait penser à mon logiciel médical HelloDoc dont la version 5.60, tourne à l'évidence sous des biblio de microsoft bien merdique, et je me retrouve avec des plantage de la MFC 80 en veux-tu en voilà ! C'est du lourdingue.
J'attends toujours la référence qui pourrait me convaincre que JKB a fait autre chose que de raconter n'importe quoi.
Mais pourquoi considères tu qu'un plantage dans une bibliothèque est lié à cette bibliothèque, et non à ces appelants ?
Dans le principe, si l'appelant fait une demande bugguée, la bibliothèque "ne doit pas" planter ! Et là, "d'après le message d'erreur", c'est bien la bibliothèque qui cesse de fonctionner.
C'est pas très sérieux tout çà ...
Oui, bon, mais il y a des trucs plus rigolos avec les MFC... Des fonctions qui ne renvoient pas d'erreur alors qu'elles devraient. C'est particulièrement criant dans les fonctions winsock2 qui se comportent différemment sous XP, 2008R2 et W7.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Mon, 30 Jan 2012 08:44:35 +0100,
PP <000pipantal@free.fr000> écrivait :
Le 29/01/2012 20:50, Manuel Leclerc a écrit :
Le 29/01/2012 18:56, PP a écrit :
Le 18/01/2012 11:02, JKB a écrit :
Je ne parle pas de libérer ce qui a été alloué par une autre.
Le problème dont je parle est qu'il fallait libérer explicitement
tout ce qui avait été alloué par une DLL parce à la fin de
l'exécution d'un programme, la mémoire associée à la DLL n'était pas
libérée comme sur un OS digne de ce nom.
Je parle d'un rapport de bug suivi d'une entrée dans la KB
Microsoft. J'ai retrouvé hier soir dans mes notes que le truc a été
patché dans la libcrt de VC++ version 6, mais je n'ai pas retrouvé
le numéro de KB. Dès que je remets la main dessus (je n'ai pas que
ça à faire), je te l'envoie.
Je ne vois pas trop de quoi vous parlez avec tout cela, mais cela me
fait penser à mon logiciel médical HelloDoc dont la version 5.60, tourne
à l'évidence sous des biblio de microsoft bien merdique, et je me
retrouve avec des plantage de la MFC 80 en veux-tu en voilà !
C'est du lourdingue.
J'attends toujours la référence qui pourrait me convaincre que JKB a
fait autre chose que de raconter n'importe quoi.
Mais pourquoi considères tu qu'un plantage dans une bibliothèque est lié
à cette bibliothèque, et non à ces appelants ?
Dans le principe, si l'appelant fait une demande bugguée, la
bibliothèque "ne doit pas" planter ! Et là, "d'après le message
d'erreur", c'est bien la bibliothèque qui cesse de fonctionner.
C'est pas très sérieux tout çà ...
Oui, bon, mais il y a des trucs plus rigolos avec les MFC... Des
fonctions qui ne renvoient pas d'erreur alors qu'elles devraient.
C'est particulièrement criant dans les fonctions winsock2 qui se
comportent différemment sous XP, 2008R2 et W7.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Je ne parle pas de libérer ce qui a été alloué par une autre. Le problème dont je parle est qu'il fallait libérer explicitement tout ce qui avait été alloué par une DLL parce à la fin de l'exécution d'un programme, la mémoire associée à la DLL n'était pas libérée comme sur un OS digne de ce nom.
Je parle d'un rapport de bug suivi d'une entrée dans la KB Microsoft. J'ai retrouvé hier soir dans mes notes que le truc a été patché dans la libcrt de VC++ version 6, mais je n'ai pas retrouvé le numéro de KB. Dès que je remets la main dessus (je n'ai pas que ça à faire), je te l'envoie.
Je ne vois pas trop de quoi vous parlez avec tout cela, mais cela me fait penser à mon logiciel médical HelloDoc dont la version 5.60, tourne à l'évidence sous des biblio de microsoft bien merdique, et je me retrouve avec des plantage de la MFC 80 en veux-tu en voilà ! C'est du lourdingue.
J'attends toujours la référence qui pourrait me convaincre que JKB a fait autre chose que de raconter n'importe quoi.
Mais pourquoi considères tu qu'un plantage dans une bibliothèque est lié à cette bibliothèque, et non à ces appelants ?
Dans le principe, si l'appelant fait une demande bugguée, la bibliothèque "ne doit pas" planter ! Et là, "d'après le message d'erreur", c'est bien la bibliothèque qui cesse de fonctionner.
C'est pas très sérieux tout çà ...
Oui, bon, mais il y a des trucs plus rigolos avec les MFC... Des fonctions qui ne renvoient pas d'erreur alors qu'elles devraient. C'est particulièrement criant dans les fonctions winsock2 qui se comportent différemment sous XP, 2008R2 et W7.
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Manuel Leclerc
Le 30/01/2012 08:44, PP a écrit :
Le 29/01/2012 20:50, Manuel Leclerc a écrit :
Mais pourquoi considères tu qu'un plantage dans une bibliothèque est lié à cette bibliothèque, et non à ces appelants ?
Dans le principe, si l'appelant fait une demande bugguée, la bibliothèque "ne doit pas" planter ! Et là, "d'après le message d'erreur", c'est bien la bibliothèque qui cesse de fonctionner.
ça dépend de ce que tu appelles "demande bugguée", "planter" et "cesser de fonctionner". Si l'appelant est mal codé et, par exemple, corrompt des structures de données, il va finir par y avoir des problèmes contre lesquels la bibliothèque ne peut pas grand chose.
Faudrait que tu donnes le "message d'erreur" en question.
Le 30/01/2012 08:44, PP a écrit :
Le 29/01/2012 20:50, Manuel Leclerc a écrit :
Mais pourquoi considères tu qu'un plantage dans une bibliothèque est lié
à cette bibliothèque, et non à ces appelants ?
Dans le principe, si l'appelant fait une demande bugguée, la
bibliothèque "ne doit pas" planter ! Et là, "d'après le message
d'erreur", c'est bien la bibliothèque qui cesse de fonctionner.
ça dépend de ce que tu appelles "demande bugguée", "planter" et
"cesser de fonctionner". Si l'appelant est mal codé et, par exemple,
corrompt des structures de données, il va finir par y avoir des
problèmes contre lesquels la bibliothèque ne peut pas grand chose.
Faudrait que tu donnes le "message d'erreur" en question.
Mais pourquoi considères tu qu'un plantage dans une bibliothèque est lié à cette bibliothèque, et non à ces appelants ?
Dans le principe, si l'appelant fait une demande bugguée, la bibliothèque "ne doit pas" planter ! Et là, "d'après le message d'erreur", c'est bien la bibliothèque qui cesse de fonctionner.
ça dépend de ce que tu appelles "demande bugguée", "planter" et "cesser de fonctionner". Si l'appelant est mal codé et, par exemple, corrompt des structures de données, il va finir par y avoir des problèmes contre lesquels la bibliothèque ne peut pas grand chose.
Faudrait que tu donnes le "message d'erreur" en question.
Manuel Leclerc
Le 30/01/2012 09:35, JKB a écrit :
Le Sun, 29 Jan 2012 20:50:13 +0100,
J'attends toujours la référence qui pourrait me convaincre que JKB a fait autre chose que de raconter n'importe quoi.
Tu peux dire ce que tu veux. Je t'ai déjà filé des informations pour te signaler aimablement que le problème avait été reconnu par Microsoft et corrigé dans une évolution de VC++ 6. J'ai d'autres choses à foutre actuellement que de me replonger dans la KB de Microsoft pour trouver le numéro correspondant (dont le libellé, je te l'accorde, n'est de mémoire pas très explicite). Mais dès que j'ai un peu de temps pour te le retrouver, tu l'auras.
Par ailleurs, ce n'est pas parce que tu n'as jamais été confronté au problème qu'il n'existe pas. Et pour ta gouverne, nous avons identifié le problème (nous, parce qu'on s'y était mis à plusieurs) à la suite de sorties de programmes de traitement d'image un peu violentes et ce problème nous a été _confirmé_ par le support de Microsoft lui-même. Et bizarrement aussi, en prenant un compilo plus récent (ou en évitant les allocations dans les bibliothèques dynamiques) le problème disparaissait.
Dernière chose, je ne cherche pas à te convaincre. Mais je suis porté à croire que le support de chez Microsoft connaît mieux les merdes de VC++ que toi.
Loin de moi l'idée de croire qu'il n'y a jamais eu de bug dans VC++, que ce soit à la la génération ou à l'exécution. Je me souviens par exemple d'une vieille version de ATL ou MFC dans laquelle l'équivalent de calloc faisait tout bien comme il faut, sauf la partie "mise à zéro" quand compilé en release, ce qui est quand même assez énorme.
Quand je dis que tu racontes n'importe quoi, c'est en référence à tes délires sur le mapping des DLLs par le gestionnaire de mémoire virtuelle du kernel.
Le 30/01/2012 09:35, JKB a écrit :
Le Sun, 29 Jan 2012 20:50:13 +0100,
J'attends toujours la référence qui pourrait me convaincre que JKB a
fait autre chose que de raconter n'importe quoi.
Tu peux dire ce que tu veux. Je t'ai déjà filé des informations pour
te signaler aimablement que le problème avait été reconnu par
Microsoft et corrigé dans une évolution de VC++ 6. J'ai d'autres
choses à foutre actuellement que de me replonger dans la KB de
Microsoft pour trouver le numéro correspondant (dont le libellé, je
te l'accorde, n'est de mémoire pas très explicite). Mais dès que j'ai
un peu de temps pour te le retrouver, tu l'auras.
Par ailleurs, ce n'est pas parce que tu n'as jamais été confronté au
problème qu'il n'existe pas. Et pour ta gouverne, nous avons
identifié le problème (nous, parce qu'on s'y était mis à plusieurs)
à la suite de sorties de programmes de traitement d'image un peu
violentes et ce problème nous a été _confirmé_ par le support de
Microsoft lui-même. Et bizarrement aussi, en prenant un compilo plus
récent (ou en évitant les allocations dans les bibliothèques
dynamiques) le problème disparaissait.
Dernière chose, je ne cherche pas à te convaincre. Mais je suis
porté à croire que le support de chez Microsoft connaît mieux les
merdes de VC++ que toi.
Loin de moi l'idée de croire qu'il n'y a jamais eu de bug dans VC++,
que ce soit à la la génération ou à l'exécution. Je me souviens par
exemple d'une vieille version de ATL ou MFC dans laquelle l'équivalent
de calloc faisait tout bien comme il faut, sauf la partie "mise à zéro"
quand compilé en release, ce qui est quand même assez énorme.
Quand je dis que tu racontes n'importe quoi, c'est en référence à tes
délires sur le mapping des DLLs par le gestionnaire de mémoire virtuelle
du kernel.
J'attends toujours la référence qui pourrait me convaincre que JKB a fait autre chose que de raconter n'importe quoi.
Tu peux dire ce que tu veux. Je t'ai déjà filé des informations pour te signaler aimablement que le problème avait été reconnu par Microsoft et corrigé dans une évolution de VC++ 6. J'ai d'autres choses à foutre actuellement que de me replonger dans la KB de Microsoft pour trouver le numéro correspondant (dont le libellé, je te l'accorde, n'est de mémoire pas très explicite). Mais dès que j'ai un peu de temps pour te le retrouver, tu l'auras.
Par ailleurs, ce n'est pas parce que tu n'as jamais été confronté au problème qu'il n'existe pas. Et pour ta gouverne, nous avons identifié le problème (nous, parce qu'on s'y était mis à plusieurs) à la suite de sorties de programmes de traitement d'image un peu violentes et ce problème nous a été _confirmé_ par le support de Microsoft lui-même. Et bizarrement aussi, en prenant un compilo plus récent (ou en évitant les allocations dans les bibliothèques dynamiques) le problème disparaissait.
Dernière chose, je ne cherche pas à te convaincre. Mais je suis porté à croire que le support de chez Microsoft connaît mieux les merdes de VC++ que toi.
Loin de moi l'idée de croire qu'il n'y a jamais eu de bug dans VC++, que ce soit à la la génération ou à l'exécution. Je me souviens par exemple d'une vieille version de ATL ou MFC dans laquelle l'équivalent de calloc faisait tout bien comme il faut, sauf la partie "mise à zéro" quand compilé en release, ce qui est quand même assez énorme.
Quand je dis que tu racontes n'importe quoi, c'est en référence à tes délires sur le mapping des DLLs par le gestionnaire de mémoire virtuelle du kernel.
JKB
Le Mon, 30 Jan 2012 09:56:38 +0100, Manuel Leclerc écrivait :
Le 30/01/2012 09:35, JKB a écrit :
Le Sun, 29 Jan 2012 20:50:13 +0100,
J'attends toujours la référence qui pourrait me convaincre que JKB a fait autre chose que de raconter n'importe quoi.
Tu peux dire ce que tu veux. Je t'ai déjà filé des informations pour te signaler aimablement que le problème avait été reconnu par Microsoft et corrigé dans une évolution de VC++ 6. J'ai d'autres choses à foutre actuellement que de me replonger dans la KB de Microsoft pour trouver le numéro correspondant (dont le libellé, je te l'accorde, n'est de mémoire pas très explicite). Mais dès que j'ai un peu de temps pour te le retrouver, tu l'auras.
Par ailleurs, ce n'est pas parce que tu n'as jamais été confronté au problème qu'il n'existe pas. Et pour ta gouverne, nous avons identifié le problème (nous, parce qu'on s'y était mis à plusieurs) à la suite de sorties de programmes de traitement d'image un peu violentes et ce problème nous a été _confirmé_ par le support de Microsoft lui-même. Et bizarrement aussi, en prenant un compilo plus récent (ou en évitant les allocations dans les bibliothèques dynamiques) le problème disparaissait.
Dernière chose, je ne cherche pas à te convaincre. Mais je suis porté à croire que le support de chez Microsoft connaît mieux les merdes de VC++ que toi.
Loin de moi l'idée de croire qu'il n'y a jamais eu de bug dans VC++, que ce soit à la la génération ou à l'exécution. Je me souviens par exemple d'une vieille version de ATL ou MFC dans laquelle l'équivalent de calloc faisait tout bien comme il faut, sauf la partie "mise à zéro" quand compilé en release, ce qui est quand même assez énorme.
Quand je dis que tu racontes n'importe quoi, c'est en référence à tes délires sur le mapping des DLLs par le gestionnaire de mémoire virtuelle du kernel.
Et bien considère que c'est du délire. Le bug a été remonté parce qu'on a tout d'abord pu l'isoler et le reproduire et aussi parce qu'on avait sous la main les sources de NT4 pour confirmer un comportement anormal.
<EOT>
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Mon, 30 Jan 2012 09:56:38 +0100,
Manuel Leclerc <manuel.leclerc@alussinan.org> écrivait :
Le 30/01/2012 09:35, JKB a écrit :
Le Sun, 29 Jan 2012 20:50:13 +0100,
J'attends toujours la référence qui pourrait me convaincre que JKB a
fait autre chose que de raconter n'importe quoi.
Tu peux dire ce que tu veux. Je t'ai déjà filé des informations pour
te signaler aimablement que le problème avait été reconnu par
Microsoft et corrigé dans une évolution de VC++ 6. J'ai d'autres
choses à foutre actuellement que de me replonger dans la KB de
Microsoft pour trouver le numéro correspondant (dont le libellé, je
te l'accorde, n'est de mémoire pas très explicite). Mais dès que j'ai
un peu de temps pour te le retrouver, tu l'auras.
Par ailleurs, ce n'est pas parce que tu n'as jamais été confronté au
problème qu'il n'existe pas. Et pour ta gouverne, nous avons
identifié le problème (nous, parce qu'on s'y était mis à plusieurs)
à la suite de sorties de programmes de traitement d'image un peu
violentes et ce problème nous a été _confirmé_ par le support de
Microsoft lui-même. Et bizarrement aussi, en prenant un compilo plus
récent (ou en évitant les allocations dans les bibliothèques
dynamiques) le problème disparaissait.
Dernière chose, je ne cherche pas à te convaincre. Mais je suis
porté à croire que le support de chez Microsoft connaît mieux les
merdes de VC++ que toi.
Loin de moi l'idée de croire qu'il n'y a jamais eu de bug dans VC++,
que ce soit à la la génération ou à l'exécution. Je me souviens par
exemple d'une vieille version de ATL ou MFC dans laquelle l'équivalent
de calloc faisait tout bien comme il faut, sauf la partie "mise à zéro"
quand compilé en release, ce qui est quand même assez énorme.
Quand je dis que tu racontes n'importe quoi, c'est en référence à tes
délires sur le mapping des DLLs par le gestionnaire de mémoire virtuelle
du kernel.
Et bien considère que c'est du délire. Le bug a été remonté parce
qu'on a tout d'abord pu l'isoler et le reproduire et aussi parce
qu'on avait sous la main les sources de NT4 pour confirmer un
comportement anormal.
<EOT>
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Mon, 30 Jan 2012 09:56:38 +0100, Manuel Leclerc écrivait :
Le 30/01/2012 09:35, JKB a écrit :
Le Sun, 29 Jan 2012 20:50:13 +0100,
J'attends toujours la référence qui pourrait me convaincre que JKB a fait autre chose que de raconter n'importe quoi.
Tu peux dire ce que tu veux. Je t'ai déjà filé des informations pour te signaler aimablement que le problème avait été reconnu par Microsoft et corrigé dans une évolution de VC++ 6. J'ai d'autres choses à foutre actuellement que de me replonger dans la KB de Microsoft pour trouver le numéro correspondant (dont le libellé, je te l'accorde, n'est de mémoire pas très explicite). Mais dès que j'ai un peu de temps pour te le retrouver, tu l'auras.
Par ailleurs, ce n'est pas parce que tu n'as jamais été confronté au problème qu'il n'existe pas. Et pour ta gouverne, nous avons identifié le problème (nous, parce qu'on s'y était mis à plusieurs) à la suite de sorties de programmes de traitement d'image un peu violentes et ce problème nous a été _confirmé_ par le support de Microsoft lui-même. Et bizarrement aussi, en prenant un compilo plus récent (ou en évitant les allocations dans les bibliothèques dynamiques) le problème disparaissait.
Dernière chose, je ne cherche pas à te convaincre. Mais je suis porté à croire que le support de chez Microsoft connaît mieux les merdes de VC++ que toi.
Loin de moi l'idée de croire qu'il n'y a jamais eu de bug dans VC++, que ce soit à la la génération ou à l'exécution. Je me souviens par exemple d'une vieille version de ATL ou MFC dans laquelle l'équivalent de calloc faisait tout bien comme il faut, sauf la partie "mise à zéro" quand compilé en release, ce qui est quand même assez énorme.
Quand je dis que tu racontes n'importe quoi, c'est en référence à tes délires sur le mapping des DLLs par le gestionnaire de mémoire virtuelle du kernel.
Et bien considère que c'est du délire. Le bug a été remonté parce qu'on a tout d'abord pu l'isoler et le reproduire et aussi parce qu'on avait sous la main les sources de NT4 pour confirmer un comportement anormal.
<EOT>
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Manuel Leclerc
Le 30/01/2012 09:59, JKB a écrit :
<EOT>
Oui ben j'espère que tu pourras quand même poster cette fameuse référence.
Le 30/01/2012 09:59, JKB a écrit :
<EOT>
Oui ben j'espère que tu pourras quand même poster cette fameuse référence.
Oui ben j'espère que tu pourras quand même poster cette fameuse référence.
JKB
Le Mon, 30 Jan 2012 10:32:44 +0100, Manuel Leclerc écrivait :
Le 30/01/2012 09:59, JKB a écrit :
<EOT>
Oui ben j'espère que tu pourras quand même poster cette fameuse référence.
Non. J'avais prévu de partir à sa recherche dès que j'avais un moment, mais vu la façon dont tu le prends et tes propos qui frisent l'insulte , tu risques fort d'aller la chercher toi-même.
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Mon, 30 Jan 2012 10:32:44 +0100,
Manuel Leclerc <manuel.leclerc@alussinan.org> écrivait :
Le 30/01/2012 09:59, JKB a écrit :
<EOT>
Oui ben j'espère que tu pourras quand même poster cette fameuse référence.
Non. J'avais prévu de partir à sa recherche dès que j'avais un
moment, mais vu la façon dont tu le prends et tes propos qui frisent
l'insulte , tu risques fort d'aller la chercher toi-même.
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Mon, 30 Jan 2012 10:32:44 +0100, Manuel Leclerc écrivait :
Le 30/01/2012 09:59, JKB a écrit :
<EOT>
Oui ben j'espère que tu pourras quand même poster cette fameuse référence.
Non. J'avais prévu de partir à sa recherche dès que j'avais un moment, mais vu la façon dont tu le prends et tes propos qui frisent l'insulte , tu risques fort d'aller la chercher toi-même.
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
PP
Le 30/01/2012 09:45, Manuel Leclerc a écrit :
Le 30/01/2012 08:44, PP a écrit :
Le 29/01/2012 20:50, Manuel Leclerc a écrit :
Mais pourquoi considères tu qu'un plantage dans une bibliothèque est lié à cette bibliothèque, et non à ces appelants ?
Dans le principe, si l'appelant fait une demande bugguée, la bibliothèque "ne doit pas" planter ! Et là, "d'après le message d'erreur", c'est bien la bibliothèque qui cesse de fonctionner.
ça dépend de ce que tu appelles "demande bugguée", "planter" et "cesser de fonctionner". Si l'appelant est mal codé et, par exemple, corrompt des structures de données, il va finir par y avoir des problèmes contre lesquels la bibliothèque ne peut pas grand chose.
Faudrait que tu donnes le "message d'erreur" en question.
MFC 80 a cessé de fonctionner !!!
La moindre des choses quand on fournit un bibliothèque générique, c'est qu'elle renvoie des messages d'erreur, plutôt que se viander, non ?
Le 30/01/2012 09:45, Manuel Leclerc a écrit :
Le 30/01/2012 08:44, PP a écrit :
Le 29/01/2012 20:50, Manuel Leclerc a écrit :
Mais pourquoi considères tu qu'un plantage dans une bibliothèque est lié
à cette bibliothèque, et non à ces appelants ?
Dans le principe, si l'appelant fait une demande bugguée, la
bibliothèque "ne doit pas" planter ! Et là, "d'après le message
d'erreur", c'est bien la bibliothèque qui cesse de fonctionner.
ça dépend de ce que tu appelles "demande bugguée", "planter" et
"cesser de fonctionner". Si l'appelant est mal codé et, par exemple,
corrompt des structures de données, il va finir par y avoir des
problèmes contre lesquels la bibliothèque ne peut pas grand chose.
Faudrait que tu donnes le "message d'erreur" en question.
MFC 80 a cessé de fonctionner !!!
La moindre des choses quand on fournit un bibliothèque générique, c'est
qu'elle renvoie des messages d'erreur, plutôt que se viander, non ?
Mais pourquoi considères tu qu'un plantage dans une bibliothèque est lié à cette bibliothèque, et non à ces appelants ?
Dans le principe, si l'appelant fait une demande bugguée, la bibliothèque "ne doit pas" planter ! Et là, "d'après le message d'erreur", c'est bien la bibliothèque qui cesse de fonctionner.
ça dépend de ce que tu appelles "demande bugguée", "planter" et "cesser de fonctionner". Si l'appelant est mal codé et, par exemple, corrompt des structures de données, il va finir par y avoir des problèmes contre lesquels la bibliothèque ne peut pas grand chose.
Faudrait que tu donnes le "message d'erreur" en question.
MFC 80 a cessé de fonctionner !!!
La moindre des choses quand on fournit un bibliothèque générique, c'est qu'elle renvoie des messages d'erreur, plutôt que se viander, non ?
Manuel Leclerc
Le 30/01/2012 11:19, PP a écrit :
MFC 80 a cessé de fonctionner !!!
La moindre des choses quand on fournit un bibliothèque générique, c'est qu'elle renvoie des messages d'erreur, plutôt que se viander, non ?
Bof. C'est en gros le genre de message que tu peux avoir si ton application crashe, par exemple en déréférençant un pointeur nul.
Je dirais à vue de nez que le problème à 99,99% de chance de se situer dans l'application et pas dans la bibliothèque générique.
Le 30/01/2012 11:19, PP a écrit :
MFC 80 a cessé de fonctionner !!!
La moindre des choses quand on fournit un bibliothèque générique, c'est
qu'elle renvoie des messages d'erreur, plutôt que se viander, non ?
Bof. C'est en gros le genre de message que tu peux avoir si ton
application crashe, par exemple en déréférençant un pointeur nul.
Je dirais à vue de nez que le problème à 99,99% de chance de se situer
dans l'application et pas dans la bibliothèque générique.
