Je cherche un outil (ou les paramètres appropriés à passer à un outil
standard) qui puisse me donner la position de toutes les occurrences
d'une chaîne dans un fichier (le fichier fait 50 Go en fait un "dump"
d'un disque crashé obtenu avec dd).
J'ai essayé "grep -b" mais il n'aime pas trop les parties binaires. Mon
autre option est de passer par "hexdump -C" d'abord, mais comme là ma
chaîne risque d'être à cheval sur deux lignes...
Une idée ?
Merci,
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Voici un programme très rapide, adapté d'un exercice fait à l'école d'ingénieurs.
Hum, si l'algorithme est joli, il faut reconnaître comme le suggère FiLH que la programmation n'est pas rigoureuse, et qu'il serait bon d'apprendre à nos futurs ingénieurs à chasser sans répit les débordements de zone mémoire!...
Je te propose (au moins) les quelques corrections suivantes (à commencer par la fin pour éviter les renumérotations de lignes) :
ligne 10 : #define TAILLEMAX sizeof(int)*8 int byg(const unsigned char *pattern, FILE *file);
ligne 17 : fprintf(stderr, "Usage: %s motif filen", *argv); fprintf(stderr, " Nbre max de caractères pour le motif : %dn", TAILLEMAX);
devant ligne 26 : if (strlen(argv[1])>TAILLEMAX) { argv[1][TAILLEMAX]=0; fprintf(stderr, "Motif tronqué à : "%s"n",argv[1]); }
ligne 34 : int initVectors(int *vector, const unsigned char *pattern) {
ligne 38 : for (i=0; i<256; i++) {
ligne 49 et 50 : int byg(const unsigned char *pattern, FILE *file) { unsigned char currentChar;
ligne 55 : int vector[256];
lignes 62 et 63 : result = vector[currentChar] & (result<<1 | 1);
et supprimer l'accolade de la ligne 69
JPaul.
-- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
Nicolas Seriot <junk@seriot.ch> wrote:
Voici un programme très rapide, adapté d'un exercice fait à l'école
d'ingénieurs.
Hum, si l'algorithme est joli, il faut reconnaître comme le suggère FiLH
que la programmation n'est pas rigoureuse, et qu'il serait bon
d'apprendre à nos futurs ingénieurs à chasser sans répit les
débordements de zone mémoire!...
Je te propose (au moins) les quelques corrections suivantes (à
commencer par la fin pour éviter les renumérotations de lignes) :
ligne 10 :
#define TAILLEMAX sizeof(int)*8
int byg(const unsigned char *pattern, FILE *file);
ligne 17 :
fprintf(stderr, "Usage: %s motif filen", *argv);
fprintf(stderr,
" Nbre max de caractères pour le motif : %dn", TAILLEMAX);
devant ligne 26 :
if (strlen(argv[1])>TAILLEMAX)
{ argv[1][TAILLEMAX]=0;
fprintf(stderr,
"Motif tronqué à : "%s"n",argv[1]);
}
ligne 34 :
int initVectors(int *vector, const unsigned char *pattern) {
ligne 38 :
for (i=0; i<256; i++) {
ligne 49 et 50 :
int byg(const unsigned char *pattern, FILE *file) {
unsigned char currentChar;
ligne 55 :
int vector[256];
lignes 62 et 63 :
result = vector[currentChar] & (result<<1 | 1);
et supprimer l'accolade de la ligne 69
JPaul.
--
/==/==\- Jean-Paul BLANC
/ /--/--//\ quelque-part (somewhere)
|/| L |\ en (in)
/|| = |||\ FRANCE
Voici un programme très rapide, adapté d'un exercice fait à l'école d'ingénieurs.
Hum, si l'algorithme est joli, il faut reconnaître comme le suggère FiLH que la programmation n'est pas rigoureuse, et qu'il serait bon d'apprendre à nos futurs ingénieurs à chasser sans répit les débordements de zone mémoire!...
Je te propose (au moins) les quelques corrections suivantes (à commencer par la fin pour éviter les renumérotations de lignes) :
ligne 10 : #define TAILLEMAX sizeof(int)*8 int byg(const unsigned char *pattern, FILE *file);
ligne 17 : fprintf(stderr, "Usage: %s motif filen", *argv); fprintf(stderr, " Nbre max de caractères pour le motif : %dn", TAILLEMAX);
devant ligne 26 : if (strlen(argv[1])>TAILLEMAX) { argv[1][TAILLEMAX]=0; fprintf(stderr, "Motif tronqué à : "%s"n",argv[1]); }
ligne 34 : int initVectors(int *vector, const unsigned char *pattern) {
ligne 38 : for (i=0; i<256; i++) {
ligne 49 et 50 : int byg(const unsigned char *pattern, FILE *file) { unsigned char currentChar;
ligne 55 : int vector[256];
lignes 62 et 63 : result = vector[currentChar] & (result<<1 | 1);
et supprimer l'accolade de la ligne 69
JPaul.
-- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
Décidément les concepteurs de virus ont vraiment la part belle.
???
JPaul. -- /==/==- Jean-Paul BLANC / /--/--// quelque-part (somewhere) |/| L | en (in) /|| = ||| FRANCE
filh
Eric Lévénez wrote:
Le 14/07/05 17:18, dans <1gzp994.1nha9cgt1ivfpN%, « FiLH »
Dans ce cas : sizeof(char) * NBY
Par définition, en C, sizeof(char) vaut 1 dans tous les cas, même si char est un 32 bits, alors il ne faut jamais fait "* sizeof(char)", car cela ne sert à rien, autant faire "/ sizeof(char)". :-)
Sauf que... préciser un sizeof char permet au lecteur de savoir ce qu'on compte. Alors que ne rien mettre ne donne aucune info.
Et oui... le code c'est aussi fait pour dire des choses aux lecteurs humains !
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Rolland Barthes. http://www.filh.org
Eric Lévénez <eric@levenez.com> wrote:
Le 14/07/05 17:18, dans <1gzp994.1nha9cgt1ivfpN%filh@filh.orgie>, « FiLH »
Dans ce cas : sizeof(char) * NBY
Par définition, en C, sizeof(char) vaut 1 dans tous les cas, même si char
est un 32 bits, alors il ne faut jamais fait "* sizeof(char)", car cela ne
sert à rien, autant faire "/ sizeof(char)". :-)
Sauf que... préciser un sizeof char permet au lecteur de savoir ce qu'on
compte. Alors que ne rien mettre ne donne aucune info.
Et oui... le code c'est aussi fait pour dire des choses aux lecteurs
humains !
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Rolland Barthes.
http://www.filh.org
Le 14/07/05 17:18, dans <1gzp994.1nha9cgt1ivfpN%, « FiLH »
Dans ce cas : sizeof(char) * NBY
Par définition, en C, sizeof(char) vaut 1 dans tous les cas, même si char est un 32 bits, alors il ne faut jamais fait "* sizeof(char)", car cela ne sert à rien, autant faire "/ sizeof(char)". :-)
Sauf que... préciser un sizeof char permet au lecteur de savoir ce qu'on compte. Alors que ne rien mettre ne donne aucune info.
Et oui... le code c'est aussi fait pour dire des choses aux lecteurs humains !
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Rolland Barthes. http://www.filh.org
Quand on n'a rien à dire on attaque sur l'orthographe...
Décidément les concepteurs de virus ont vraiment la part belle.
???
90% les trous de sécus sont basés sur des dépassements..
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Rolland Barthes. http://www.filh.org
Quand on n'a rien à dire on attaque sur l'orthographe...
Décidément les concepteurs de virus ont vraiment la part belle.
???
90% les trous de sécus sont basés sur des dépassements..
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Rolland Barthes.
http://www.filh.org
Quand on n'a rien à dire on attaque sur l'orthographe...
Décidément les concepteurs de virus ont vraiment la part belle.
???
90% les trous de sécus sont basés sur des dépassements..
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Rolland Barthes. http://www.filh.org
filh
JPaul wrote:
Nicolas Seriot wrote:
Voici un programme très rapide, adapté d'un exercice fait à l'école d'ingénieurs.
Hum, si l'algorithme est joli, il faut reconnaître comme le suggère FiLH que la programmation n'est pas rigoureuse, et qu'il serait bon d'apprendre à nos futurs ingénieurs à chasser sans répit les débordements de zone mémoire!...
Je te propose (au moins) les quelques corrections suivantes (à commencer par la fin pour éviter les renumérotations de lignes) :
ligne 55 : int vector[256];
Pourquoi 256 ? Pourquoi pas 357 ?
Le malloc c'est trop compliqué ?
Pourquoi mettre en dur des limites dans le code ?
FiLH -- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Rolland Barthes. http://www.filh.org
JPaul <blanc@empty.org> wrote:
Nicolas Seriot <junk@seriot.ch> wrote:
Voici un programme très rapide, adapté d'un exercice fait à l'école
d'ingénieurs.
Hum, si l'algorithme est joli, il faut reconnaître comme le suggère FiLH
que la programmation n'est pas rigoureuse, et qu'il serait bon
d'apprendre à nos futurs ingénieurs à chasser sans répit les
débordements de zone mémoire!...
Je te propose (au moins) les quelques corrections suivantes (à
commencer par la fin pour éviter les renumérotations de lignes) :
ligne 55 :
int vector[256];
Pourquoi 256 ? Pourquoi pas 357 ?
Le malloc c'est trop compliqué ?
Pourquoi mettre en dur des limites dans le code ?
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Rolland Barthes.
http://www.filh.org
Voici un programme très rapide, adapté d'un exercice fait à l'école d'ingénieurs.
Hum, si l'algorithme est joli, il faut reconnaître comme le suggère FiLH que la programmation n'est pas rigoureuse, et qu'il serait bon d'apprendre à nos futurs ingénieurs à chasser sans répit les débordements de zone mémoire!...
Je te propose (au moins) les quelques corrections suivantes (à commencer par la fin pour éviter les renumérotations de lignes) :
ligne 55 : int vector[256];
Pourquoi 256 ? Pourquoi pas 357 ?
Le malloc c'est trop compliqué ?
Pourquoi mettre en dur des limites dans le code ?
FiLH -- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Rolland Barthes. http://www.filh.org
DINH Viêt Hoà
Le malloc c'est trop compliqué ?
le malloc() c'est moins efficace qu'une allocation sur pile. Et optionnellement, oui, c'est plus compliqué qu'une allocation sur pile.
-- DINH V. Hoa,
"un bar branché, c'est un cyber-café" -- j.j.
Le malloc c'est trop compliqué ?
le malloc() c'est moins efficace qu'une allocation sur pile.
Et optionnellement, oui, c'est plus compliqué qu'une allocation sur
pile.
le malloc() c'est moins efficace qu'une allocation sur pile. Et optionnellement, oui, c'est plus compliqué qu'une allocation sur pile.
-- DINH V. Hoa,
"un bar branché, c'est un cyber-café" -- j.j.
filh
DINH Viêt Hoà wrote:
Le malloc c'est trop compliqué ?
le malloc() c'est moins efficace qu'une allocation sur pile.
Oui mais - 1 c'est dynamique et ça permet de fonctionner toujours - 2 dans le cas qui nous concerne, tu plaisantes j'espère...
Et optionnellement, oui, c'est plus compliqué qu'une allocation sur pile.
Heu... oui bien programmer c'est plus compliqué.
Sortir des algos à la con du genre de ceux là et pas savoir gérer un malloc, faut peut-être pas abuser non ?
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Rolland Barthes. http://www.filh.org
DINH Viêt Hoà <dinh.viet.hoa@free.fr> wrote:
Le malloc c'est trop compliqué ?
le malloc() c'est moins efficace qu'une allocation sur pile.
Oui mais
- 1 c'est dynamique et ça permet de fonctionner toujours
- 2 dans le cas qui nous concerne, tu plaisantes j'espère...
Et optionnellement, oui, c'est plus compliqué qu'une allocation sur
pile.
Heu... oui bien programmer c'est plus compliqué.
Sortir des algos à la con du genre de ceux là et pas savoir gérer un
malloc, faut peut-être pas abuser non ?
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Rolland Barthes.
http://www.filh.org
le malloc() c'est moins efficace qu'une allocation sur pile.
Oui mais - 1 c'est dynamique et ça permet de fonctionner toujours - 2 dans le cas qui nous concerne, tu plaisantes j'espère...
Et optionnellement, oui, c'est plus compliqué qu'une allocation sur pile.
Heu... oui bien programmer c'est plus compliqué.
Sortir des algos à la con du genre de ceux là et pas savoir gérer un malloc, faut peut-être pas abuser non ?
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Rolland Barthes. http://www.filh.org
Eric Lévénez
Le 14/07/05 17:58, dans <1gzpb4u.1ciepql1ns6e3vN%, « FiLH » a écrit :
Eric Lévénez wrote:
Le 14/07/05 17:18, dans <1gzp994.1nha9cgt1ivfpN%, « FiLH »
Dans ce cas : sizeof(char) * NBY
Par définition, en C, sizeof(char) vaut 1 dans tous les cas, même si char est un 32 bits, alors il ne faut jamais fait "* sizeof(char)", car cela ne sert à rien, autant faire "/ sizeof(char)". :-)
Sauf que... préciser un sizeof char permet au lecteur de savoir ce qu'on compte. Alors que ne rien mettre ne donne aucune info.
En C standard, toutes les tailles sont des multiples d'un char, donc préciser la taille d'un char à un endroit du code est inutile ou alors il faudrait aussi le dire partout, comme sur un simple "*p++"...
Et oui... le code c'est aussi fait pour dire des choses aux lecteurs humains !
Le lecteur humain est sensé connaître le C, hors hélas un programmeur qui fait un "* sizeof(char)" suppose trop souvent qu'un char vaut 8 bits et donc que sizeof(char) peut être > 1 sur d'autres architectures. Il suffit de demander à des "programmeurs" ce que vaut "sizeof(char)" sur des architectures 16 et 32 bits (comme les DSP), et là on tombe de haut, de très haut. Alors, au lieu de faire ce "* 1", il vaut mieux expliciter par un commentaire le pourquoi de la chose.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 14/07/05 17:58, dans <1gzpb4u.1ciepql1ns6e3vN%filh@filh.orgie>, « FiLH »
<filh@filh.orgie> a écrit :
Eric Lévénez <eric@levenez.com> wrote:
Le 14/07/05 17:18, dans <1gzp994.1nha9cgt1ivfpN%filh@filh.orgie>, « FiLH »
Dans ce cas : sizeof(char) * NBY
Par définition, en C, sizeof(char) vaut 1 dans tous les cas, même si char
est un 32 bits, alors il ne faut jamais fait "* sizeof(char)", car cela ne
sert à rien, autant faire "/ sizeof(char)". :-)
Sauf que... préciser un sizeof char permet au lecteur de savoir ce qu'on
compte. Alors que ne rien mettre ne donne aucune info.
En C standard, toutes les tailles sont des multiples d'un char, donc
préciser la taille d'un char à un endroit du code est inutile ou alors il
faudrait aussi le dire partout, comme sur un simple "*p++"...
Et oui... le code c'est aussi fait pour dire des choses aux lecteurs
humains !
Le lecteur humain est sensé connaître le C, hors hélas un programmeur qui
fait un "* sizeof(char)" suppose trop souvent qu'un char vaut 8 bits et donc
que sizeof(char) peut être > 1 sur d'autres architectures. Il suffit de
demander à des "programmeurs" ce que vaut "sizeof(char)" sur des
architectures 16 et 32 bits (comme les DSP), et là on tombe de haut, de très
haut. Alors, au lieu de faire ce "* 1", il vaut mieux expliciter par un
commentaire le pourquoi de la chose.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 14/07/05 17:58, dans <1gzpb4u.1ciepql1ns6e3vN%, « FiLH » a écrit :
Eric Lévénez wrote:
Le 14/07/05 17:18, dans <1gzp994.1nha9cgt1ivfpN%, « FiLH »
Dans ce cas : sizeof(char) * NBY
Par définition, en C, sizeof(char) vaut 1 dans tous les cas, même si char est un 32 bits, alors il ne faut jamais fait "* sizeof(char)", car cela ne sert à rien, autant faire "/ sizeof(char)". :-)
Sauf que... préciser un sizeof char permet au lecteur de savoir ce qu'on compte. Alors que ne rien mettre ne donne aucune info.
En C standard, toutes les tailles sont des multiples d'un char, donc préciser la taille d'un char à un endroit du code est inutile ou alors il faudrait aussi le dire partout, comme sur un simple "*p++"...
Et oui... le code c'est aussi fait pour dire des choses aux lecteurs humains !
Le lecteur humain est sensé connaître le C, hors hélas un programmeur qui fait un "* sizeof(char)" suppose trop souvent qu'un char vaut 8 bits et donc que sizeof(char) peut être > 1 sur d'autres architectures. Il suffit de demander à des "programmeurs" ce que vaut "sizeof(char)" sur des architectures 16 et 32 bits (comme les DSP), et là on tombe de haut, de très haut. Alors, au lieu de faire ce "* 1", il vaut mieux expliciter par un commentaire le pourquoi de la chose.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
DINH Viêt Hoà
Oui mais - 1 c'est dynamique et ça permet de fonctionner toujours
modulo les cas d'erreurs à gérer. Le traitement de l'erreur de malloc() peut vite générer en l'écriture de code à longueur indéterminée.
Et optionnellement, oui, c'est plus compliqué qu'une allocation sur pile.
Heu... oui bien programmer c'est plus compliqué.
Le C est effectivement un langage à ne pas laisser entre toutes mains.
Sortir des algos à la con du genre de ceux là et pas savoir gérer un malloc, faut peut-être pas abuser non ?
J'avouerai que je n'ai pas bien compris ce que faisait le programme et qu'il n'apparaît pas vraiment clairement qu'il fait une recherche de chaîne dans le programme. Du coup, je n'ai pas bien vu l'intérêt de la proposition du malloc() au lieu de cette déclaration de tableau.
-- DINH V. Hoa,
"un bar branché, c'est un cyber-café" -- j.j.
Oui mais
- 1 c'est dynamique et ça permet de fonctionner toujours
modulo les cas d'erreurs à gérer.
Le traitement de l'erreur de malloc() peut vite générer en l'écriture de
code à longueur indéterminée.
Et optionnellement, oui, c'est plus compliqué qu'une allocation sur
pile.
Heu... oui bien programmer c'est plus compliqué.
Le C est effectivement un langage à ne pas laisser entre toutes mains.
Sortir des algos à la con du genre de ceux là et pas savoir gérer un
malloc, faut peut-être pas abuser non ?
J'avouerai que je n'ai pas bien compris ce que faisait le programme et
qu'il n'apparaît pas vraiment clairement qu'il fait une recherche de
chaîne dans le programme.
Du coup, je n'ai pas bien vu l'intérêt de la proposition du malloc() au
lieu de cette déclaration de tableau.
Oui mais - 1 c'est dynamique et ça permet de fonctionner toujours
modulo les cas d'erreurs à gérer. Le traitement de l'erreur de malloc() peut vite générer en l'écriture de code à longueur indéterminée.
Et optionnellement, oui, c'est plus compliqué qu'une allocation sur pile.
Heu... oui bien programmer c'est plus compliqué.
Le C est effectivement un langage à ne pas laisser entre toutes mains.
Sortir des algos à la con du genre de ceux là et pas savoir gérer un malloc, faut peut-être pas abuser non ?
J'avouerai que je n'ai pas bien compris ce que faisait le programme et qu'il n'apparaît pas vraiment clairement qu'il fait une recherche de chaîne dans le programme. Du coup, je n'ai pas bien vu l'intérêt de la proposition du malloc() au lieu de cette déclaration de tableau.
-- DINH V. Hoa,
"un bar branché, c'est un cyber-café" -- j.j.
filh
Eric Lévénez wrote:
Sauf que... préciser un sizeof char permet au lecteur de savoir ce qu'on compte. Alors que ne rien mettre ne donne aucune info.
En C standard, toutes les tailles sont des multiples d'un char, donc préciser la taille d'un char à un endroit du code est inutile
Si je fais un malloc(345), j'alloue 345 octets sans savoir de quoi il s'agit.
Si je fais un malloc(354 * sizeof (char)) j'alloue pour stocker 354 char.
C'est tout. Ça évite un commentaire ça précise un usage.
Je sais,les « vrais programmeurs » n'ont pas besoin de ça, et le compilateur s'en fout (mais je m'en fous que le compilateur s'en foute).
Mais on en a soupé des bugs des « vrais programmeurs ».
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Rolland Barthes. http://www.filh.org
Eric Lévénez <eric@levenez.com> wrote:
Sauf que... préciser un sizeof char permet au lecteur de savoir ce qu'on
compte. Alors que ne rien mettre ne donne aucune info.
En C standard, toutes les tailles sont des multiples d'un char, donc
préciser la taille d'un char à un endroit du code est inutile
Si je fais un malloc(345), j'alloue 345 octets sans savoir de quoi il
s'agit.
Si je fais un malloc(354 * sizeof (char)) j'alloue pour stocker 354
char.
C'est tout. Ça évite un commentaire ça précise un usage.
Je sais,les « vrais programmeurs » n'ont pas besoin de ça, et le
compilateur s'en fout (mais je m'en fous que le compilateur s'en foute).
Mais on en a soupé des bugs des « vrais programmeurs ».
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Rolland Barthes.
http://www.filh.org
Sauf que... préciser un sizeof char permet au lecteur de savoir ce qu'on compte. Alors que ne rien mettre ne donne aucune info.
En C standard, toutes les tailles sont des multiples d'un char, donc préciser la taille d'un char à un endroit du code est inutile
Si je fais un malloc(345), j'alloue 345 octets sans savoir de quoi il s'agit.
Si je fais un malloc(354 * sizeof (char)) j'alloue pour stocker 354 char.
C'est tout. Ça évite un commentaire ça précise un usage.
Je sais,les « vrais programmeurs » n'ont pas besoin de ça, et le compilateur s'en fout (mais je m'en fous que le compilateur s'en foute).
Mais on en a soupé des bugs des « vrais programmeurs ».
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Rolland Barthes. http://www.filh.org
