Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement Langage C Mises a jours des pages man linux strcpy/strcat

Mises a jours des pages man linux strcpy/strcat

14 réponses
Avatar
Marc Boyer
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.

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Signaler un problème avec ce contenu

10 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
espie
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...

Avatar
Marc Boyer
Le 18-06-2007, Marc Espie a écrit :
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.

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)


Avatar
espie
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. ;-)

Avatar
Marc Boyer
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 ?
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)


Avatar
espie
In article ,
Marc Boyer wrote:
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.


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.

Quant a rendre l'alternative standard... la derniere fois que j'ai
regarde les drafts C, le comite avait pete les plombs: leurs variantes
de fonctions `safe' etaient inutilisables parce que bien trop lourdes
(genre trois arguments de plus par fonction, et des noms pas intuitifs,
et une utilisation lourdingue au possible).

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...



Avatar
rixed
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."

Avatar
Charlie Gordon
"Marc Boyer" a écrit dans le message
de news:
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.


Aurais-tu un pointeur vers la nouvelle rédaction ?

Chqrlie (pour l'éradication de strncpy/strncat)

Avatar
espie
In article ,
wrote:
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."


Ca confirme que Drepper est un con.

Les memes programmeurs qui ignoreront les troncations avec strlcpy sont
ceux qui se planteront sur les tailles de tampon avec strcpy, ou qui
ne feront pas de verif de taille du buffer du tout.

Sans compter que strlcpy et strlcat ont ete concues pour que les verifications
de troncations soient les plus triviales possibles...


Avatar
Marc Boyer
Le 18-06-2007, Marc Espie a écrit :
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 suis d'accord. Tu oublie aussi de mentionner la fabuleuse
incohérence entre les deux, strncat produisant toujours une
chaine null-terminated, et pas strncpy.

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.


C'est en effet ce que j'ai entendu dire. D'ailleurs, à l'époque
de la discussion, Charlie Gordon avait fait le pari, dans tous code
utilisant l'une ou l'autre, de trouver des bugs. Et je crois qu'il
l'avait gagné.

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'ailleurs, le vrai programmeur ne lit pas les pages de man, il
lit les pages infos ;-)
Mais comme professionnellement, je suis plus confronté à des
débutants qu'à de vrais programmeurs, j'ai étudié les pages de man.

En plus, les pages infos étaient fausses (cf post de Charlie Gordon
le 8 oct 2004).

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.


De toute façon, l'issue, c'est l'abandon du C...

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.


Oui.

Voilà,
Marc
PS: T'es à l'Epita maintenant ?


Chut ! incognito... je poste ici en tant que developpeur OpenBSD.


Et ça paye ?

j'essaie tant bien que mal d'inculquer des bases de developpement logiciel
propres a quelques etudiants...


Je vois. Je fais la même chose dans une école concurente.

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)


Avatar
Marc Boyer
Le 18-06-2007, Charlie Gordon a écrit :
"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 ?


Non, juste quelques échanges de mail. Je peux poster la version
si tu veux.

Marc
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)


1 2