Voici donc ce qui devrait arriver dans les pages de man.
Par rapport à ce que nous avions proposé, les parties "WARNING"
et "BUG" ont été oublié, pour ne reprendre que la description
de ce qu'elles font, pas les mises en garde.
DESCRIPTION
The strcat() function appends the src string to the dest
string, overwriting the null character (`\0') at the end of
dest, and then adds a terminating null character. The
strings may not overlap, and the dest string must have
enough space for the result.
The strncat() function is similar, except that
* it will use at most n characters from src; and
* src does not need to be null terminated if it contains n
or more characters.
As with strcat(), the resulting string in dest is always
null terminated.
If src contains n or more characters, strcat() writes n+1
characters to dest (n from src plus the terminating null
character). Therefore, the size of dest must be at least
strlen(dest)+n+1.
Si le type int (type choisi pour i) est plus petit que size_t, il risque d'y avoir des problèmes...
Oui, tout à fait. C'est marrant, c'est le genre de chose auquelles je n'étais pas sensible en 2004, et qui me saute aux yeux en 2007. Sauf que là, le copier/coller.
Je vais reporter le pb.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Le 19-06-2007, Vincent Lefevre <vincent+news@vinc17.org> a écrit :
Dans l'article <slrnf7fequ.3mv.Marc.Boyer@localhost.localdomain>,
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> écrit:
Si le type int (type choisi pour i) est plus petit que size_t,
il risque d'y avoir des problèmes...
Oui, tout à fait.
C'est marrant, c'est le genre de chose auquelles je n'étais pas
sensible en 2004, et qui me saute aux yeux en 2007. Sauf que là,
le copier/coller.
Je vais reporter le pb.
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Si le type int (type choisi pour i) est plus petit que size_t, il risque d'y avoir des problèmes...
Oui, tout à fait. C'est marrant, c'est le genre de chose auquelles je n'étais pas sensible en 2004, et qui me saute aux yeux en 2007. Sauf que là, le copier/coller.
Je vais reporter le pb.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Voici donc ce qui devrait arriver dans les pages de man. Par rapport à ce que nous avions proposé, les parties "WARNING" et "BUG" ont été oublié, pour ne reprendre que la description de ce qu'elles font, pas les mises en garde.
Pas glop ! Autant dire que la proposition a été vidée de sa substance. Il faut *FORTEMENT* décourager l'utilisation de ces fonctions décadentes, surtout strncpy ! Se contenter de décrire les particularités de leur sémantique ne sert à rien : la plupart des programmeurs, même chevronnés pensent en connaitre déjà l'usage et l'intérêt.
Dans nos projets, nous avons ajouté les directives suivantes aux headers :
et encore plus avec des gcc plus récents, et pas question de laisser des warnings soit-disant inoffensifs... -Werror fait passer la tentation de la facilité.
Il faut en finir avec le code crade qui compile par miracle et ne fonctionne que de façon approximative, à plus ou moins 1 près.
DESCRIPTION The strcat() function appends the src string to the dest string, overwriting the null character (` ') at the end of dest, and then adds a terminating null character. The strings may not overlap, and the dest string must have enough space for the result.
The strncat() function is similar, except that
* it will use at most n characters from src; and
* src does not need to be null terminated if it contains n or more characters.
As with strcat(), the resulting string in dest is always null terminated.
If src contains n or more characters, strcat() writes n+1 characters to dest (n from src plus the terminating null character). Therefore, the size of dest must be at least strlen(dest)+n+1.
RETURN VALUE The strcat() and strncat() functions return a pointer to the resulting string dest.
CONFORMING TO SVr4, 4.3BSD, C89, C99.
SEE ALSO bcopy(3), memccpy(3), memcpy(3), strcpy(3), strncpy(3), wcscat(3), wcsncat(3)
-- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le message
de news: slrnf7fequ.3mv.Marc.Boyer@localhost.localdomain...
Voici donc ce qui devrait arriver dans les pages de man.
Par rapport à ce que nous avions proposé, les parties "WARNING"
et "BUG" ont été oublié, pour ne reprendre que la description
de ce qu'elles font, pas les mises en garde.
Pas glop !
Autant dire que la proposition a été vidée de sa substance.
Il faut *FORTEMENT* décourager l'utilisation de ces fonctions décadentes,
surtout strncpy !
Se contenter de décrire les particularités de leur sémantique ne sert à rien
: la plupart des programmeurs, même chevronnés pensent en connaitre déjà
l'usage et l'intérêt.
Dans nos projets, nous avons ajouté les directives suivantes aux headers :
et encore plus avec des gcc plus récents, et pas question de laisser des
warnings soit-disant inoffensifs... -Werror fait passer la tentation de la
facilité.
Il faut en finir avec le code crade qui compile par miracle et ne fonctionne
que de façon approximative, à plus ou moins 1 près.
DESCRIPTION
The strcat() function appends the src string to the dest
string, overwriting the null character (` ') at the end of
dest, and then adds a terminating null character. The
strings may not overlap, and the dest string must have
enough space for the result.
The strncat() function is similar, except that
* it will use at most n characters from src; and
* src does not need to be null terminated if it contains n
or more characters.
As with strcat(), the resulting string in dest is always
null terminated.
If src contains n or more characters, strcat() writes n+1
characters to dest (n from src plus the terminating null
character). Therefore, the size of dest must be at least
strlen(dest)+n+1.
Voici donc ce qui devrait arriver dans les pages de man. Par rapport à ce que nous avions proposé, les parties "WARNING" et "BUG" ont été oublié, pour ne reprendre que la description de ce qu'elles font, pas les mises en garde.
Pas glop ! Autant dire que la proposition a été vidée de sa substance. Il faut *FORTEMENT* décourager l'utilisation de ces fonctions décadentes, surtout strncpy ! Se contenter de décrire les particularités de leur sémantique ne sert à rien : la plupart des programmeurs, même chevronnés pensent en connaitre déjà l'usage et l'intérêt.
Dans nos projets, nous avons ajouté les directives suivantes aux headers :
et encore plus avec des gcc plus récents, et pas question de laisser des warnings soit-disant inoffensifs... -Werror fait passer la tentation de la facilité.
Il faut en finir avec le code crade qui compile par miracle et ne fonctionne que de façon approximative, à plus ou moins 1 près.
DESCRIPTION The strcat() function appends the src string to the dest string, overwriting the null character (` ') at the end of dest, and then adds a terminating null character. The strings may not overlap, and the dest string must have enough space for the result.
The strncat() function is similar, except that
* it will use at most n characters from src; and
* src does not need to be null terminated if it contains n or more characters.
As with strcat(), the resulting string in dest is always null terminated.
If src contains n or more characters, strcat() writes n+1 characters to dest (n from src plus the terminating null character). Therefore, the size of dest must be at least strlen(dest)+n+1.
RETURN VALUE The strcat() and strncat() functions return a pointer to the resulting string dest.
CONFORMING TO SVr4, 4.3BSD, C89, C99.
SEE ALSO bcopy(3), memccpy(3), memcpy(3), strcpy(3), strncpy(3), wcscat(3), wcsncat(3)
-- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Gabriel Dos Reis
Marc Boyer writes:
| > Pareil pour les options de compilation : | > | > -O2 | > -funsigned-char | | Est-ce raisonnable ? Est-ce que ça ne laisse pas le programmeur se | reposer sur le fait que les char sont non signés ? Ne vaut il mieux | pas le forcer à précier le signe des char à chaque usage ?
Oui. Utiliser -funsignd-char, c'est chercher des problemes lorsqu'on n'est pas en train de batir le systeme.
| | > -fstrict-aliasing -Wall -W -Werror -Wchar-subscripts -Wundef | > -Wshadow | > -D"index(s,c)=index__(s,c)" | | C'est un truc à vous, ça... | | > -Wcast-align -Wwrite-strings -Wsign-compare | > -Wunused | > -Wno-unused-parameter | | Tient, pourquoi donc ? | Moi, je suis plutôt pour la démarche. | void foo(int x, int y){ | (void) y; // unused parameter, parce que blabla...
Mon dieu !
-- Gaby
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
| > Pareil pour les options de compilation :
| >
| > -O2
| > -funsigned-char
|
| Est-ce raisonnable ? Est-ce que ça ne laisse pas le programmeur se
| reposer sur le fait que les char sont non signés ? Ne vaut il mieux
| pas le forcer à précier le signe des char à chaque usage ?
Oui. Utiliser -funsignd-char, c'est chercher des problemes lorsqu'on
n'est pas en train de batir le systeme.
|
| > -fstrict-aliasing -Wall -W -Werror -Wchar-subscripts -Wundef
| > -Wshadow
| > -D"index(s,c)=index__(s,c)"
|
| C'est un truc à vous, ça...
|
| > -Wcast-align -Wwrite-strings -Wsign-compare
| > -Wunused
| > -Wno-unused-parameter
|
| Tient, pourquoi donc ?
| Moi, je suis plutôt pour la démarche.
| void foo(int x, int y){
| (void) y; // unused parameter, parce que blabla...
| > Pareil pour les options de compilation : | > | > -O2 | > -funsigned-char | | Est-ce raisonnable ? Est-ce que ça ne laisse pas le programmeur se | reposer sur le fait que les char sont non signés ? Ne vaut il mieux | pas le forcer à précier le signe des char à chaque usage ?
Oui. Utiliser -funsignd-char, c'est chercher des problemes lorsqu'on n'est pas en train de batir le systeme.
| | > -fstrict-aliasing -Wall -W -Werror -Wchar-subscripts -Wundef | > -Wshadow | > -D"index(s,c)=index__(s,c)" | | C'est un truc à vous, ça... | | > -Wcast-align -Wwrite-strings -Wsign-compare | > -Wunused | > -Wno-unused-parameter | | Tient, pourquoi donc ? | Moi, je suis plutôt pour la démarche. | void foo(int x, int y){ | (void) y; // unused parameter, parce que blabla...
Mon dieu !
-- Gaby
Marc Boyer
Le 19-06-2007, Charlie Gordon a écrit :
"Marc Boyer" a écrit dans le message de news:
Voici donc ce qui devrait arriver dans les pages de man. Par rapport à ce que nous avions proposé, les parties "WARNING" et "BUG" ont été oublié, pour ne reprendre que la description de ce qu'elles font, pas les mises en garde.
Autant dire que la proposition a été vidée de sa substance. Il faut *FORTEMENT* décourager l'utilisation de ces fonctions décadentes, surtout strncpy !
C'est une page de man, pas un cours de C.
Se contenter de décrire les particularités de leur sémantique ne sert à rien : la plupart des programmeurs, même chevronnés pensent en connaitre déjà l'usage et l'intérêt.
Est-ce que ceux ci liraient la notice "Warning" en fin de page de man?
Dans nos projets, nous avons ajouté les directives suivantes aux headers :
Est-ce raisonnable ? Est-ce que ça ne laisse pas le programmeur se reposer sur le fait que les char sont non signés ? Ne vaut il mieux pas le forcer à précier le signe des char à chaque usage ?
et encore plus avec des gcc plus récents, et pas question de laisser des warnings soit-disant inoffensifs... -Werror fait passer la tentation de la facilité.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Le 19-06-2007, Charlie Gordon <news@chqrlie.org> a écrit :
"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le message
de news: slrnf7fequ.3mv.Marc.Boyer@localhost.localdomain...
Voici donc ce qui devrait arriver dans les pages de man.
Par rapport à ce que nous avions proposé, les parties "WARNING"
et "BUG" ont été oublié, pour ne reprendre que la description
de ce qu'elles font, pas les mises en garde.
Autant dire que la proposition a été vidée de sa substance.
Il faut *FORTEMENT* décourager l'utilisation de ces fonctions décadentes,
surtout strncpy !
C'est une page de man, pas un cours de C.
Se contenter de décrire les particularités de leur sémantique ne sert à rien
: la plupart des programmeurs, même chevronnés pensent en connaitre déjà
l'usage et l'intérêt.
Est-ce que ceux ci liraient la notice "Warning" en fin de page de man?
Dans nos projets, nous avons ajouté les directives suivantes aux headers :
Est-ce raisonnable ? Est-ce que ça ne laisse pas le programmeur se
reposer sur le fait que les char sont non signés ? Ne vaut il mieux
pas le forcer à précier le signe des char à chaque usage ?
et encore plus avec des gcc plus récents, et pas question de laisser des
warnings soit-disant inoffensifs... -Werror fait passer la tentation de la
facilité.
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Voici donc ce qui devrait arriver dans les pages de man. Par rapport à ce que nous avions proposé, les parties "WARNING" et "BUG" ont été oublié, pour ne reprendre que la description de ce qu'elles font, pas les mises en garde.
Autant dire que la proposition a été vidée de sa substance. Il faut *FORTEMENT* décourager l'utilisation de ces fonctions décadentes, surtout strncpy !
C'est une page de man, pas un cours de C.
Se contenter de décrire les particularités de leur sémantique ne sert à rien : la plupart des programmeurs, même chevronnés pensent en connaitre déjà l'usage et l'intérêt.
Est-ce que ceux ci liraient la notice "Warning" en fin de page de man?
Dans nos projets, nous avons ajouté les directives suivantes aux headers :
Est-ce raisonnable ? Est-ce que ça ne laisse pas le programmeur se reposer sur le fait que les char sont non signés ? Ne vaut il mieux pas le forcer à précier le signe des char à chaque usage ?
et encore plus avec des gcc plus récents, et pas question de laisser des warnings soit-disant inoffensifs... -Werror fait passer la tentation de la facilité.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Gabriel Dos Reis
Marc Boyer writes:
| Le 20-06-2007, Gabriel Dos Reis a écrit : | > Marc Boyer writes: | >| > -Wno-unused-parameter | >| | >| Tient, pourquoi donc ? | >| Moi, je suis plutôt pour la démarche. | >| void foo(int x, int y){ | >| (void) y; // unused parameter, parce que blabla... | > | > Mon dieu ! | | Pourquoi ? Tu fais comment quand tu as un paramètre qui sert | plus à rien ?
Je n'ecris pas ce que je considere une abomination, e.g. le cast ci-dessus avec ou sans commentaire.
Je laisse le compilateur raler -- c'est une limitation stupide du langage.
Certains utilisent l'ignoble __attributte__((unused)) de GCC, mais je ne l'ecris pas dans mes propres codes.
-- Gaby
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
| Le 20-06-2007, Gabriel Dos Reis <gdr@integrable-solutions.net> a écrit :
| > Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
| >| > -Wno-unused-parameter
| >|
| >| Tient, pourquoi donc ?
| >| Moi, je suis plutôt pour la démarche.
| >| void foo(int x, int y){
| >| (void) y; // unused parameter, parce que blabla...
| >
| > Mon dieu !
|
| Pourquoi ? Tu fais comment quand tu as un paramètre qui sert
| plus à rien ?
Je n'ecris pas ce que je considere une abomination, e.g. le cast
ci-dessus avec ou sans commentaire.
Je laisse le compilateur raler -- c'est une limitation stupide du langage.
Certains utilisent l'ignoble __attributte__((unused)) de GCC, mais
je ne l'ecris pas dans mes propres codes.
| Le 20-06-2007, Gabriel Dos Reis a écrit : | > Marc Boyer writes: | >| > -Wno-unused-parameter | >| | >| Tient, pourquoi donc ? | >| Moi, je suis plutôt pour la démarche. | >| void foo(int x, int y){ | >| (void) y; // unused parameter, parce que blabla... | > | > Mon dieu ! | | Pourquoi ? Tu fais comment quand tu as un paramètre qui sert | plus à rien ?
Je n'ecris pas ce que je considere une abomination, e.g. le cast ci-dessus avec ou sans commentaire.
Je laisse le compilateur raler -- c'est une limitation stupide du langage.
Certains utilisent l'ignoble __attributte__((unused)) de GCC, mais je ne l'ecris pas dans mes propres codes.
-- Gaby
Gabriel Dos Reis
(Marc Espie) writes:
| C'est un des trucs ou j'ai toujours pas compris que le comite de | normalisation n'ait pas adopte la convention C++... ils sont | rapides pour prendre les mot-cles C++ et les re-adapter a la | sauce un peu plus cradingue (voir les incoherences de const et void * | en C), par contre, une construction aussi bete que | | void | f(int x, int) | { | } | | | pas un pour la reprendre...
Il n'y aurait pas de la place pour mettre une semantique autre que celle de C++, donc ce serait contraire aux Principes.
-- Gaby
espie@lain.home (Marc Espie) writes:
| C'est un des trucs ou j'ai toujours pas compris que le comite de
| normalisation n'ait pas adopte la convention C++... ils sont
| rapides pour prendre les mot-cles C++ et les re-adapter a la
| sauce un peu plus cradingue (voir les incoherences de const et void *
| en C), par contre, une construction aussi bete que
|
| void
| f(int x, int)
| {
| }
|
|
| pas un pour la reprendre...
Il n'y aurait pas de la place pour mettre une semantique autre que
celle de C++, donc ce serait contraire aux Principes.
| C'est un des trucs ou j'ai toujours pas compris que le comite de | normalisation n'ait pas adopte la convention C++... ils sont | rapides pour prendre les mot-cles C++ et les re-adapter a la | sauce un peu plus cradingue (voir les incoherences de const et void * | en C), par contre, une construction aussi bete que | | void | f(int x, int) | { | } | | | pas un pour la reprendre...
Il n'y aurait pas de la place pour mettre une semantique autre que celle de C++, donc ce serait contraire aux Principes.
-- Gaby
Gabriel Dos Reis
Marc Boyer writes:
| Le 20-06-2007, Gabriel Dos Reis a écrit : | > Marc Boyer writes: | > | >| Le 20-06-2007, Gabriel Dos Reis a écrit : | >| > Marc Boyer writes: | >| >| > -Wno-unused-parameter | >| >| | >| >| Tient, pourquoi donc ? | >| >| Moi, je suis plutôt pour la démarche. | >| >| void foo(int x, int y){ | >| >| (void) y; // unused parameter, parce que blabla... | >| > | >| > Mon dieu ! | >| | >| Pourquoi ? Tu fais comment quand tu as un paramètre qui sert | >| plus à rien ? | > | > Je n'ecris pas ce que je considere une abomination, e.g. le cast | > ci-dessus avec ou sans commentaire. | | En quoi est-ce une abomination ? C'est une sorte de #pragma | popularisé par l'usage.
C'est probablement parce que je n'ai pas l'imagination assez debordante pour voir cela comme une "sorte de pragma popularise par l'usage" que je trouve que c'est une abomination. Et je trouve aussi que les pragmas sont des abominations, alors je ne suis pas sure que ce soit une analogie qui m'aidera beaucoup.
| | > Je laisse le compilateur raler -- c'est une limitation stupide du langage. | > | > Certains utilisent l'ignoble __attributte__((unused)) de GCC, mais | > je ne l'ecris pas dans mes propres codes. | | Sauf que cet __attributte__ est spécifique à GCC non ? | Alors que le (void) est plus populaire, pour un résultat | semblable, non ?
Je n'ecris pas et je n'enseigne pas mes eleves a ecrire du code populaire. J'essaie d'ecrire du code simple, correcte, lisible et maintenable. (Je n'y arrive pas toujours, mais j'essaie).
-- Gaby
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
| Le 20-06-2007, Gabriel Dos Reis <gdr@integrable-solutions.net> a écrit :
| > Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
| >
| >| Le 20-06-2007, Gabriel Dos Reis <gdr@integrable-solutions.net> a écrit :
| >| > Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
| >| >| > -Wno-unused-parameter
| >| >|
| >| >| Tient, pourquoi donc ?
| >| >| Moi, je suis plutôt pour la démarche.
| >| >| void foo(int x, int y){
| >| >| (void) y; // unused parameter, parce que blabla...
| >| >
| >| > Mon dieu !
| >|
| >| Pourquoi ? Tu fais comment quand tu as un paramètre qui sert
| >| plus à rien ?
| >
| > Je n'ecris pas ce que je considere une abomination, e.g. le cast
| > ci-dessus avec ou sans commentaire.
|
| En quoi est-ce une abomination ? C'est une sorte de #pragma
| popularisé par l'usage.
C'est probablement parce que je n'ai pas l'imagination assez debordante
pour voir cela comme une "sorte de pragma popularise par l'usage" que
je trouve que c'est une abomination. Et je trouve aussi que les
pragmas sont des abominations, alors je ne suis pas sure que ce soit
une analogie qui m'aidera beaucoup.
|
| > Je laisse le compilateur raler -- c'est une limitation stupide du langage.
| >
| > Certains utilisent l'ignoble __attributte__((unused)) de GCC, mais
| > je ne l'ecris pas dans mes propres codes.
|
| Sauf que cet __attributte__ est spécifique à GCC non ?
| Alors que le (void) est plus populaire, pour un résultat
| semblable, non ?
Je n'ecris pas et je n'enseigne pas mes eleves a ecrire du code
populaire. J'essaie d'ecrire du code simple, correcte, lisible et
maintenable. (Je n'y arrive pas toujours, mais j'essaie).
| Le 20-06-2007, Gabriel Dos Reis a écrit : | > Marc Boyer writes: | > | >| Le 20-06-2007, Gabriel Dos Reis a écrit : | >| > Marc Boyer writes: | >| >| > -Wno-unused-parameter | >| >| | >| >| Tient, pourquoi donc ? | >| >| Moi, je suis plutôt pour la démarche. | >| >| void foo(int x, int y){ | >| >| (void) y; // unused parameter, parce que blabla... | >| > | >| > Mon dieu ! | >| | >| Pourquoi ? Tu fais comment quand tu as un paramètre qui sert | >| plus à rien ? | > | > Je n'ecris pas ce que je considere une abomination, e.g. le cast | > ci-dessus avec ou sans commentaire. | | En quoi est-ce une abomination ? C'est une sorte de #pragma | popularisé par l'usage.
C'est probablement parce que je n'ai pas l'imagination assez debordante pour voir cela comme une "sorte de pragma popularise par l'usage" que je trouve que c'est une abomination. Et je trouve aussi que les pragmas sont des abominations, alors je ne suis pas sure que ce soit une analogie qui m'aidera beaucoup.
| | > Je laisse le compilateur raler -- c'est une limitation stupide du langage. | > | > Certains utilisent l'ignoble __attributte__((unused)) de GCC, mais | > je ne l'ecris pas dans mes propres codes. | | Sauf que cet __attributte__ est spécifique à GCC non ? | Alors que le (void) est plus populaire, pour un résultat | semblable, non ?
Je n'ecris pas et je n'enseigne pas mes eleves a ecrire du code populaire. J'essaie d'ecrire du code simple, correcte, lisible et maintenable. (Je n'y arrive pas toujours, mais j'essaie).
-- Gaby
Gabriel Dos Reis
Marc Boyer writes:
| Disons que ce n'est pas vraiment 'ma' doc.
Mais tu es en train de la changer, de l'ameliorer.
-- Gaby
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
| Disons que ce n'est pas vraiment 'ma' doc.
Mais tu es en train de la changer, de l'ameliorer.