Bon voil=E0 j'ai a priori un bug dans le code C de bibclean, une
application pour nettoyer des entr=E9es BibTeX
(http://www.math.utah.edu/pub/bibclean/), je m'explique :
La fonction suivante compile sans probl=E8me tant sous ma debian (Linux
Gaia 2.6.8-1-386 #1 Thu Nov 25 04:24:08 UTC 2004 i686 GNU/Linux) que
sous le syst=E8me Solaris pour lequel je d=E9veloppe une application
utilisant bibclean (SunOS diabolo 5.8 Generic_108528-27 sun4u sparc
SUNW,Sun-Fire-880 et SunOS vignes.georgiatech-metz.fr 5.7
Generic_106541-10 sun4u sparc SUNW,Ultra-2).
Le probl=E8me (il en faut malheureusement) c'est que, apr=E8s debuggage,
il semble que la fonction unexpected() dans bibclean ne soit pas
appel=E9e.
void
check_month(VOID)
{
int m; /* month index */
size_t n =3D strlen(current_value);
if (n =3D=3D 3) /* check for match against standard
abbrevs */
{
for (m =3D 0; month_pair[m].old_name !=3D (const char*)NULL; ++m)
{
if (stricmp(month_pair[m].new_name,current_value) =3D=3D 0)
return;
}
}
/* Hand coding for the remaining patterns is too ugly to
contemplate,
so we only provide the checking when real pattern matching is
available. */
#if !defined(HAVE_OLDCODE)
if (check_patterns(pattern_names[PT_MONTH].table,current_value) =3D=3D
YES)
return;
#endif
void
check_month(VOID)
{
int m; /* month index */
size_t n =3D strlen(current_value);
if (n =3D=3D 3) /* check for match against standard
abbrevs */
{
for (m =3D 0; month_pair[m].old_name !=3D (const char*)NULL; ++m)
{
if (stricmp(month_pair[m].new_name,current_value) =3D=3D 0)
return;
}
}
unexpected();
/* Hand coding for the remaining patterns is too ugly to
contemplate,
so we only provide the checking when real pattern matching is
available. */
#if !defined(HAVE_OLDCODE)
if (check_patterns(pattern_names[PT_MONTH].table,current_value) =3D=3D
YES)
return;
#endif
Donc s'agit-il d'un bug connu de Solaris 5.x ? Comment faire s'il y a
d'autres portions de code avec un probl=E8me semblable ailleurs ? Je
veux pas vraiment me farcir tout le code pour v=E9rifier si =E7a marche
ou pas sous Solaris...
Donc, la question serait : pourquoi =E7a marche pas dans le 1er cas ?
#if !defined(HAVE_OLDCODE) if (check_patterns(pattern_names[PT_MONTH].table,current_value) = > YES) return; #endif
D'après ce que tu décris, je suppose que tu passes dans cette branche de code et que le return est appelé.
que fait check_patterns() ?
d'ailleurs, ce genre de code est une hérésie :
if (a(b) == YES)
vu que le résultat de a(b) est à priori déjà un booléen.
-- DINH V. Hoa,
"monde de merde" -- Erwan David
Paul Gaborit
À (at) 4 Jun 2005 02:52:10 -0700, "phan_tom_99" écrivait (wrote):
Donc s'agit-il d'un bug connu de Solaris 5.x ?
Certainement pas un bug de Solaris. Ni même du compilateur C que vous utilisez.
Comment faire s'il y a d'autres portions de code avec un problème semblable ailleurs ? Je veux pas vraiment me farcir tout le code pour vérifier si ça marche ou pas sous Solaris...
Donc, la question serait : pourquoi ça marche pas dans le 1er cas ?
Parce que HAVE_OLDCODE doit être défini (par la configuration du produit) et que le test doit l'être aussi et, par conséquent, le 'return' est effectué avant l'appel à la fonction 'unexpected'...
Êtes-vous sûr de votre configuration ? Est-elle adaptée aux caractéristiques de votre compilateur et de votre environnement ? Quel compilateur utilisez-vous ? Quelle version ?
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) 4 Jun 2005 02:52:10 -0700,
"phan_tom_99" <duong.phan81@gmail.com> écrivait (wrote):
Donc s'agit-il d'un bug connu de Solaris 5.x ?
Certainement pas un bug de Solaris. Ni même du compilateur C que vous
utilisez.
Comment faire s'il y a d'autres portions de code avec un problème semblable
ailleurs ? Je veux pas vraiment me farcir tout le code pour vérifier si ça
marche ou pas sous Solaris...
Donc, la question serait : pourquoi ça marche pas dans le 1er cas ?
Parce que HAVE_OLDCODE doit être défini (par la configuration du produit) et
que le test doit l'être aussi et, par conséquent, le 'return' est effectué
avant l'appel à la fonction 'unexpected'...
Êtes-vous sûr de votre configuration ? Est-elle adaptée aux caractéristiques
de votre compilateur et de votre environnement ? Quel compilateur
utilisez-vous ? Quelle version ?
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) 4 Jun 2005 02:52:10 -0700, "phan_tom_99" écrivait (wrote):
Donc s'agit-il d'un bug connu de Solaris 5.x ?
Certainement pas un bug de Solaris. Ni même du compilateur C que vous utilisez.
Comment faire s'il y a d'autres portions de code avec un problème semblable ailleurs ? Je veux pas vraiment me farcir tout le code pour vérifier si ça marche ou pas sous Solaris...
Donc, la question serait : pourquoi ça marche pas dans le 1er cas ?
Parce que HAVE_OLDCODE doit être défini (par la configuration du produit) et que le test doit l'être aussi et, par conséquent, le 'return' est effectué avant l'appel à la fonction 'unexpected'...
Êtes-vous sûr de votre configuration ? Est-elle adaptée aux caractéristiques de votre compilateur et de votre environnement ? Quel compilateur utilisez-vous ? Quelle version ?
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Antoine Leca
En <news:, phan_tom_99 va escriure:
Le problème (il en faut malheureusement) c'est que, après debuggage, il semble que la fonction unexpected() dans bibclean ne soit pas appelée.
Et est-il prévu qu'elle le soit, avec un nom pareil ? (plus question subsidiaire: pourquoi?)
check_month(VOID) if (n == 3) /* check for match against standard abbrevs */ if (stricmp(month_pair[m].new_name,current_value) == 0) return;
« Normalement », on sort ici, et le code appelant se débrouille avec un nom de mois « normal ».
Pour la suite, on a donc un nom de mois « anormal » (par exemple, une abréviation en français/en anglais, le genre de truc classique qui gêne ce genre de code). Voyons ce que l'on en fait...
#if !defined(HAVE_OLDCODE) if (check_patterns( return; #endif
Si tu n'as *pas* "OLDCODE" (ce qui est je suppose ton cas), et que la fonction check_patterns() réussit à interpréter d'une manière ou d'une autre le nom « anormal », alors on repasse aussi le bébé au code appelant (et je pense que ton problème c'est que le code appelant, lui, ne doit pas savoir quoi faire avec cela, donc tu obtiens un comportement bogué).
unexpected();
Sinon tu sors par unexpected() qui doit générer un message de protestation ou autre, et passer à la ligne suivante via je suppose un longjmp() (donc pour toi « cela fonctionne »).
Après modification du code, ça marche si unexpected() est placée avant le bloc #if ... #endif :
Évidemment, si tu court-circuites l'acceptation des noms « anormaux », le code appelant n'a plus à traiter ce qu'il ne sait pas traiter, cela « marche mieux » (et tu dois avoir encore plus de messages de protestation ignorés).
Donc s'agit-il d'un bug connu de Solaris 5.x ?
Heu ? pourquoi ?
Pose-toi plutôt les questions:
-- pourquoi n'as-tu pas OLDCODE, et qu'est ce que cela contrôle par ailleurs ?
-- qu'elle est la forme du mois qui fait passer par le deuxième return, et essaye de tracer un peu pour voir pourquoi le code appelant cette fonction ne peut pas s'en sortir.
Dans un cas ou dans l'autre, tu devrais arriver à la raison du bogue (non décrit), et suffisament d'éléments pour te permettre de soumettre un raport d'anomalie aux développeurs, et obtenir un correctif.
Je me base sur le commentaire so we only provide the checking when real pattern matching is available. */ qui donne à penser que le test est activé seulement quand un module « non standard » ("real pattern matching") est disponible: typiquement, le problème doit être dans le dit module, et son implémentation sur ta machine; autrement dit, dans une portion de code très différente de celle que tu as montrée.
Comment faire s'il y a d'autres portions de code avec un problème semblable ailleurs ?
En passant: _quel_ est le problème ?
Antoine
En <news:1117878730.888773.305950@g14g2000cwa.googlegroups.com>,
phan_tom_99 va escriure:
Le problème (il en faut malheureusement) c'est que, après debuggage,
il semble que la fonction unexpected() dans bibclean ne soit pas
appelée.
Et est-il prévu qu'elle le soit, avec un nom pareil ?
(plus question subsidiaire: pourquoi?)
check_month(VOID)
if (n == 3) /* check for match against standard abbrevs */
if (stricmp(month_pair[m].new_name,current_value) == 0)
return;
« Normalement », on sort ici, et le code appelant se débrouille avec un nom
de mois « normal ».
Pour la suite, on a donc un nom de mois « anormal » (par exemple, une
abréviation en français/en anglais, le genre de truc classique qui gêne ce
genre de code).
Voyons ce que l'on en fait...
#if !defined(HAVE_OLDCODE)
if (check_patterns(
return;
#endif
Si tu n'as *pas* "OLDCODE" (ce qui est je suppose ton cas), et que la
fonction check_patterns() réussit à interpréter d'une manière ou d'une autre
le nom « anormal », alors on repasse aussi le bébé au code appelant (et je
pense que ton problème c'est que le code appelant, lui, ne doit pas savoir
quoi faire avec cela, donc tu obtiens un comportement bogué).
unexpected();
Sinon tu sors par unexpected() qui doit générer un message de protestation
ou autre, et passer à la ligne suivante via je suppose un longjmp() (donc
pour toi « cela fonctionne »).
Après modification du code, ça marche si unexpected() est placée
avant le bloc #if ... #endif :
Évidemment, si tu court-circuites l'acceptation des noms « anormaux », le
code appelant n'a plus à traiter ce qu'il ne sait pas traiter, cela « marche
mieux » (et tu dois avoir encore plus de messages de protestation ignorés).
Donc s'agit-il d'un bug connu de Solaris 5.x ?
Heu ? pourquoi ?
Pose-toi plutôt les questions:
-- pourquoi n'as-tu pas OLDCODE, et qu'est ce que cela contrôle par ailleurs
?
-- qu'elle est la forme du mois qui fait passer par le deuxième return, et
essaye de tracer un peu pour voir pourquoi le code appelant cette fonction
ne peut pas s'en sortir.
Dans un cas ou dans l'autre, tu devrais arriver à la raison du bogue (non
décrit), et suffisament d'éléments pour te permettre de soumettre un raport
d'anomalie aux développeurs, et obtenir un correctif.
Je me base sur le commentaire
so we only provide the checking when real pattern matching is
available. */
qui donne à penser que le test est activé seulement quand un module « non
standard » ("real pattern matching") est disponible: typiquement, le
problème doit être dans le dit module, et son implémentation sur ta machine;
autrement dit, dans une portion de code très différente de celle que tu as
montrée.
Comment faire s'il y a
d'autres portions de code avec un problème semblable ailleurs ?
Le problème (il en faut malheureusement) c'est que, après debuggage, il semble que la fonction unexpected() dans bibclean ne soit pas appelée.
Et est-il prévu qu'elle le soit, avec un nom pareil ? (plus question subsidiaire: pourquoi?)
check_month(VOID) if (n == 3) /* check for match against standard abbrevs */ if (stricmp(month_pair[m].new_name,current_value) == 0) return;
« Normalement », on sort ici, et le code appelant se débrouille avec un nom de mois « normal ».
Pour la suite, on a donc un nom de mois « anormal » (par exemple, une abréviation en français/en anglais, le genre de truc classique qui gêne ce genre de code). Voyons ce que l'on en fait...
#if !defined(HAVE_OLDCODE) if (check_patterns( return; #endif
Si tu n'as *pas* "OLDCODE" (ce qui est je suppose ton cas), et que la fonction check_patterns() réussit à interpréter d'une manière ou d'une autre le nom « anormal », alors on repasse aussi le bébé au code appelant (et je pense que ton problème c'est que le code appelant, lui, ne doit pas savoir quoi faire avec cela, donc tu obtiens un comportement bogué).
unexpected();
Sinon tu sors par unexpected() qui doit générer un message de protestation ou autre, et passer à la ligne suivante via je suppose un longjmp() (donc pour toi « cela fonctionne »).
Après modification du code, ça marche si unexpected() est placée avant le bloc #if ... #endif :
Évidemment, si tu court-circuites l'acceptation des noms « anormaux », le code appelant n'a plus à traiter ce qu'il ne sait pas traiter, cela « marche mieux » (et tu dois avoir encore plus de messages de protestation ignorés).
Donc s'agit-il d'un bug connu de Solaris 5.x ?
Heu ? pourquoi ?
Pose-toi plutôt les questions:
-- pourquoi n'as-tu pas OLDCODE, et qu'est ce que cela contrôle par ailleurs ?
-- qu'elle est la forme du mois qui fait passer par le deuxième return, et essaye de tracer un peu pour voir pourquoi le code appelant cette fonction ne peut pas s'en sortir.
Dans un cas ou dans l'autre, tu devrais arriver à la raison du bogue (non décrit), et suffisament d'éléments pour te permettre de soumettre un raport d'anomalie aux développeurs, et obtenir un correctif.
Je me base sur le commentaire so we only provide the checking when real pattern matching is available. */ qui donne à penser que le test est activé seulement quand un module « non standard » ("real pattern matching") est disponible: typiquement, le problème doit être dans le dit module, et son implémentation sur ta machine; autrement dit, dans une portion de code très différente de celle que tu as montrée.
Comment faire s'il y a d'autres portions de code avec un problème semblable ailleurs ?
En passant: _quel_ est le problème ?
Antoine
Paul Gaborit
À (at) Mon, 06 Jun 2005 08:21:55 +0200, Paul Gaborit écrivait (wrote):
Parce que HAVE_OLDCODE doit être défini...
En fait, j'avais mal lu le code. C'est donc le contraire : HAVE_OLDCODE ne doit pas être défini (ce qui est normal a mon sens). Le comportement du programme doit donc être celui prévu.
Pourquoi croyez-vous donc qu'il y a un bug ?
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Mon, 06 Jun 2005 08:21:55 +0200,
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrivait (wrote):
Parce que HAVE_OLDCODE doit être défini...
En fait, j'avais mal lu le code. C'est donc le contraire : HAVE_OLDCODE ne
doit pas être défini (ce qui est normal a mon sens). Le comportement du
programme doit donc être celui prévu.
Pourquoi croyez-vous donc qu'il y a un bug ?
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Mon, 06 Jun 2005 08:21:55 +0200, Paul Gaborit écrivait (wrote):
Parce que HAVE_OLDCODE doit être défini...
En fait, j'avais mal lu le code. C'est donc le contraire : HAVE_OLDCODE ne doit pas être défini (ce qui est normal a mon sens). Le comportement du programme doit donc être celui prévu.
Pourquoi croyez-vous donc qu'il y a un bug ?
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
