Bonjour à tous,
pour ceux qui étaient déjà là à l'automne 2004 (ça fait un bail),
j'ai le plaisir d'annoncer que la ré-écriture des pages de man
linux str[n]cpy/str[n]cat que nous avions proposé sera inclue
dans la version 2.58.
Peut-être que cela diminuera le nombre de bug liés à ces fonctions.
Bonjour à tous,
pour ceux qui étaient déjà là à l'automne 2004 (ça fait un bail),
j'ai le plaisir d'annoncer que la ré-écriture des pages de man
linux str[n]cpy/str[n]cat que nous avions proposé sera inclue
dans la version 2.58.
Peut-être que cela diminuera le nombre de bug liés à ces fonctions.
Bonjour à tous,
pour ceux qui étaient déjà là à l'automne 2004 (ça fait un bail),
j'ai le plaisir d'annoncer que la ré-écriture des pages de man
linux str[n]cpy/str[n]cat que nous avions proposé sera inclue
dans la version 2.58.
Peut-être que cela diminuera le nombre de bug liés à ces fonctions.
In article ,
Marc Boyer wrote:Bonjour à tous,
pour ceux qui étaient déjà là à l'automne 2004 (ça fait un bail),
j'ai le plaisir d'annoncer que la ré-écriture des pages de man
linux str[n]cpy/str[n]cat que nous avions proposé sera inclue
dans la version 2.58.
Peut-être que cela diminuera le nombre de bug liés à ces fonctions.
La meilleure facon de diminuer le nombre de bugs liees a ces fonctions,
c'est d'enfin arriver a importer strlcpy/strlcat dans la glibc.
Mais ca, tant que vous aurez Ulrich Drepper sur le dos, ca va etre dur...
In article <slrnf7crvd.78s.Marc.Boyer@localhost.localdomain>,
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote:
Bonjour à tous,
pour ceux qui étaient déjà là à l'automne 2004 (ça fait un bail),
j'ai le plaisir d'annoncer que la ré-écriture des pages de man
linux str[n]cpy/str[n]cat que nous avions proposé sera inclue
dans la version 2.58.
Peut-être que cela diminuera le nombre de bug liés à ces fonctions.
La meilleure facon de diminuer le nombre de bugs liees a ces fonctions,
c'est d'enfin arriver a importer strlcpy/strlcat dans la glibc.
Mais ca, tant que vous aurez Ulrich Drepper sur le dos, ca va etre dur...
In article ,
Marc Boyer wrote:Bonjour à tous,
pour ceux qui étaient déjà là à l'automne 2004 (ça fait un bail),
j'ai le plaisir d'annoncer que la ré-écriture des pages de man
linux str[n]cpy/str[n]cat que nous avions proposé sera inclue
dans la version 2.58.
Peut-être que cela diminuera le nombre de bug liés à ces fonctions.
La meilleure facon de diminuer le nombre de bugs liees a ces fonctions,
c'est d'enfin arriver a importer strlcpy/strlcat dans la glibc.
Mais ca, tant que vous aurez Ulrich Drepper sur le dos, ca va etre dur...
Je suis pour la politique des petits pas: j'essaye déjà d'améliorer
ce que je peux contribuer à améliorer.
Je suis pour la politique des petits pas: j'essaye déjà d'améliorer
ce que je peux contribuer à améliorer.
Je suis pour la politique des petits pas: j'essaye déjà d'améliorer
ce que je peux contribuer à améliorer.
In article ,
Marc Boyer wrote:Je suis pour la politique des petits pas: j'essaye déjà d'améliorer
ce que je peux contribuer à améliorer.
<sarcasme>
C'est sur qu'importer deux malheureuses fonctions bien testees, utilisees
depuis des annees a peu pres partout ailleurs, c'est un progres enorme.
</sarcasme>
Mais bon, politiquement, ca ne le fait pas. Et puis les programmeurs
linux ne se plantent jamais dans l'utilisation de strcpy, c'est bien
connu. ;-)
In article <slrnf7ctvd.78s.Marc.Boyer@localhost.localdomain>,
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote:
Je suis pour la politique des petits pas: j'essaye déjà d'améliorer
ce que je peux contribuer à améliorer.
<sarcasme>
C'est sur qu'importer deux malheureuses fonctions bien testees, utilisees
depuis des annees a peu pres partout ailleurs, c'est un progres enorme.
</sarcasme>
Mais bon, politiquement, ca ne le fait pas. Et puis les programmeurs
linux ne se plantent jamais dans l'utilisation de strcpy, c'est bien
connu. ;-)
In article ,
Marc Boyer wrote:Je suis pour la politique des petits pas: j'essaye déjà d'améliorer
ce que je peux contribuer à améliorer.
<sarcasme>
C'est sur qu'importer deux malheureuses fonctions bien testees, utilisees
depuis des annees a peu pres partout ailleurs, c'est un progres enorme.
</sarcasme>
Mais bon, politiquement, ca ne le fait pas. Et puis les programmeurs
linux ne se plantent jamais dans l'utilisation de strcpy, c'est bien
connu. ;-)
Le 18-06-2007, Marc Espie a écrit :In article ,
Marc Boyer wrote:Je suis pour la politique des petits pas: j'essaye déjà d'améliorer
ce que je peux contribuer à améliorer.
<sarcasme>
C'est sur qu'importer deux malheureuses fonctions bien testees, utilisees
depuis des annees a peu pres partout ailleurs, c'est un progres enorme.
</sarcasme>
De quoi parles tu ? Des strl* ?Mais bon, politiquement, ca ne le fait pas. Et puis les programmeurs
linux ne se plantent jamais dans l'utilisation de strcpy, c'est bien
connu. ;-)
Je ne comprends pas très bien à qui tu parles et à quel degrès il
faut prendre tes propos. Si tu as les moyens d'influencer la prochaine
norme C ou les développeurs de la glibc, ne te gène pas.
En ce qui me concerne, après avoir constaté que les pages man linux
pouvaient être améliorée, j'ai proposé une nouvelle version (en 2004),
rédigée avec de nombreux contributeurs de fclc, et elle devrait
etre prise en compte.
Voilà,
Marc
PS: T'es à l'Epita maintenant ?
Le 18-06-2007, Marc Espie <espie@lain.home> a écrit :
In article <slrnf7ctvd.78s.Marc.Boyer@localhost.localdomain>,
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote:
Je suis pour la politique des petits pas: j'essaye déjà d'améliorer
ce que je peux contribuer à améliorer.
<sarcasme>
C'est sur qu'importer deux malheureuses fonctions bien testees, utilisees
depuis des annees a peu pres partout ailleurs, c'est un progres enorme.
</sarcasme>
De quoi parles tu ? Des strl* ?
Mais bon, politiquement, ca ne le fait pas. Et puis les programmeurs
linux ne se plantent jamais dans l'utilisation de strcpy, c'est bien
connu. ;-)
Je ne comprends pas très bien à qui tu parles et à quel degrès il
faut prendre tes propos. Si tu as les moyens d'influencer la prochaine
norme C ou les développeurs de la glibc, ne te gène pas.
En ce qui me concerne, après avoir constaté que les pages man linux
pouvaient être améliorée, j'ai proposé une nouvelle version (en 2004),
rédigée avec de nombreux contributeurs de fclc, et elle devrait
etre prise en compte.
Voilà,
Marc
PS: T'es à l'Epita maintenant ?
Le 18-06-2007, Marc Espie a écrit :In article ,
Marc Boyer wrote:Je suis pour la politique des petits pas: j'essaye déjà d'améliorer
ce que je peux contribuer à améliorer.
<sarcasme>
C'est sur qu'importer deux malheureuses fonctions bien testees, utilisees
depuis des annees a peu pres partout ailleurs, c'est un progres enorme.
</sarcasme>
De quoi parles tu ? Des strl* ?Mais bon, politiquement, ca ne le fait pas. Et puis les programmeurs
linux ne se plantent jamais dans l'utilisation de strcpy, c'est bien
connu. ;-)
Je ne comprends pas très bien à qui tu parles et à quel degrès il
faut prendre tes propos. Si tu as les moyens d'influencer la prochaine
norme C ou les développeurs de la glibc, ne te gène pas.
En ce qui me concerne, après avoir constaté que les pages man linux
pouvaient être améliorée, j'ai proposé une nouvelle version (en 2004),
rédigée avec de nombreux contributeurs de fclc, et elle devrait
etre prise en compte.
Voilà,
Marc
PS: T'es à l'Epita maintenant ?
Il se trouve qu'une alternative a ete ecrite: strlcpy/strlcat, avec
precisement comme cahier des charges d'etre super-simple a utiliser.
Elles remplissent ce cahier des charges, sont portables, et ont commence
a essaimer un peu partout (entre rsync, kde, tous les BSD, solaris, et
j'en passe)... sauf dans la glibc, avec un commentaire de Drepper qui
etait du genre `ces fonctions ne servent a rien, les vrais programmeurs
ne font pas d'erreur avec strcpy/strcat'.
Il se trouve qu'une alternative a ete ecrite: strlcpy/strlcat, avec
precisement comme cahier des charges d'etre super-simple a utiliser.
Elles remplissent ce cahier des charges, sont portables, et ont commence
a essaimer un peu partout (entre rsync, kde, tous les BSD, solaris, et
j'en passe)... sauf dans la glibc, avec un commentaire de Drepper qui
etait du genre `ces fonctions ne servent a rien, les vrais programmeurs
ne font pas d'erreur avec strcpy/strcat'.
Il se trouve qu'une alternative a ete ecrite: strlcpy/strlcat, avec
precisement comme cahier des charges d'etre super-simple a utiliser.
Elles remplissent ce cahier des charges, sont portables, et ont commence
a essaimer un peu partout (entre rsync, kde, tous les BSD, solaris, et
j'en passe)... sauf dans la glibc, avec un commentaire de Drepper qui
etait du genre `ces fonctions ne servent a rien, les vrais programmeurs
ne font pas d'erreur avec strcpy/strcat'.
Bonjour à tous,
pour ceux qui étaient déjà là à l'automne 2004 (ça fait un bail),
j'ai le plaisir d'annoncer que la ré-écriture des pages de man
linux str[n]cpy/str[n]cat que nous avions proposé sera inclue
dans la version 2.58.
Peut-être que cela diminuera le nombre de bug liés à ces fonctions.
Bonjour à tous,
pour ceux qui étaient déjà là à l'automne 2004 (ça fait un bail),
j'ai le plaisir d'annoncer que la ré-écriture des pages de man
linux str[n]cpy/str[n]cat que nous avions proposé sera inclue
dans la version 2.58.
Peut-être que cela diminuera le nombre de bug liés à ces fonctions.
Bonjour à tous,
pour ceux qui étaient déjà là à l'automne 2004 (ça fait un bail),
j'ai le plaisir d'annoncer que la ré-écriture des pages de man
linux str[n]cpy/str[n]cat que nous avions proposé sera inclue
dans la version 2.58.
Peut-être que cela diminuera le nombre de bug liés à ces fonctions.
On 2007-06-18, Marc Espie wrote:Il se trouve qu'une alternative a ete ecrite: strlcpy/strlcat, avec
precisement comme cahier des charges d'etre super-simple a utiliser.
Elles remplissent ce cahier des charges, sont portables, et ont commence
a essaimer un peu partout (entre rsync, kde, tous les BSD, solaris, et
j'en passe)... sauf dans la glibc, avec un commentaire de Drepper qui
etait du genre `ces fonctions ne servent a rien, les vrais programmeurs
ne font pas d'erreur avec strcpy/strcat'.
D'après Wikipedia (http://en.wikipedia.org/wiki/Strlcpy) :
"The strlcpy and strlcat functions are controversial. (...) Furthermore,
some, including Ulrich Drepper, argue that strlcpy and strlcat make
truncation errors easier for a programmer to ignore and thus can
introduce more bugs than they remove; consequently, these functions have
not been added to the GNU C Library."
On 2007-06-18, Marc Espie <espie@lain.home> wrote:
Il se trouve qu'une alternative a ete ecrite: strlcpy/strlcat, avec
precisement comme cahier des charges d'etre super-simple a utiliser.
Elles remplissent ce cahier des charges, sont portables, et ont commence
a essaimer un peu partout (entre rsync, kde, tous les BSD, solaris, et
j'en passe)... sauf dans la glibc, avec un commentaire de Drepper qui
etait du genre `ces fonctions ne servent a rien, les vrais programmeurs
ne font pas d'erreur avec strcpy/strcat'.
D'après Wikipedia (http://en.wikipedia.org/wiki/Strlcpy) :
"The strlcpy and strlcat functions are controversial. (...) Furthermore,
some, including Ulrich Drepper, argue that strlcpy and strlcat make
truncation errors easier for a programmer to ignore and thus can
introduce more bugs than they remove; consequently, these functions have
not been added to the GNU C Library."
On 2007-06-18, Marc Espie wrote:Il se trouve qu'une alternative a ete ecrite: strlcpy/strlcat, avec
precisement comme cahier des charges d'etre super-simple a utiliser.
Elles remplissent ce cahier des charges, sont portables, et ont commence
a essaimer un peu partout (entre rsync, kde, tous les BSD, solaris, et
j'en passe)... sauf dans la glibc, avec un commentaire de Drepper qui
etait du genre `ces fonctions ne servent a rien, les vrais programmeurs
ne font pas d'erreur avec strcpy/strcat'.
D'après Wikipedia (http://en.wikipedia.org/wiki/Strlcpy) :
"The strlcpy and strlcat functions are controversial. (...) Furthermore,
some, including Ulrich Drepper, argue that strlcpy and strlcat make
truncation errors easier for a programmer to ignore and thus can
introduce more bugs than they remove; consequently, these functions have
not been added to the GNU C Library."
Pas dirige contre toi, mais bien plutot contre Drepper and co.
Ca fait des annees que je vois des problemes lies a l'utilisation
de strcpy, strcat, strncpy, strncat... en gros, les gens ne savent
pas compter et se plantent regulierement de 1, et en plus strncpy et
strncat sont super-sournoises, et ne font presque jamais ce qu'on veut
(ou alors avec une efficacite douteuse).
Je ne compte plus le nombre de
debuts de trous de securite (voire de trous complets) lies a leur
utilisation... c'est reellement les sources les plus frequentes de
buffer overflow.
Il se trouve qu'une alternative a ete ecrite: strlcpy/strlcat, avec
precisement comme cahier des charges d'etre super-simple a utiliser.
Elles remplissent ce cahier des charges, sont portables, et ont commence
a essaimer un peu partout (entre rsync, kde, tous les BSD, solaris, et
j'en passe)... sauf dans la glibc, avec un commentaire de Drepper qui
etait du genre `ces fonctions ne servent a rien, les vrais programmeurs
ne font pas d'erreur avec strcpy/strcat'.
Donc bon... depuis le nombre d'annees que c'est comme ca, c'est tres
bien que tu sois arrive a faire bouger les pages de man de strcpy/strcat,
mais ca ne changera rien au probleme de fond, qui est que ces fonctions
sont dangereuses... et ca me degoute un peu que ca avance toujours a la
vitesse d'un escargot englue dans de la melasse.
Pour le reste, ben on peut faire de l'evangelisation... mais c'est sur
que si les deux fonctions etaient disponibles en magasin chez linux,
ca rendrait tout de suite l'adoption plus rapide.
Rappel: strlcpy et strlcat possedent des implementations triviales,
disponibles sous une license compatible avec a peu pres tout.
Voilà,
Marc
PS: T'es à l'Epita maintenant ?
Chut ! incognito... je poste ici en tant que developpeur OpenBSD.
j'essaie tant bien que mal d'inculquer des bases de developpement logiciel
propres a quelques etudiants...
Pas dirige contre toi, mais bien plutot contre Drepper and co.
Ca fait des annees que je vois des problemes lies a l'utilisation
de strcpy, strcat, strncpy, strncat... en gros, les gens ne savent
pas compter et se plantent regulierement de 1, et en plus strncpy et
strncat sont super-sournoises, et ne font presque jamais ce qu'on veut
(ou alors avec une efficacite douteuse).
Je ne compte plus le nombre de
debuts de trous de securite (voire de trous complets) lies a leur
utilisation... c'est reellement les sources les plus frequentes de
buffer overflow.
Il se trouve qu'une alternative a ete ecrite: strlcpy/strlcat, avec
precisement comme cahier des charges d'etre super-simple a utiliser.
Elles remplissent ce cahier des charges, sont portables, et ont commence
a essaimer un peu partout (entre rsync, kde, tous les BSD, solaris, et
j'en passe)... sauf dans la glibc, avec un commentaire de Drepper qui
etait du genre `ces fonctions ne servent a rien, les vrais programmeurs
ne font pas d'erreur avec strcpy/strcat'.
Donc bon... depuis le nombre d'annees que c'est comme ca, c'est tres
bien que tu sois arrive a faire bouger les pages de man de strcpy/strcat,
mais ca ne changera rien au probleme de fond, qui est que ces fonctions
sont dangereuses... et ca me degoute un peu que ca avance toujours a la
vitesse d'un escargot englue dans de la melasse.
Pour le reste, ben on peut faire de l'evangelisation... mais c'est sur
que si les deux fonctions etaient disponibles en magasin chez linux,
ca rendrait tout de suite l'adoption plus rapide.
Rappel: strlcpy et strlcat possedent des implementations triviales,
disponibles sous une license compatible avec a peu pres tout.
Voilà,
Marc
PS: T'es à l'Epita maintenant ?
Chut ! incognito... je poste ici en tant que developpeur OpenBSD.
j'essaie tant bien que mal d'inculquer des bases de developpement logiciel
propres a quelques etudiants...
Pas dirige contre toi, mais bien plutot contre Drepper and co.
Ca fait des annees que je vois des problemes lies a l'utilisation
de strcpy, strcat, strncpy, strncat... en gros, les gens ne savent
pas compter et se plantent regulierement de 1, et en plus strncpy et
strncat sont super-sournoises, et ne font presque jamais ce qu'on veut
(ou alors avec une efficacite douteuse).
Je ne compte plus le nombre de
debuts de trous de securite (voire de trous complets) lies a leur
utilisation... c'est reellement les sources les plus frequentes de
buffer overflow.
Il se trouve qu'une alternative a ete ecrite: strlcpy/strlcat, avec
precisement comme cahier des charges d'etre super-simple a utiliser.
Elles remplissent ce cahier des charges, sont portables, et ont commence
a essaimer un peu partout (entre rsync, kde, tous les BSD, solaris, et
j'en passe)... sauf dans la glibc, avec un commentaire de Drepper qui
etait du genre `ces fonctions ne servent a rien, les vrais programmeurs
ne font pas d'erreur avec strcpy/strcat'.
Donc bon... depuis le nombre d'annees que c'est comme ca, c'est tres
bien que tu sois arrive a faire bouger les pages de man de strcpy/strcat,
mais ca ne changera rien au probleme de fond, qui est que ces fonctions
sont dangereuses... et ca me degoute un peu que ca avance toujours a la
vitesse d'un escargot englue dans de la melasse.
Pour le reste, ben on peut faire de l'evangelisation... mais c'est sur
que si les deux fonctions etaient disponibles en magasin chez linux,
ca rendrait tout de suite l'adoption plus rapide.
Rappel: strlcpy et strlcat possedent des implementations triviales,
disponibles sous une license compatible avec a peu pres tout.
Voilà,
Marc
PS: T'es à l'Epita maintenant ?
Chut ! incognito... je poste ici en tant que developpeur OpenBSD.
j'essaie tant bien que mal d'inculquer des bases de developpement logiciel
propres a quelques etudiants...
"Marc Boyer" a écrit dans le message
de news:pour ceux qui étaient déjà là à l'automne 2004 (ça fait un bail),
j'ai le plaisir d'annoncer que la ré-écriture des pages de man
linux str[n]cpy/str[n]cat que nous avions proposé sera inclue
dans la version 2.58.
Peut-être que cela diminuera le nombre de bug liés à ces fonctions.
Aurais-tu un pointeur vers la nouvelle rédaction ?
"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le message
de news: slrnf7crvd.78s.Marc.Boyer@localhost.localdomain...
pour ceux qui étaient déjà là à l'automne 2004 (ça fait un bail),
j'ai le plaisir d'annoncer que la ré-écriture des pages de man
linux str[n]cpy/str[n]cat que nous avions proposé sera inclue
dans la version 2.58.
Peut-être que cela diminuera le nombre de bug liés à ces fonctions.
Aurais-tu un pointeur vers la nouvelle rédaction ?
"Marc Boyer" a écrit dans le message
de news:pour ceux qui étaient déjà là à l'automne 2004 (ça fait un bail),
j'ai le plaisir d'annoncer que la ré-écriture des pages de man
linux str[n]cpy/str[n]cat que nous avions proposé sera inclue
dans la version 2.58.
Peut-être que cela diminuera le nombre de bug liés à ces fonctions.
Aurais-tu un pointeur vers la nouvelle rédaction ?