Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ bug dans regexx - bouteille à la mer

bug dans regexx - bouteille à la mer

16 réponses
Avatar
news.wanadoo.fr
Salut à toutes et tous,

je rencontre un problème avec regexx.
plutôt qu'un long discours voici le programme que je compile :

// DEBUT DU PROGRAMME --------------------------------
#include <stdio.h>
#include <regexx.hh>

using namespace std;
using namespace regexx;

string s="coucou";
string c="c";

main()
{
Regexx z;
try {
i=z.exec(s,c,Regexx::global|Regexx::newline);
}
catch(Regexx::CompileException &e)
{
cout << "compile-exception : " << e.message() << "\n";
exit(1);
}
catch(...)
{
cout << "Exception exceptionnelle !\n";
}
cout << "matches=" << z.matches() << "\n";
}
// FIN DU PROGRAMME -----------------

si je l'execute, j'obtiens "matches=2", ce qui est correct.

Si je change la ligne :
string c="c"; par : string="[c";
(je mets volontairement une erreur dans mon expression régulière)

si je l'execute, j'obtiens "compile-exception : missing terminating ] for
character class", ce qui est toujours correct.

Si je change la ligne :
string c="c"; par : string="c*";

si je l'execute, j'obtiens (après quelques secondes), un sibyllin :
"Aborted", ce qui n'est pas correct, évidemment....


Une âme charitable saura m'expliquer pourquoi et/ou vérifier de son côté le
même problème de comportement ?


Pour info, le compilateur : gcc version 3.3.3 (SuSE Linux)

D'avance, merci pour les éventuelles réponses ;-)


François Otho
Signaler un problème avec ce contenu

6 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
François
Normalement tu devrait pouvoir rapidement tester l'expression qui te pose
pb.
Tiens nous au courant afin de savoir si le comportement est le même...


En adaptant le petit programme indiqué ci-dessous, l'expression régulière
"c*"
fonctionne bien et ne provoque pas de plantage (c'est bien le moins) du
programme.

Ce qui est dommage, c'est que suse diffuse toujours ce package "regexx" qui
comporte une erreur aussi flagrante. J'ai bien essayé de contacter l'unique
auteur de
ce package : sa page perso est introuvable et son adresse de messagerie est
invalide.
Bref, à moins de plonger dans ses sources, à moins de s'inscrire sur
sourceforge,
et de tenter de devenir un administrateur/développeur de ce package (je ne
sais
meme pas si cela est possible !)... je ne vois pas à qui je pourrais
m'adresser %-(

Est-ce cela toute la "modernite" du modèle open-source ? ;-)

Attention, ce N'EST NI UNE ATTAQUE, NI UNE AFFIRMATION, CE n'est RIEN !
C'est juste une interrogation que je me pose (publiquement).

et, je pense, qu'il est INUTILE DE démarrer une enfilade dont tout le
monde se moque(ra) !... ;-))

Allez....

F.Otho

Avatar
François
Normalement tu devrait pouvoir rapidement tester l'expression qui te pose
pb.
Tiens nous au courant afin de savoir si le comportement est le même...


En adaptant le petit programme indiqué ci-dessous, l'expression régulière
"c*" fonctionne bien et ne provoque pas de plantage (c'est bien le moins) du
programme.

Ce qui est dommage, c'est que suse diffuse toujours ce package "regexx" qui
comporte une erreur aussi flagrante. J'ai bien essayé de contacter l'unique
auteur de ce package : sa page perso est introuvable et son adresse de
messagerie est invalide.
Bref, à moins de plonger dans ses sources, à moins de s'inscrire sur
sourceforge, et de tenter de devenir un administrateur/développeur de ce
package (je ne sais meme pas si cela est possible !)... je ne vois pas à qui
je pourrais m'adresser %-(

Est-ce cela toute la "modernite" du modèle open-source ? ;-)

Attention, ce N'EST NI UNE ATTAQUE, NI UNE AFFIRMATION, CE n'est RIEN !
C'est juste une interrogation que je me pose (publiquement).

