passer une chaîne d'un char [] à un autre char []

Le
j4e8a16n
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] = '';

motTmp[0] = mot[0];

while(motTmp[k++] != '')
printf("%c", *motTmp);

JPD
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 5
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Richard Delorme
Le #19355181
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] = '';



Plus simplement :
char mot[60] = "Hello";


motTmp[0] = mot[0];




http://www.levenez.com/lang/c/faq/fclc008.html#q_2

8.2 Comment recopier une chaîne dans une autre ?

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
Le #19355331
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.
Eric Levenez
Le #19355541
Le 17/05/09 20:55, dans
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 :
Xavier Roche
Le #19355681
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.
espie
Le #19356251
In article Eric Levenez
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
Le #19357141
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.
espie
Le #19357211
In article Sylvain SF
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.
Gabriel Dos Reis
Le #19357491
(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
Richard Delorme
Le #19359091
Marc Espie a écrit :
In article Sylvain SF
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
Richard Delorme
Le #19359241
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
Publicité
Poster une réponse
Anonyme