Ah bon ? char *chaine = "Chaîne qui pourrait avoir plus de 255 lettres.";
Merci beaucoup pour votre analyse.
Jean Pierre Daviau
"Antoine Leca" a écrit dans le message de news: 479dc559$0$12475$
Voir aussi les commentaires de Marc dans news:fnfmpa$rvo$,, je n'ai pas souligné tous les problèmes qu'il a soulevés à juste titre. Mais j'en vois plusieurs autres... http://news.free.fr/
Liens inutilisables pour moi. Auriez-vous des liens complets? Je ne connais pas ces groupes.
"Antoine Leca" <root@localhost.invalid> a écrit dans le message
de news: 479dc559$0$12475$426a74cc@news.free.fr...
Voir aussi les commentaires de Marc dans
news:fnfmpa$rvo$1@biggoron.nerim.net,, je n'ai pas souligné
tous les
problèmes qu'il a soulevés à juste titre. Mais j'en vois
plusieurs autres...
http://news.free.fr/
"Antoine Leca" a écrit dans le message de news: 479dc559$0$12475$
Voir aussi les commentaires de Marc dans news:fnfmpa$rvo$,, je n'ai pas souligné tous les problèmes qu'il a soulevés à juste titre. Mais j'en vois plusieurs autres... http://news.free.fr/
Liens inutilisables pour moi. Auriez-vous des liens complets? Je ne connais pas ces groupes.
espie
In article <479e62a7$0$3289$, Mickaël Wolff wrote:
Bonjour,
Non, meme pas.
Tout à fait.
« La fonction strncpy() est identique, sauf que seuls les n premiers octets de src sont copiés. Ainsi, s'il n'y a pas de caractère nul dans les n premiers octets de src, la chaîne résultante ne disposera de caractère nul final. »
strncpy possede l'enorme gros defaut de *remplir* completement son buffer de zeros, quoi qu'il arrive.
Ce qui est un avantage.
En quoi est-ce un avantage ? Ca la rend moins efficace, et incite les gens a ne pas s'en servir, parce que c'est moins efficace.
Et l'autre enorme gros defaut de ne pas mettre de zero final quand le buffer deborde.
Il ne peut pas déborder. Et combien même tu déborde, il y aurait un problème. Au fait, lorsque strcpy déborde, les données écrites en trop sont susceptible d'écraser le pointeur de retour (pour retrouver le point d'appel de la fonction) et la valeur de retour de la fonction, si ce n'est plus. Donc considérer qu'on peut tolérer un buffer overflow tant qu'il termine par un ' ', c'est cavalier.
Tu fais expres de ne pas comprendre ce que je veux dire, ou quoi ?
Une fonction soit-disant de manipulation de chaine de caracteres qui peut produire des chaines non terminees convenablement, au sens du C, c'est quand meme un leger probleme, non ?
strncpy a une utilisation bien precise, qui est de convertir des chaines du C en un format d'un autre age, tel que celui utilise par l'utmp ou par les entetes d'archive ar.
Euh... non, strncpy est une fonction relativement récente, qui vise à copier une chaine dans une zone mémoire réservée, avec une limite de sécurité. Bien sûr cette limite peut être détournée pour obtenir l'usage que tu recherche.
Non, la fonction recente visant a recopier une chaine dans une zone memoire reservee, c'est strlcpy.
strncpy a quand meme 20 ans d'age, au moins (ANSI C89, BSD 4.3). Cote fonction recente, tu repasseras...
strncpy n'a rien pour elle, en dehors des conditions tres particulieres d'usage dont je parlais.
Essaye de mettre de l'eau dans ton vin, ça ne mange pas de pain, et on te passera plus volontier des erreurs grossières de comparaisons incohérentes ou d'affectations hasardeuses.
Laisse-moi doucement rigoler.
Je n'ai aucune raison de mettre de l'eau dans mon vin pour des trucs aussi basiques. strncpy est nocive. Dans l'enorme majorite des cas ou je l'ai vue utilisee, le code resultant etait peu lisible, voire completement buggue. C'est une fonction qui n'a presque rien pour elle.
In article <479e62a7$0$3289$426a74cc@news.free.fr>,
Mickaël Wolff <mickael.wolff@laposte.net> wrote:
Bonjour,
Non, meme pas.
Tout à fait.
« La fonction strncpy() est identique, sauf que seuls les n
premiers octets de src sont copiés. Ainsi, s'il n'y a pas
de caractère nul dans les n premiers octets de src, la
chaîne résultante ne disposera de caractère nul final. »
strncpy possede l'enorme gros defaut de *remplir* completement son buffer
de zeros, quoi qu'il arrive.
Ce qui est un avantage.
En quoi est-ce un avantage ? Ca la rend moins efficace, et incite les gens
a ne pas s'en servir, parce que c'est moins efficace.
Et l'autre enorme gros defaut de ne pas mettre
de zero final quand le buffer deborde.
Il ne peut pas déborder. Et combien même tu déborde, il y aurait un
problème. Au fait, lorsque strcpy déborde, les données écrites en trop
sont susceptible d'écraser le pointeur de retour (pour retrouver le
point d'appel de la fonction) et la valeur de retour de la fonction, si
ce n'est plus. Donc considérer qu'on peut tolérer un buffer overflow
tant qu'il termine par un ' ', c'est cavalier.
Tu fais expres de ne pas comprendre ce que je veux dire, ou quoi ?
Une fonction soit-disant de manipulation de chaine de caracteres qui
peut produire des chaines non terminees convenablement, au sens du C,
c'est quand meme un leger probleme, non ?
strncpy a une utilisation bien precise, qui est de convertir des chaines
du C en un format d'un autre age, tel que celui utilise par l'utmp ou par
les entetes d'archive ar.
Euh... non, strncpy est une fonction relativement récente, qui vise à
copier une chaine dans une zone mémoire réservée, avec une limite de
sécurité. Bien sûr cette limite peut être détournée pour obtenir l'usage
que tu recherche.
Non, la fonction recente visant a recopier une chaine dans une zone memoire
reservee, c'est strlcpy.
strncpy a quand meme 20 ans d'age, au moins (ANSI C89, BSD 4.3).
Cote fonction recente, tu repasseras...
strncpy n'a rien pour elle, en dehors des conditions tres particulieres
d'usage dont je parlais.
Essaye de mettre de l'eau dans ton vin, ça ne mange pas de pain, et on
te passera plus volontier des erreurs grossières de comparaisons
incohérentes ou d'affectations hasardeuses.
Laisse-moi doucement rigoler.
Je n'ai aucune raison de mettre de l'eau dans mon vin pour des trucs aussi
basiques. strncpy est nocive. Dans l'enorme majorite des cas ou je l'ai
vue utilisee, le code resultant etait peu lisible, voire completement
buggue. C'est une fonction qui n'a presque rien pour elle.
In article <479e62a7$0$3289$, Mickaël Wolff wrote:
Bonjour,
Non, meme pas.
Tout à fait.
« La fonction strncpy() est identique, sauf que seuls les n premiers octets de src sont copiés. Ainsi, s'il n'y a pas de caractère nul dans les n premiers octets de src, la chaîne résultante ne disposera de caractère nul final. »
strncpy possede l'enorme gros defaut de *remplir* completement son buffer de zeros, quoi qu'il arrive.
Ce qui est un avantage.
En quoi est-ce un avantage ? Ca la rend moins efficace, et incite les gens a ne pas s'en servir, parce que c'est moins efficace.
Et l'autre enorme gros defaut de ne pas mettre de zero final quand le buffer deborde.
Il ne peut pas déborder. Et combien même tu déborde, il y aurait un problème. Au fait, lorsque strcpy déborde, les données écrites en trop sont susceptible d'écraser le pointeur de retour (pour retrouver le point d'appel de la fonction) et la valeur de retour de la fonction, si ce n'est plus. Donc considérer qu'on peut tolérer un buffer overflow tant qu'il termine par un ' ', c'est cavalier.
Tu fais expres de ne pas comprendre ce que je veux dire, ou quoi ?
Une fonction soit-disant de manipulation de chaine de caracteres qui peut produire des chaines non terminees convenablement, au sens du C, c'est quand meme un leger probleme, non ?
strncpy a une utilisation bien precise, qui est de convertir des chaines du C en un format d'un autre age, tel que celui utilise par l'utmp ou par les entetes d'archive ar.
Euh... non, strncpy est une fonction relativement récente, qui vise à copier une chaine dans une zone mémoire réservée, avec une limite de sécurité. Bien sûr cette limite peut être détournée pour obtenir l'usage que tu recherche.
Non, la fonction recente visant a recopier une chaine dans une zone memoire reservee, c'est strlcpy.
strncpy a quand meme 20 ans d'age, au moins (ANSI C89, BSD 4.3). Cote fonction recente, tu repasseras...
strncpy n'a rien pour elle, en dehors des conditions tres particulieres d'usage dont je parlais.
Essaye de mettre de l'eau dans ton vin, ça ne mange pas de pain, et on te passera plus volontier des erreurs grossières de comparaisons incohérentes ou d'affectations hasardeuses.
Laisse-moi doucement rigoler.
Je n'ai aucune raison de mettre de l'eau dans mon vin pour des trucs aussi basiques. strncpy est nocive. Dans l'enorme majorite des cas ou je l'ai vue utilisee, le code resultant etait peu lisible, voire completement buggue. C'est une fonction qui n'a presque rien pour elle.
Jean Pierre Daviau
Non, la fonction recente visant a recopier une chaine dans une zone memoire reservee, c'est strlcpy.
Oui, mais ma fonction peut copier une sous-chaîne située n'importe où dans une chaîne ...
Non, la fonction recente visant a recopier une chaine dans une
zone memoire
reservee, c'est strlcpy.
Oui, mais ma fonction peut copier une sous-chaîne située
n'importe où dans une chaîne ...
Non, la fonction recente visant a recopier une chaine dans une zone memoire reservee, c'est strlcpy.
Oui, mais ma fonction peut copier une sous-chaîne située n'importe où dans une chaîne ...
Antoine Leca
En news:i5unj.1793$, Jean Pierre Daviau va escriure:
"Antoine Leca" a écrit dans le message de news: 479dc559$0$12475$
Voir aussi les commentaires de Marc dans news:fnfmpa$rvo$,, je n'ai pas souligné tous les problèmes qu'il a soulevés à juste titre. Mais j'en vois plusieurs autres... http://news.free.fr/
Si vous continuez, vous allez même vous faire mal voir chez ProXad...
Auriez-vous des liens complets?
Copier groups.google.com/groups?selm= suivi de l'indicatif du message (en l'occurence 479 etc. @news.free.fr ou fnf etc. @biggoron.nerim.net, c'est-à-dire sans le news:) et cela devrait marcher (si vous êtes connecté à Internet, évidemment). Pour le message de Marc, cela donne groups.google.com/groups?selm=fnfmpa$rvo$
La formule avec news: devant est un raccourci (un URL, Uniform Resource Locator) qui permet aux lecteurs de niouzes et autres outils intégrés de communications d'aller chercher directement le Message-Id indiqué (après les deux points) dans leur base interne ou bien dans la base du serveur auquel le client est abonné: mais certains logiciels de lecture des niouzes n'ont pas ces fonctions implémentées; et par ailleurs, il est toujours possible que le message (en l'occurence celui de Marc) n'ai pas encore été répliqué sur le serveur auxquel vous êtes abonné (par exemple, en ce momment j'utilise mon serveur de secours, Free donc, car mon serveur habituel est en panne...) auquel cas, une solution alternative c'est Google.
Je ne connais pas ces groupes.
Le groupe est celui que vous lisez en ce moment, fr.comp.lang.fr...
En news:i5unj.1793$pn.5056@wagner.videotron.net,
Jean Pierre Daviau <Once@WasEno.ugh> va escriure:
"Antoine Leca" <root@localhost.invalid> a écrit dans le message
de news: 479dc559$0$12475$426a74cc@news.free.fr...
Voir aussi les commentaires de Marc dans
news:fnfmpa$rvo$1@biggoron.nerim.net,, je n'ai pas souligné
tous les
problèmes qu'il a soulevés à juste titre. Mais j'en vois
plusieurs autres...
http://news.free.fr/
Si vous continuez, vous allez même vous faire mal voir chez ProXad...
Auriez-vous des liens complets?
Copier groups.google.com/groups?selm= suivi de l'indicatif du message (en
l'occurence 479 etc. @news.free.fr ou fnf etc. @biggoron.nerim.net,
c'est-à-dire sans le news:) et cela devrait marcher (si vous êtes connecté à
Internet, évidemment). Pour le message de Marc, cela donne
groups.google.com/groups?selm=fnfmpa$rvo$1@biggoron.nerim.net
La formule avec news: devant est un raccourci (un URL, Uniform Resource
Locator) qui permet aux lecteurs de niouzes et autres outils intégrés de
communications d'aller chercher directement le Message-Id indiqué (après les
deux points) dans leur base interne ou bien dans la base du serveur auquel
le client est abonné: mais certains logiciels de lecture des niouzes n'ont
pas ces fonctions implémentées; et par ailleurs, il est toujours possible
que le message (en l'occurence celui de Marc) n'ai pas encore été répliqué
sur le serveur auxquel vous êtes abonné (par exemple, en ce momment
j'utilise mon serveur de secours, Free donc, car mon serveur habituel est en
panne...) auquel cas, une solution alternative c'est Google.
Je ne connais pas ces groupes.
Le groupe est celui que vous lisez en ce moment, fr.comp.lang.fr...
En news:i5unj.1793$, Jean Pierre Daviau va escriure:
"Antoine Leca" a écrit dans le message de news: 479dc559$0$12475$
Voir aussi les commentaires de Marc dans news:fnfmpa$rvo$,, je n'ai pas souligné tous les problèmes qu'il a soulevés à juste titre. Mais j'en vois plusieurs autres... http://news.free.fr/
Si vous continuez, vous allez même vous faire mal voir chez ProXad...
Auriez-vous des liens complets?
Copier groups.google.com/groups?selm= suivi de l'indicatif du message (en l'occurence 479 etc. @news.free.fr ou fnf etc. @biggoron.nerim.net, c'est-à-dire sans le news:) et cela devrait marcher (si vous êtes connecté à Internet, évidemment). Pour le message de Marc, cela donne groups.google.com/groups?selm=fnfmpa$rvo$
La formule avec news: devant est un raccourci (un URL, Uniform Resource Locator) qui permet aux lecteurs de niouzes et autres outils intégrés de communications d'aller chercher directement le Message-Id indiqué (après les deux points) dans leur base interne ou bien dans la base du serveur auquel le client est abonné: mais certains logiciels de lecture des niouzes n'ont pas ces fonctions implémentées; et par ailleurs, il est toujours possible que le message (en l'occurence celui de Marc) n'ai pas encore été répliqué sur le serveur auxquel vous êtes abonné (par exemple, en ce momment j'utilise mon serveur de secours, Free donc, car mon serveur habituel est en panne...) auquel cas, une solution alternative c'est Google.
Je ne connais pas ces groupes.
Le groupe est celui que vous lisez en ce moment, fr.comp.lang.fr...
strncpy a quand meme 20 ans d'age, au moins (ANSI C89, BSD 4.3).
et System III, et aussi Version 7; soit presque 30 ans, en fait.
Merci, je me doutais bien d'un gag comme ca, mais comme j'avais pas
de ref plus ancienne sous la main, je me suis arrete avant.
espie
In article <ljInj.32247$, Jean Pierre Daviau wrote:
Non, la fonction recente visant a recopier une chaine dans une zone memoire reservee, c'est strlcpy.
Oui, mais ma fonction peut copier une sous-chaîne située n'importe où dans une chaîne ...
Ta fonction ne fait rien. Le code initial etait buggue jusqu'a l'os. Le code corrige avait l'air a peine meilleur. Si tu commencais par donner les *specs* de ta fonction plutot que du code qui ne marche pas, on arriverait sans doute mieux a communiquer... ;-)
In article <ljInj.32247$1n5.11936@weber.videotron.net>,
Jean Pierre Daviau <Once@WasEno.ugh> wrote:
Non, la fonction recente visant a recopier une chaine dans une
zone memoire
reservee, c'est strlcpy.
Oui, mais ma fonction peut copier une sous-chaîne située
n'importe où dans une chaîne ...
Ta fonction ne fait rien. Le code initial etait buggue jusqu'a l'os.
Le code corrige avait l'air a peine meilleur. Si tu commencais par
donner les *specs* de ta fonction plutot que du code qui ne marche pas,
on arriverait sans doute mieux a communiquer... ;-)
In article <ljInj.32247$, Jean Pierre Daviau wrote:
Non, la fonction recente visant a recopier une chaine dans une zone memoire reservee, c'est strlcpy.
Oui, mais ma fonction peut copier une sous-chaîne située n'importe où dans une chaîne ...
Ta fonction ne fait rien. Le code initial etait buggue jusqu'a l'os. Le code corrige avait l'air a peine meilleur. Si tu commencais par donner les *specs* de ta fonction plutot que du code qui ne marche pas, on arriverait sans doute mieux a communiquer... ;-)
Antoine Leca
En news:fno8l5$18dm$, Marc Espie va escriure:
strncpy [...] [...] Version 7; soit presque 30 ans, en fait.
Merci, je me doutais bien d'un gag comme ca, mais comme j'avais pas
de ref plus ancienne sous la main, je me suis arrete avant.
http://minnie.tuhs.org/UnixTree/V7/usr/src/libc/gen/strncpy.c.html (ou n'importe quel miroir de TUHS, évidemment; cf. http://minnie.tuhs.org/TUHS/archive_sites.html)
Antoine
En news:fno8l5$18dm$1@biggoron.nerim.net,
Marc Espie <espie@lain.home> va escriure:
strncpy [...]
[...] Version 7; soit presque 30 ans, en fait.
Merci, je me doutais bien d'un gag comme ca, mais comme j'avais pas
de ref plus ancienne sous la main, je me suis arrete avant.
http://minnie.tuhs.org/UnixTree/V7/usr/src/libc/gen/strncpy.c.html
(ou n'importe quel miroir de TUHS, évidemment; cf.
http://minnie.tuhs.org/TUHS/archive_sites.html)
strncpy [...] [...] Version 7; soit presque 30 ans, en fait.
Merci, je me doutais bien d'un gag comme ca, mais comme j'avais pas
de ref plus ancienne sous la main, je me suis arrete avant.
http://minnie.tuhs.org/UnixTree/V7/usr/src/libc/gen/strncpy.c.html (ou n'importe quel miroir de TUHS, évidemment; cf. http://minnie.tuhs.org/TUHS/archive_sites.html)
Antoine
Antoine Leca
En news:ljInj.32247$, Jean Pierre Daviau va escriure:
Oui, mais ma fonction peut copier une sous-chaîne située n'importe où dans une chaîne ...
Ce n'est pas une caractéristique probante. En C, une sous-chaîne qui commence au n-ième caractère d'une chaîne s, cela s'écrit s+n toujours, partout, et sans se compliquer la vie à passer un argument complémentaire.
*À moins* que l'on veuille implémenter un contrôle de cohérence (vérifier que n est inférieur à strlen(s)), chose qu'en C il est de tradition d'écrire à part : C est né dans les années 1970, époque où les contraintes de performances étaient différentes d'aujourd'hui. Donc en C on préfère ne faire qu'une seule fois un contrôle de cohérence, si c'est pas bon on sort et sinon on continue. Aujourd'hui ce n'est pas bien vu, on préfère vérifier la même chose (un pointeur n'est pas NULL, la chaîne ne déborde pas, etc.) 666 fois, quite à ce que les performances ressenties soient les mêmes que celles avec le matériel datant de 10 ans, plutôt que de laisser une seule possibilité d'avoir un bogue de ce genre qui se glisse dans le code. Différence de points de vue.
Antoine
En news:ljInj.32247$1n5.11936@weber.videotron.net, Jean Pierre Daviau va
escriure:
Oui, mais ma fonction peut copier une sous-chaîne située
n'importe où dans une chaîne ...
Ce n'est pas une caractéristique probante. En C, une sous-chaîne qui
commence au n-ième caractère d'une chaîne s, cela s'écrit
s+n
toujours, partout, et sans se compliquer la vie à passer un argument
complémentaire.
*À moins* que l'on veuille implémenter un contrôle de cohérence (vérifier
que n est inférieur à strlen(s)), chose qu'en C il est de tradition d'écrire
à part : C est né dans les années 1970, époque où les contraintes de
performances étaient différentes d'aujourd'hui. Donc en C on préfère ne
faire qu'une seule fois un contrôle de cohérence, si c'est pas bon on sort
et sinon on continue. Aujourd'hui ce n'est pas bien vu, on préfère vérifier
la même chose (un pointeur n'est pas NULL, la chaîne ne déborde pas, etc.)
666 fois, quite à ce que les performances ressenties soient les mêmes que
celles avec le matériel datant de 10 ans, plutôt que de laisser une seule
possibilité d'avoir un bogue de ce genre qui se glisse dans le code.
Différence de points de vue.
En news:ljInj.32247$, Jean Pierre Daviau va escriure:
Oui, mais ma fonction peut copier une sous-chaîne située n'importe où dans une chaîne ...
Ce n'est pas une caractéristique probante. En C, une sous-chaîne qui commence au n-ième caractère d'une chaîne s, cela s'écrit s+n toujours, partout, et sans se compliquer la vie à passer un argument complémentaire.
*À moins* que l'on veuille implémenter un contrôle de cohérence (vérifier que n est inférieur à strlen(s)), chose qu'en C il est de tradition d'écrire à part : C est né dans les années 1970, époque où les contraintes de performances étaient différentes d'aujourd'hui. Donc en C on préfère ne faire qu'une seule fois un contrôle de cohérence, si c'est pas bon on sort et sinon on continue. Aujourd'hui ce n'est pas bien vu, on préfère vérifier la même chose (un pointeur n'est pas NULL, la chaîne ne déborde pas, etc.) 666 fois, quite à ce que les performances ressenties soient les mêmes que celles avec le matériel datant de 10 ans, plutôt que de laisser une seule possibilité d'avoir un bogue de ce genre qui se glisse dans le code. Différence de points de vue.