et, je pense, qu'il n'est pas UTILE de demarrer un débat pro/anti dont tout
le monde se moque(ra) !... ou presque ;-))

Allez....

F.Otho

PS : pour info, boost::regex fonctionne parfaitement et se "montre" très
agréable à utiliser...

Avatar
kanze
Stan ( remove the dots ) wrote:

Tu les utilises souvent les expressions rationnelles ( à part
pour le projet en question )?


Ça dépend. Prèsque chaque fois que j'ai à traiter des entrées
faites par un être humain (y compris parfois des fichiers de
configuration). C'est un outil extrèmement puissant, et très
simple à utiliser une fois qu'on les connaît.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Avatar
kanze
François wrote:

Ce qui est dommage, c'est que suse diffuse toujours ce package
"regexx" qui comporte une erreur aussi flagrante. J'ai bien
essayé de contacter l'unique auteur de ce package : sa page
perso est introuvable et son adresse de messagerie est
invalide. Bref, à moins de plonger dans ses sources, à moins
de s'inscrire sur sourceforge, et de tenter de devenir un
administrateur/développeur de ce package (je ne sais meme pas
si cela est possible !)... je ne vois pas à qui je pourrais
m'adresser %-(

Est-ce cela toute la "modernite" du modèle open-source ? ;-)


C'est un des « problèmes » du modèle open-source.

En fait, évidemment, c'est qu'il y a des auteurs et des produits
sérieux, et des auteurs et des produits qui ne le sont pas. Open
Source ou non -- on rencontre les mêmes problèmes parfois avec
des logiciels commerciaux. C'est donc un problème général, qui
touche aussi bien l'open source que les autres produits.
L'argument de l'open source, c'est que tu as les sources, tu
peux donc faire les corrections toi-même si le fournisseur n'est
plus là. Argument extrèmement falicieux, à mon avis -- si tu as
utilisé le produit, c'est souvent parce que tu n'as pas les
ressources de l'écrire et de le maintenir toi-même.

C'est donc un problème de l'open-source dans la même mesure que
c'est un problème du logiciel commercial. Et c'est un problème
sans solution facile. Il existe de grands projets, dont on peut
être assez sûr qu'ils ne vont pas disparaître : MS-Windows ou
Sun CC, par exemple, mais aussi Linux et g++. Et il en existe
beaucoup de petits, dont on ne sait rien. Malheureusement, dans
bien trop de cas, la fonctionnalité dont on a besion se trouve
seulement dans un des petits. Alors, tout ce qu'il reste à
faire, c'est de se renseigner au maximum.

À cet égard, c'est important de se rendre compte que les
distributeurs de Linux, mais aussi de plus en plus les
fournisseurs des Unix commerciaux, comme Sun pour Solaris,
fournit sur les CD d'installation énormement de choses gratuites
« en plus » -- le fournisseur (Suse, Sun) le met là parce qu'il
y a de la place, et qu'il pense que quelqu'un pourrait s'y
intéresser, mais sans faire le moindre validation de ce que
c'est. En ce qui concerne ces logiciels, il faut procéder
exactement comme tu ferais s'ils n'y étaient pas, et que tu les
cherchais sur le reseau. C-à-d : tu trouves qui s'en occupe, et
tu évalues son sérieux au mieux que tu peux, et alors tu fais de
l'analyse du risque -- qu'est-ce que ça t'apporte, par rapport
aux risques de l'utiliser. Le fait que ce logiciel soit sur un
CD livré par une société en quelle tu as confiance ne signifie
pas que tu puisse y avoir confiance.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Avatar
Jean-Marc Desperrier
wrote:
L'argument de l'open source, c'est que tu as les sources, tu
peux donc faire les corrections toi-même si le fournisseur n'est
plus là. Argument extrèmement falicieux, à mon avis -- si tu as
utilisé le produit, c'est souvent parce que tu n'as pas les
ressources de l'écrire et de le maintenir toi-même.


