Il faut utiliser la fonction strcpy(), et non l'opérateur d'affectation =. Il faut s'assurer que l'on dispose d'espace suffisant dans la chaîne cible avant d'utiliser strcpy(), qui ne fait aucun contrôle de débordement.
Pour une copie plus sécurisée, on préférera la fonction strncpy().
while(motTmp[k++] != ' ') printf("%c", *motTmp);
printf("%s", motTmp);
-- Richard
j4e8a16n a écrit :
Bonjour à tous,
int k = 0;
char mot [60];
char motTmp [60];
mot [0] = 'H';
mot [1] = 'e';
mot [2] = 'l';
mot [3] = 'l';
mot [4] = 'o';
mot [5] = ' ';
Il faut utiliser la fonction strcpy(), et non l'opérateur d'affectation
=. Il faut s'assurer que l'on dispose d'espace suffisant dans la chaîne
cible avant d'utiliser strcpy(), qui ne fait aucun contrôle de débordement.
Pour une copie plus sécurisée, on préférera la fonction strncpy().
Il faut utiliser la fonction strcpy(), et non l'opérateur d'affectation =. Il faut s'assurer que l'on dispose d'espace suffisant dans la chaîne cible avant d'utiliser strcpy(), qui ne fait aucun contrôle de débordement.
Pour une copie plus sécurisée, on préférera la fonction strncpy().
while(motTmp[k++] != ' ') printf("%c", *motTmp);
printf("%s", motTmp);
-- Richard
Xavier Roche
Richard Delorme a écrit :
Plus simplement : char mot[60] = "Hello";
Il vaut mieux utiliser strcpy() ou strlcpy() [en standardisation il me semble] ; l'affectation effectue également un memset() silencieux sur les 53 caractères terminaux.
Pour une copie plus sécurisée, on préférera la fonction strncpy().
C'est un conseil idiot, à mon humble avis. Au lieu de provoquer un débordement sur strcpy(), on crée une chaine non terminée, qui vous explosera à la figure de manière aléatoire, bien plus tard. Autant avoir un crash direct, débuggable. Bref, strncpy() est une fonction horrible que l'on ne devrait absolument jamais utiliser (c'est vraiment la fonction la plus débile de la libc amha)
Mais strlcpy() est une solution beaucoup plus propre - à réimplémenter au besoin, mais c'est le type de fonction utile.
Richard Delorme a écrit :
Plus simplement :
char mot[60] = "Hello";
Il vaut mieux utiliser strcpy() ou strlcpy() [en standardisation il me
semble] ; l'affectation effectue également un memset() silencieux sur
les 53 caractères terminaux.
Pour une copie plus sécurisée, on préférera la fonction strncpy().
C'est un conseil idiot, à mon humble avis. Au lieu de provoquer un
débordement sur strcpy(), on crée une chaine non terminée, qui vous
explosera à la figure de manière aléatoire, bien plus tard. Autant avoir
un crash direct, débuggable. Bref, strncpy() est une fonction horrible
que l'on ne devrait absolument jamais utiliser (c'est vraiment la
fonction la plus débile de la libc amha)
Mais strlcpy() est une solution beaucoup plus propre - à réimplémenter
au besoin, mais c'est le type de fonction utile.
Il vaut mieux utiliser strcpy() ou strlcpy() [en standardisation il me semble] ; l'affectation effectue également un memset() silencieux sur les 53 caractères terminaux.
Pour une copie plus sécurisée, on préférera la fonction strncpy().
C'est un conseil idiot, à mon humble avis. Au lieu de provoquer un débordement sur strcpy(), on crée une chaine non terminée, qui vous explosera à la figure de manière aléatoire, bien plus tard. Autant avoir un crash direct, débuggable. Bref, strncpy() est une fonction horrible que l'on ne devrait absolument jamais utiliser (c'est vraiment la fonction la plus débile de la libc amha)
Mais strlcpy() est une solution beaucoup plus propre - à réimplémenter au besoin, mais c'est le type de fonction utile.
Eric Levenez
Le 17/05/09 20:55, dans <gupmjn$4e6$, « Xavier Roche » a écrit :
Richard Delorme a écrit :
Pour une copie plus sécurisée, on préférera la fonction strncpy().
C'est un conseil idiot, [snip]
Mais strlcpy() est une solution beaucoup plus propre - à réimplémenter au besoin, mais c'est le type de fonction utile.
Peut-être qu'un jour strlcpy sera dans la norme, mais pour l'instant il n'en est rien. Déjà que le C d'il y a 10 ans (C99) n'est pas beaucoup utilisé, alors une fonction qui sera peut-être un jour dans une future norme, c'est une rigolade de la conseiller en disant que les solutions standard sont "idiotes".
-- Éric Lévénez FAQ de fclc : <http://www.levenez.com/lang/c/faq/>
Le 17/05/09 20:55, dans <gupmjn$4e6$1@news.httrack.net>, « Xavier Roche »
<xroche@free.fr.NOSPAM.invalid> a écrit :
Richard Delorme a écrit :
Pour une copie plus sécurisée, on préférera la fonction strncpy().
C'est un conseil idiot, [snip]
Mais strlcpy() est une solution beaucoup plus propre - à réimplémenter
au besoin, mais c'est le type de fonction utile.
Peut-être qu'un jour strlcpy sera dans la norme, mais pour l'instant il n'en
est rien. Déjà que le C d'il y a 10 ans (C99) n'est pas beaucoup utilisé,
alors une fonction qui sera peut-être un jour dans une future norme, c'est
une rigolade de la conseiller en disant que les solutions standard sont
"idiotes".
--
Éric Lévénez
FAQ de fclc : <http://www.levenez.com/lang/c/faq/>
Le 17/05/09 20:55, dans <gupmjn$4e6$, « Xavier Roche » a écrit :
Richard Delorme a écrit :
Pour une copie plus sécurisée, on préférera la fonction strncpy().
C'est un conseil idiot, [snip]
Mais strlcpy() est une solution beaucoup plus propre - à réimplémenter au besoin, mais c'est le type de fonction utile.
Peut-être qu'un jour strlcpy sera dans la norme, mais pour l'instant il n'en est rien. Déjà que le C d'il y a 10 ans (C99) n'est pas beaucoup utilisé, alors une fonction qui sera peut-être un jour dans une future norme, c'est une rigolade de la conseiller en disant que les solutions standard sont "idiotes".
-- Éric Lévénez FAQ de fclc : <http://www.levenez.com/lang/c/faq/>
Xavier Roche
Eric Levenez a écrit :
Peut-être qu'un jour strlcpy sera dans la norme, mais pour l'instant il n'en est rien.
C'est pour cela que je conseille de placer une implémentation dans un .h, genre fonction statique.
une rigolade de la conseiller en disant que les solutions standard sont "idiotes".
Utiliser strncpy() est aussi (/encore plus) idiot qu'utiliser strcpy(), oui.
Eric Levenez a écrit :
Peut-être qu'un jour strlcpy sera dans la norme, mais pour l'instant il n'en
est rien.
C'est pour cela que je conseille de placer une implémentation dans un
.h, genre fonction statique.
une rigolade de la conseiller en disant que les solutions standard sont
"idiotes".
Utiliser strncpy() est aussi (/encore plus) idiot qu'utiliser strcpy(), oui.
Peut-être qu'un jour strlcpy sera dans la norme, mais pour l'instant il n'en est rien.
C'est pour cela que je conseille de placer une implémentation dans un .h, genre fonction statique.
une rigolade de la conseiller en disant que les solutions standard sont "idiotes".
Utiliser strncpy() est aussi (/encore plus) idiot qu'utiliser strcpy(), oui.
espie
In article <C636321E.E8367%, Eric Levenez wrote:
Peut-être qu'un jour strlcpy sera dans la norme, mais pour l'instant il n'en est rien. Déjà que le C d'il y a 10 ans (C99) n'est pas beaucoup utilisé, alors une fonction qui sera peut-être un jour dans une future norme, c'est une rigolade de la conseiller en disant que les solutions standard sont "idiotes".
Ca ne change rien au fait qu'strncpy/strncat sont deux conneries qui n'ont rien de tres securise.
Je fais partie des gens qui militent pour l'utilisation de strlcpy, juste parce que j'en ai marre de corriger des buffer-overflow dans du code tiers qui se croit malin et se plante dans strcpy/strncpy...
In article <C636321E.E8367%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> wrote:
Peut-être qu'un jour strlcpy sera dans la norme, mais pour l'instant il n'en
est rien. Déjà que le C d'il y a 10 ans (C99) n'est pas beaucoup utilisé,
alors une fonction qui sera peut-être un jour dans une future norme, c'est
une rigolade de la conseiller en disant que les solutions standard sont
"idiotes".
Ca ne change rien au fait qu'strncpy/strncat sont deux conneries qui n'ont
rien de tres securise.
Je fais partie des gens qui militent pour l'utilisation de strlcpy, juste
parce que j'en ai marre de corriger des buffer-overflow dans du code tiers
qui se croit malin et se plante dans strcpy/strncpy...
Peut-être qu'un jour strlcpy sera dans la norme, mais pour l'instant il n'en est rien. Déjà que le C d'il y a 10 ans (C99) n'est pas beaucoup utilisé, alors une fonction qui sera peut-être un jour dans une future norme, c'est une rigolade de la conseiller en disant que les solutions standard sont "idiotes".
Ca ne change rien au fait qu'strncpy/strncat sont deux conneries qui n'ont rien de tres securise.
Je fais partie des gens qui militent pour l'utilisation de strlcpy, juste parce que j'en ai marre de corriger des buffer-overflow dans du code tiers qui se croit malin et se plante dans strcpy/strncpy...
Sylvain SF
Marc Espie a écrit :
Peut-être qu'un jour strlcpy sera dans la norme
en tout cas, il n'est pas dans Studio qui préfère strcpy_s ...
Je fais partie des gens qui militent pour l'utilisation de strlcpy [...]
et dire que str*l*cpy est mieux que str*n*cpy est suffisant? vraiment?
affirmer "à réimplémenter" me parait insuffisant pour qui a) n'a pas conscience des dangers de str[n]cpy, b) ne sait pas ce qu'un L change par rapport à un N (car les détails d'implémentations donnés s'arrêtent là, dommage un wiki appuierait sûrement mieux l'affirmation).
Sylvain.
Marc Espie a écrit :
Peut-être qu'un jour strlcpy sera dans la norme
en tout cas, il n'est pas dans Studio qui préfère strcpy_s ...
Je fais partie des gens qui militent pour l'utilisation de strlcpy [...]
et dire que str*l*cpy est mieux que str*n*cpy est suffisant? vraiment?
affirmer "à réimplémenter" me parait insuffisant pour qui a) n'a pas
conscience des dangers de str[n]cpy, b) ne sait pas ce qu'un L change
par rapport à un N (car les détails d'implémentations donnés s'arrêtent
là, dommage un wiki appuierait sûrement mieux l'affirmation).
en tout cas, il n'est pas dans Studio qui préfère strcpy_s ...
Je fais partie des gens qui militent pour l'utilisation de strlcpy [...]
et dire que str*l*cpy est mieux que str*n*cpy est suffisant? vraiment?
affirmer "à réimplémenter" me parait insuffisant pour qui a) n'a pas conscience des dangers de str[n]cpy, b) ne sait pas ce qu'un L change par rapport à un N (car les détails d'implémentations donnés s'arrêtent là, dommage un wiki appuierait sûrement mieux l'affirmation).
Sylvain.
espie
In article <4a10a921$0$17084$, Sylvain SF wrote:
Marc Espie a écrit :
Peut-être qu'un jour strlcpy sera dans la norme
Non, non. Apprend a citer correctement deja, c'est pas moi qui ait ecrit ca.
en tout cas, il n'est pas dans Studio qui préfère strcpy_s ...
Je fais partie des gens qui militent pour l'utilisation de strlcpy [...]
et dire que str*l*cpy est mieux que str*n*cpy est suffisant? vraiment?
affirmer "à réimplémenter" me parait insuffisant pour qui a) n'a pas conscience des dangers de str[n]cpy, b) ne sait pas ce qu'un L change par rapport à un N (car les détails d'implémentations donnés s'arrêtent là, dommage un wiki appuierait sûrement mieux l'affirmation).
Tutut! 30 secondes de google t'ameneront sans probleme sur toute la doc que tu veux sur strlcpy/strlcat. Faut quand meme pas faire preuve de trop de mauvaise foi, le papier de Todd Miller qui presente strlcpy et strlcat et leur interet est le 2e lien qui apparait si je cherche strlcpy ! (wikipedia etant le premier).
Si tu veux vraiment un resume rapide, strncpy n'est pas efficace (remplit forcement tout son buffer), et en plus ne suffit pas a fabriquer des chaines bien formees toutes seules (faut rajouter un zero final a la main si on veut etre certain d'en avoir un).
strcpy_s n'est pas super-bien foutue en cas de debordement. En particulier, tu ne sais pas vraiment de combien tu debordes. Et puis, c'est un peu une microsofterie, et absolument personne n'a l'air de vouloir l'adopter pour l'instant...
strlcpy et strlcat ont l'air toutes betes, mais justement, elles sont tres simples d'emploi. Un de leurs interets, c'est qu'elles prennent exactement les memes parametres (dest, source, taille de tampon), et renvoient la meme chose (taille necessaire pour faire l'operation dans sa totalite). La seule chose qui change etant l'operation (copy vs. concatenation). Autant d'endroits en moins pour faire des erreurs...
quand tu en es au 3e programmeur ruse qui se plante dans ses calculs de strcpy, ou qui utilise strncat de facon incorrecte, tu vois strlcpy et strlcat comme vachement bien, finalement.
In article <4a10a921$0$17084$ba4acef3@news.orange.fr>,
Sylvain SF <sylvain@boiteaspam.info> wrote:
Marc Espie a écrit :
Peut-être qu'un jour strlcpy sera dans la norme
Non, non. Apprend a citer correctement deja, c'est pas moi qui ait ecrit ca.
en tout cas, il n'est pas dans Studio qui préfère strcpy_s ...
Je fais partie des gens qui militent pour l'utilisation de strlcpy [...]
et dire que str*l*cpy est mieux que str*n*cpy est suffisant? vraiment?
affirmer "à réimplémenter" me parait insuffisant pour qui a) n'a pas
conscience des dangers de str[n]cpy, b) ne sait pas ce qu'un L change
par rapport à un N (car les détails d'implémentations donnés s'arrêtent
là, dommage un wiki appuierait sûrement mieux l'affirmation).
Tutut! 30 secondes de google t'ameneront sans probleme sur toute la doc
que tu veux sur strlcpy/strlcat. Faut quand meme pas faire preuve de trop
de mauvaise foi, le papier de Todd Miller qui presente strlcpy et strlcat
et leur interet est le 2e lien qui apparait si je cherche strlcpy !
(wikipedia etant le premier).
Si tu veux vraiment un resume rapide, strncpy n'est pas efficace (remplit
forcement tout son buffer), et en plus ne suffit pas a fabriquer des
chaines bien formees toutes seules (faut rajouter un zero final a la main
si on veut etre certain d'en avoir un).
strcpy_s n'est pas super-bien foutue en cas de debordement. En particulier,
tu ne sais pas vraiment de combien tu debordes. Et puis, c'est un peu une
microsofterie, et absolument personne n'a l'air de vouloir l'adopter pour
l'instant...
strlcpy et strlcat ont l'air toutes betes, mais justement, elles sont tres
simples d'emploi. Un de leurs interets, c'est qu'elles prennent exactement
les memes parametres (dest, source, taille de tampon), et renvoient la meme
chose (taille necessaire pour faire l'operation dans sa totalite). La seule
chose qui change etant l'operation (copy vs. concatenation).
Autant d'endroits en moins pour faire des erreurs...
quand tu en es au 3e programmeur ruse qui se plante dans ses calculs de strcpy,
ou qui utilise strncat de facon incorrecte, tu vois strlcpy et strlcat comme
vachement bien, finalement.
Non, non. Apprend a citer correctement deja, c'est pas moi qui ait ecrit ca.
en tout cas, il n'est pas dans Studio qui préfère strcpy_s ...
Je fais partie des gens qui militent pour l'utilisation de strlcpy [...]
et dire que str*l*cpy est mieux que str*n*cpy est suffisant? vraiment?
affirmer "à réimplémenter" me parait insuffisant pour qui a) n'a pas conscience des dangers de str[n]cpy, b) ne sait pas ce qu'un L change par rapport à un N (car les détails d'implémentations donnés s'arrêtent là, dommage un wiki appuierait sûrement mieux l'affirmation).
Tutut! 30 secondes de google t'ameneront sans probleme sur toute la doc que tu veux sur strlcpy/strlcat. Faut quand meme pas faire preuve de trop de mauvaise foi, le papier de Todd Miller qui presente strlcpy et strlcat et leur interet est le 2e lien qui apparait si je cherche strlcpy ! (wikipedia etant le premier).
Si tu veux vraiment un resume rapide, strncpy n'est pas efficace (remplit forcement tout son buffer), et en plus ne suffit pas a fabriquer des chaines bien formees toutes seules (faut rajouter un zero final a la main si on veut etre certain d'en avoir un).
strcpy_s n'est pas super-bien foutue en cas de debordement. En particulier, tu ne sais pas vraiment de combien tu debordes. Et puis, c'est un peu une microsofterie, et absolument personne n'a l'air de vouloir l'adopter pour l'instant...
strlcpy et strlcat ont l'air toutes betes, mais justement, elles sont tres simples d'emploi. Un de leurs interets, c'est qu'elles prennent exactement les memes parametres (dest, source, taille de tampon), et renvoient la meme chose (taille necessaire pour faire l'operation dans sa totalite). La seule chose qui change etant l'operation (copy vs. concatenation). Autant d'endroits en moins pour faire des erreurs...
quand tu en es au 3e programmeur ruse qui se plante dans ses calculs de strcpy, ou qui utilise strncat de facon incorrecte, tu vois strlcpy et strlcat comme vachement bien, finalement.
Gabriel Dos Reis
(Marc Espie) writes:
[...]
| quand tu en es au 3e programmeur ruse qui se plante dans ses calculs de strcpy, | ou qui utilise strncat de facon incorrecte, tu vois strlcpy et strlcat comme | vachement bien, finalement.
Peut-être que ce qu'il faut c'est un vrai type de données « string » au lieu de cette notion floue de pointeur vers un « char » qu'on avance jusqu'à ce qu'on tombe sur zéro ? À la fin, on va empiler des « strXyyy » sans vraiment voir le bout du tunnel de sécurité...
-- Gaby
espie@lain.home (Marc Espie) writes:
[...]
| quand tu en es au 3e programmeur ruse qui se plante dans ses calculs de strcpy,
| ou qui utilise strncat de facon incorrecte, tu vois strlcpy et strlcat comme
| vachement bien, finalement.
Peut-être que ce qu'il faut c'est un vrai type de données « string » au
lieu de cette notion floue de pointeur vers un « char » qu'on avance jusqu'à
ce qu'on tombe sur zéro ? À la fin, on va empiler des « strXyyy » sans
vraiment voir le bout du tunnel de sécurité...
| quand tu en es au 3e programmeur ruse qui se plante dans ses calculs de strcpy, | ou qui utilise strncat de facon incorrecte, tu vois strlcpy et strlcat comme | vachement bien, finalement.
Peut-être que ce qu'il faut c'est un vrai type de données « string » au lieu de cette notion floue de pointeur vers un « char » qu'on avance jusqu'à ce qu'on tombe sur zéro ? À la fin, on va empiler des « strXyyy » sans vraiment voir le bout du tunnel de sécurité...
-- Gaby
Richard Delorme
Marc Espie a écrit :
In article <4a10a921$0$17084$, Sylvain SF wrote:
Marc Espie a écrit :
Peut-être qu'un jour strlcpy sera dans la norme
Non, non. Apprend a citer correctement deja, c'est pas moi qui ait ecrit ca.
en tout cas, il n'est pas dans Studio qui préfère strcpy_s ...
Je fais partie des gens qui militent pour l'utilisation de strlcpy [...]
et dire que str*l*cpy est mieux que str*n*cpy est suffisant? vraiment?
affirmer "à réimplémenter" me parait insuffisant pour qui a) n'a pas conscience des dangers de str[n]cpy, b) ne sait pas ce qu'un L change par rapport à un N (car les détails d'implémentations donnés s'arrêtent là, dommage un wiki appuierait sûrement mieux l'affirmation).
Tutut! 30 secondes de google t'ameneront sans probleme sur toute la doc que tu veux sur strlcpy/strlcat. Faut quand meme pas faire preuve de trop de mauvaise foi, le papier de Todd Miller qui presente strlcpy et strlcat et leur interet est le 2e lien qui apparait si je cherche strlcpy ! (wikipedia etant le premier).
On trouve aussi assez rapidement l'avis de Ulrich Drepper (c'est lui qui interdit l'addition de ces fonctions dans la glibc). Il dit à propos de strlcpy et stlcat :
This is horribly inefficient BSD crap. Using these function only leads to other errors. Correct string handling means that you always know how long your strings are and therefore you can you memcpy (instead of strcpy). Beside, those who are using strcat or variants deserved to be punished.
It hides bugs in programs. If a string is too long for an allocated memory block the copying must not simply silently stop. Instead the program must reallocate or signal an error.
strlcpy et strlcat ont l'air toutes betes, mais justement, elles sont tres simples d'emploi. Un de leurs interets, c'est qu'elles prennent exactement les memes parametres (dest, source, taille de tampon), et renvoient la meme chose (taille necessaire pour faire l'operation dans sa totalite). La seule chose qui change etant l'operation (copy vs. concatenation). Autant d'endroits en moins pour faire des erreurs...
En quoi tronquer une chaîne n'est pas une erreur ?
-- Richard
Marc Espie a écrit :
In article <4a10a921$0$17084$ba4acef3@news.orange.fr>,
Sylvain SF <sylvain@boiteaspam.info> wrote:
Marc Espie a écrit :
Peut-être qu'un jour strlcpy sera dans la norme
Non, non. Apprend a citer correctement deja, c'est pas moi qui ait ecrit ca.
en tout cas, il n'est pas dans Studio qui préfère strcpy_s ...
Je fais partie des gens qui militent pour l'utilisation de strlcpy [...]
et dire que str*l*cpy est mieux que str*n*cpy est suffisant? vraiment?
affirmer "à réimplémenter" me parait insuffisant pour qui a) n'a pas
conscience des dangers de str[n]cpy, b) ne sait pas ce qu'un L change
par rapport à un N (car les détails d'implémentations donnés s'arrêtent
là, dommage un wiki appuierait sûrement mieux l'affirmation).
Tutut! 30 secondes de google t'ameneront sans probleme sur toute la doc
que tu veux sur strlcpy/strlcat. Faut quand meme pas faire preuve de trop
de mauvaise foi, le papier de Todd Miller qui presente strlcpy et strlcat
et leur interet est le 2e lien qui apparait si je cherche strlcpy !
(wikipedia etant le premier).
On trouve aussi assez rapidement l'avis de Ulrich Drepper (c'est lui qui
interdit l'addition de ces fonctions dans la glibc). Il dit à propos
de strlcpy et stlcat :
This is horribly inefficient BSD crap. Using these function only
leads to other errors. Correct string handling means that you always
know how long your strings are and therefore you can you memcpy
(instead of strcpy).
Beside, those who are using strcat or variants deserved to be punished.
It hides bugs in programs. If a string is
too long for an allocated memory block the copying must not simply
silently stop. Instead the program must reallocate or signal an
error.
strlcpy et strlcat ont l'air toutes betes, mais justement, elles sont tres
simples d'emploi. Un de leurs interets, c'est qu'elles prennent exactement
les memes parametres (dest, source, taille de tampon), et renvoient la meme
chose (taille necessaire pour faire l'operation dans sa totalite). La seule
chose qui change etant l'operation (copy vs. concatenation).
Autant d'endroits en moins pour faire des erreurs...
En quoi tronquer une chaîne n'est pas une erreur ?
Non, non. Apprend a citer correctement deja, c'est pas moi qui ait ecrit ca.
en tout cas, il n'est pas dans Studio qui préfère strcpy_s ...
Je fais partie des gens qui militent pour l'utilisation de strlcpy [...]
et dire que str*l*cpy est mieux que str*n*cpy est suffisant? vraiment?
affirmer "à réimplémenter" me parait insuffisant pour qui a) n'a pas conscience des dangers de str[n]cpy, b) ne sait pas ce qu'un L change par rapport à un N (car les détails d'implémentations donnés s'arrêtent là, dommage un wiki appuierait sûrement mieux l'affirmation).
Tutut! 30 secondes de google t'ameneront sans probleme sur toute la doc que tu veux sur strlcpy/strlcat. Faut quand meme pas faire preuve de trop de mauvaise foi, le papier de Todd Miller qui presente strlcpy et strlcat et leur interet est le 2e lien qui apparait si je cherche strlcpy ! (wikipedia etant le premier).
On trouve aussi assez rapidement l'avis de Ulrich Drepper (c'est lui qui interdit l'addition de ces fonctions dans la glibc). Il dit à propos de strlcpy et stlcat :
This is horribly inefficient BSD crap. Using these function only leads to other errors. Correct string handling means that you always know how long your strings are and therefore you can you memcpy (instead of strcpy). Beside, those who are using strcat or variants deserved to be punished.
It hides bugs in programs. If a string is too long for an allocated memory block the copying must not simply silently stop. Instead the program must reallocate or signal an error.
strlcpy et strlcat ont l'air toutes betes, mais justement, elles sont tres simples d'emploi. Un de leurs interets, c'est qu'elles prennent exactement les memes parametres (dest, source, taille de tampon), et renvoient la meme chose (taille necessaire pour faire l'operation dans sa totalite). La seule chose qui change etant l'operation (copy vs. concatenation). Autant d'endroits en moins pour faire des erreurs...
En quoi tronquer une chaîne n'est pas une erreur ?
-- Richard
Richard Delorme
Xavier Roche a écrit :
Richard Delorme a écrit :
Plus simplement : char mot[60] = "Hello";
Il vaut mieux utiliser strcpy() ou strlcpy() [en standardisation il me semble] ; l'affectation effectue également un memset() silencieux sur les 53 caractères terminaux.
Ce qui est l'effet recherché.
Pour une copie plus sécurisée, on préférera la fonction strncpy().
C'est un conseil idiot, à mon humble avis.
C'est celui de la FAQ.
Au lieu de provoquer un débordement sur strcpy(), on crée une chaine non terminée, qui vous explosera à la figure de manière aléatoire, bien plus tard. Autant avoir un crash direct, débuggable. Bref, strncpy() est une fonction horrible que l'on ne devrait absolument jamais utiliser (c'est vraiment la fonction la plus débile de la libc amha)
Mais strlcpy() est une solution beaucoup plus propre - à réimplémenter au besoin, mais c'est le type de fonction utile.
L'OP est à l'évidence un débutant complet en C, sans doute incapable d'implémenter strlcpy de manière correct(*). La première chose à faire, dans son cas est de lire la FAQ et de suivre ces conseils. Quand on devient un programmeur émérite, on peut alors écrire sa propre bibliothèque de manipulation de chaines, avec un comportement plus cohérent que ce qu'offre la libc. Et dans ce cas, je doute que l'on s'amuse à tronquer des chaines au lieu de les copier.
(*) Pour preuve que ce n'est pas si simple, ici on en trouve une implémentation incorrecte : http://www.oreillynet.com/pub/a/network/2003/05/20/secureprogckbk.html
-- Richard
Xavier Roche a écrit :
Richard Delorme a écrit :
Plus simplement :
char mot[60] = "Hello";
Il vaut mieux utiliser strcpy() ou strlcpy() [en standardisation il me
semble] ; l'affectation effectue également un memset() silencieux sur
les 53 caractères terminaux.
Ce qui est l'effet recherché.
Pour une copie plus sécurisée, on préférera la fonction strncpy().
C'est un conseil idiot, à mon humble avis.
C'est celui de la FAQ.
Au lieu de provoquer un
débordement sur strcpy(), on crée une chaine non terminée, qui vous
explosera à la figure de manière aléatoire, bien plus tard. Autant avoir
un crash direct, débuggable. Bref, strncpy() est une fonction horrible
que l'on ne devrait absolument jamais utiliser (c'est vraiment la
fonction la plus débile de la libc amha)
Mais strlcpy() est une solution beaucoup plus propre - à réimplémenter
au besoin, mais c'est le type de fonction utile.
L'OP est à l'évidence un débutant complet en C, sans doute incapable
d'implémenter strlcpy de manière correct(*). La première chose à faire,
dans son cas est de lire la FAQ et de suivre ces conseils. Quand on
devient un programmeur émérite, on peut alors écrire sa propre
bibliothèque de manipulation de chaines, avec un comportement plus
cohérent que ce qu'offre la libc. Et dans ce cas, je doute que l'on
s'amuse à tronquer des chaines au lieu de les copier.
(*) Pour preuve que ce n'est pas si simple, ici on en trouve une
implémentation incorrecte :
http://www.oreillynet.com/pub/a/network/2003/05/20/secureprogckbk.html
Il vaut mieux utiliser strcpy() ou strlcpy() [en standardisation il me semble] ; l'affectation effectue également un memset() silencieux sur les 53 caractères terminaux.
Ce qui est l'effet recherché.
Pour une copie plus sécurisée, on préférera la fonction strncpy().
C'est un conseil idiot, à mon humble avis.
C'est celui de la FAQ.
Au lieu de provoquer un débordement sur strcpy(), on crée une chaine non terminée, qui vous explosera à la figure de manière aléatoire, bien plus tard. Autant avoir un crash direct, débuggable. Bref, strncpy() est une fonction horrible que l'on ne devrait absolument jamais utiliser (c'est vraiment la fonction la plus débile de la libc amha)
Mais strlcpy() est une solution beaucoup plus propre - à réimplémenter au besoin, mais c'est le type de fonction utile.
L'OP est à l'évidence un débutant complet en C, sans doute incapable d'implémenter strlcpy de manière correct(*). La première chose à faire, dans son cas est de lire la FAQ et de suivre ces conseils. Quand on devient un programmeur émérite, on peut alors écrire sa propre bibliothèque de manipulation de chaines, avec un comportement plus cohérent que ce qu'offre la libc. Et dans ce cas, je doute que l'on s'amuse à tronquer des chaines au lieu de les copier.
(*) Pour preuve que ce n'est pas si simple, ici on en trouve une implémentation incorrecte : http://www.oreillynet.com/pub/a/network/2003/05/20/secureprogckbk.html