La deuxième partie est que tu peux payer quelqu'un pour faire les
corrections et que le prix sera +/- proportionel à l'ampleur du
correctif. Ca dépend si le code est plus ou moins bien écrit.
Mais tu as là aussi la possibilité de vérifier à l'avance.

C'est donc un problème de l'open-source dans la même mesure que
c'est un problème du logiciel commercial. Et c'est un problème
sans solution facile.


Non, c'est définitivement un problèmes plus facile avec l'open source,
mais certains sont dans l'illusion qu'il disparaît avec l'open source et
ça c'est faux.

L'illusion en particulier est qu'il vont pouvoir utiliser le produit
sans jamais être celui qui devra investir (en temps ou financièrement)
pour continuer à le faire fonctionner. Et ça c'est un gros problème de
l'open source. Pour que le modèle marche bien, on ne devrait pas penser
qu'on peut l'utiliser un logiciel open source sans contribuer
proportionnellement au poids que l'on représente dans les utilisateurs.

Quand il y a beaucoup d'utilisateur, cette contribution devient très
faible, mais il ne faudrait jamais penser qu'elle est nulle, car nul et
très faible sont deux choses extrêmement différentes.

[...] le fournisseur (Suse, Sun) le met là parce qu'il
y a de la place


C'est pas tout à fait comme cela que cela marche quand même.
Le boulot des gens qui font une distrib est de sélectionner correctement
la majorité des paquets qu'ils incluent, et de s'assurer de leur
stabilité quand utilisé ensemble et de les patcher si besoin pour cela.
C'est vrai qu'il y a généralement une liste par défaut de paquet sur
lesquels ils font ce travail, et ensuite une liste complémentaire sur
laquelle ils ne s'engagent pas du tout, mais ils ne doivent pas mettre
en avant ces paquets là.

Il devrait y avoir un moyen de signaler à SUSE que regexx n'est pas du
tout maintenu, et qu'ils devraient remplacer par boost::regex, et
inclure regexx seulement dans les éléments optionnels pour
compatibilité. Ou s'ils ne remplacent pas, qu'ils devraient s'occupent
de corriger ce bug. Car s'ils poussent ce paquet, c'est un peu leur
boulot de le faire, et ici le paiement des cd SUSE constitue la
contribution référencée plus haut de l'utilisateur à regexx.

Avatar
kanze
Jean-Marc Desperrier wrote:
wrote:
L'argument de l'open source, c'est que tu as les sources, tu
peux donc faire les corrections toi-même si le fournisseur
n'est plus là. Argument extrèmement falicieux, à mon avis --
si tu as utilisé le produit, c'est souvent parce que tu n'as
pas les ressources de l'écrire et de le maintenir toi-même.


La deuxième partie est que tu peux payer quelqu'un pour faire
les corrections et que le prix sera +/- proportionel à
l'ampleur du correctif. Ca dépend si le code est plus ou moins
bien écrit. Mais tu as là aussi la possibilité de vérifier à
l'avance.


Si je veux gerer mon budget, il faut que je sache combien ça va
me coûter avant de me servir d'un produit. L'idée que quelqu'un
de chez moi, ou ailleurs, pourrait jeter un coup d'oeil à g++, à
wxWidgets ou à Linux, et donner une estimation à peu près
correcte de combien une correction va coûter est complètement
illusoire.

Dans le cas des logiciels extrèmement répandus, comme g++, il
n'y a pas de problème. G++ a fait ses preuves, et en plus, il y
a certainement assez de gens qui le connaissent pour continuer
la maintenance, et il y a assez de gens qui en ont besoin pour
s'assurer que quelqu'un a assez d'intérêt pour le faire. On
pourrait sûrement en dire autant pour certains d'autres projets,
comme Linux. Mais on pourrait en dire autant pour Solaris, je
crois. Ce n'est pas l'ouverture des sources qui a reduit la
risque, mais la taille de la communité utilisateur.

Avec un produit moins répandu, il faut faire l'analysis des
risques, des coûts, et ce que ça m'apporte. Dans la pratique, ce
qui m'intéresse avant la disponibilité des sources, c'est la
probabilité que quelqu'un qui les connaît déjà va continuer à y
travailler. En principe, c'est plus facile à évauler pour un
produit commercial, parce qu'on connaît plus ou moins bien les
motivations d'une entreprise commerciale, et qu'on a accès à un
certain nombre de données en ce qui concerne leur situation
financielle. Mais c'est assez limité aussi.

C'est donc un problème de l'open-source dans la même mesure
que c'est un problème du logiciel commercial. Et c'est un
problème sans solution facile.


Non, c'est définitivement un problèmes plus facile avec l'open
source, mais certains sont dans l'illusion qu'il disparaît
avec l'open source et ça c'est faux.

L'illusion en particulier est qu'il vont pouvoir utiliser le
produit sans jamais être celui qui devra investir (en temps ou
financièrement) pour continuer à le faire fonctionner.

Et ça c'est un gros problème de l'open source. Pour que le
modèle marche bien, on ne devrait pas penser qu'on peut
l'utiliser un logiciel open source sans contribuer
proportionnellement au poids que l'on représente dans les
utilisateurs.


Là, je suis tout à fait d'accord. Actuellement, le modèle marche
parce que certains sont près à contribuer bien plus que leur
just partie. Je suis près à parier que la plupart des
utilisateurs g++ n'investit rien en dehors des coûts internes
(installation, formation, etc.) ; si tous en faisaient autant,
on n'aurait pas g++. Mais c'est un autre problème.

Quand il y a beaucoup d'utilisateur, cette contribution
devient très faible, mais il ne faudrait jamais penser qu'elle
est nulle, car nul et très faible sont deux choses extrêmement
différentes.

[...] le fournisseur (Suse, Sun) le met là parce qu'il y a
de la place


C'est pas tout à fait comme cela que cela marche quand même.

Le boulot des gens qui font une distrib est de sélectionner
correctement la majorité des paquets qu'ils incluent, et de
s'assurer de leur stabilité quand utilisé ensemble et de les
patcher si besoin pour cela.


Ce n'est pas comme ça que travaille Sun, et ce n'est pas comme
ça que travaille Mandrake. Dans le cas de Sun, il y a une
distinction radicale entre leurs produits et les autres, avec
très peu d'exceptions. (Ils s'occupent de l'integration de Emacs
et de Vim dans Sun Workshop, par exemple.) Dans le cas de
Mandrake, c'est un peu près au hazard, j'ai l'impression, ils y
mettent n'importe quoi.

C'est vrai qu'il y a généralement une liste par défaut de
paquet sur lesquels ils font ce travail, et ensuite une liste
complémentaire sur laquelle ils ne s'engagent pas du tout,
mais ils ne doivent pas mettre en avant ces paquets là.

Il devrait y avoir un moyen de signaler à SUSE que regexx
n'est pas du tout maintenu, et qu'ils devraient remplacer par
boost::regex, et inclure regexx seulement dans les éléments
optionnels pour compatibilité.


Ils ont bien une adresse email, je crois.

Ou s'ils ne remplacent pas, qu'ils devraient s'occupent de
corriger ce bug. Car s'ils poussent ce paquet, c'est un peu
leur boulot de le faire, et ici le paiement des cd SUSE
constitue la contribution référencée plus haut de
l'utilisateur à regexx.


La question est : qu'est-ce qu'on entend par « pousser » le
paquet ? Est-ce le fait qu'il est présent sur leur CD et à leur
site signifie qu'il le pousse ? Ou simplement qu'il y a des gens
que ça intéresse, et qu'il le rend disponible simplement pour
leur rendre la vie plus commode ?

J'ai malheureusement l'impression que ce qui fait vendre une
distribution Linux, c'est le nombre de paquets livrés avec le
système. Sans considérer qu'il y a paquet et paquet.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


1 2