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 passer une chaîne d'un char [] à un autre char []

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

46 réponses
Avatar
j4e8a16n
Bonjour =E0 tous,

int k =3D 0;
char mot [60];
char motTmp [60];

mot [0] =3D 'H';
mot [1] =3D 'e';
mot [2] =3D 'l';
mot [3] =3D 'l';
mot [4] =3D 'o';
mot [5] =3D '\0';

motTmp[0] =3D mot[0];

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

JPD
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 3 4 5
Avatar
Antoine Leca
Le 19/05/2009 17:06, écrivit :
C'est a croire que certaine grosse boite aurait envie de casser les efforts
de normalisation pour que les gens utilisent a la place leur version
proprietaire d'un langage similaire...



La boîte en question a comme objectif déclaré C++, pas C. S'ils
maintiennent encore la version C de leur compilo (ne serait-ce que pour
leur permettre de continuer à compiler un certain béhemoth), ils
annoncent haut et fort que les utilisateurs sont priés de migrer, voire
leur force un peu la main (une initiative dans ce sens prend la forme de
macro avec nom à rallonge à prédéfinir afin d'utiliser la bibliothèque
standard; et en mode non-conforme au standard, c'est pareil).

De fait, je ne sais pas s'ils y sont revenus, mais au début du siècle
ils étaient soigneusement absent du Comité, ainsi d'ailleurs qu'une
bonne partie des vendeurs les plus importants de compilateurs C... Or il
est bien connu que si tu veux torpiller un effort de normalisation, il
faut absolument faire partie du comité chargé de la normalisation ; à
défaut, la normalisation se fait sans toi, et tu n'as pas de prise sur
sa réussite.


Antoine
Avatar
Gabriel Dos Reis
Antoine Leca writes:

[...]

| De fait, je ne sais pas s'ils y sont revenus, mais au début du siècle
| ils étaient soigneusement absent du Comité, ainsi d'ailleurs qu'une
| bonne partie des vendeurs les plus importants de compilateurs C... Or il
| est bien connu que si tu veux torpiller un effort de normalisation, il
| faut absolument faire partie du comité chargé de la normalisation ; à
| défaut, la normalisation se fait sans toi, et tu n'as pas de prise sur
| sa réussite.

Exactement ; c'est pourquoi je pense que notre cher Comité se
débrouille bien tout seul pour saboter l'évolution du C.

-- Gaby
Avatar
candide
Marc Espie a écrit :

C'est a croire que certaine grosse boite aurait envie de casser les efforts
de normalisation pour que les gens utilisent a la place leur version
proprietaire d'un langage similaire...




Antoine Leca a écrit :
La boîte en question a comme objectif déclaré C++, pas C. S'ils
maintiennent encore la version C de leur compilo (ne serait-ce que pour
leur permettre de continuer à compiler un certain béhemoth),



Et la réponse au schmilblick était ? ...
Avatar
Gabriel Dos Reis
candide writes:

[...]

| Et la réponse au schmilblick était ? ...

schmilblick.
Avatar
Remi Koutcherawy
Le 18/05/2009 11:55, Richard Delorme a écrit :
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.


La FAQ mériterait d'être corrigée.
Dans son dernier bulletin d'actualité CERTA donne des liens vers les
listes d'appels de fonctions à bannir
http://www.certa.ssi.gouv.fr/site/CERTA-2009-ACT-021.pdf

On trouve strncpy() dans les appels mal sécurisés
https://www.securecoding.cert.org/confluence/display/seccode/STR03-C.+Do+not+inadvertently+truncate+a+null-terminated+byte+string
Avatar
Eric Levenez
Le 23/05/09 01:19, dans <4a173318$0$17783$, « Remi
Koutcherawy » a écrit :

Le 18/05/2009 11:55, Richard Delorme a écrit :
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.


La FAQ mériterait d'être corrigée.



En §8.2, il est indiqué qu'au lieu d'utiliser strcpy il vaut mieux utiliser
strncpy. <http://www.levenez.com/lang/c/faq/fclc008.html#q_2>

Comme il a été dit ce thread (et dans d'autres), si vraiment on veut en C
plus sécurisé il faudrait proscrire tous les str*, tous les mem*, et bien
sûr tous les pointeurs. Ah, et les malloc / free. Combiens de bugs liés à
l'allocation manuelle de la mémoire ? D'innombrables. Il faudrait donc
supprimer les malloc et donc les free...

Si dans la prochaine version de la norme C, il y a de nouvelles fonctions
str* "plus" sécurisés, il sera bon d'ajouter celles-ci à la FAQ, mais je ne
vois pas l'intérêt de le faire actuellement. Ou alors il faudrait dire
quelque chose du genre, "utiliser de préférence les extensions str* liées à
votre plateforme (voir votre document)".

Mais si d'autres ici veulent une modification de la FAQ, merci de me donner
le texte à ajouter ou à corriger dans celle-ci.

--
Éric Lévénez
FAQ de fclc : <http://www.levenez.com/lang/c/faq/>
Avatar
Antoine Leca
Le 22/05/2009 23:19, Remi Koutcherawy écrivit :
Le 18/05/2009 11:55, Richard Delorme a écrit :
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.


La FAQ mériterait d'être corrigée.



C'est difficile à faire. Tu te proposes pour la maintenance ?

Dans son dernier bulletin d'actualité CERTA donne des liens vers les
listes d'appels de fonctions à bannir
http://www.certa.ssi.gouv.fr/site/CERTA-2009-ACT-021.pdf



Je recopie le passage concerné :

| 3 Des listes d’appels de fonction à bannir
|
| Microsoft maintient depuis plusieurs années une liste d’appels de
| fonctions à bannir par les développeurs. Cette liste contient un
| ensemble d'API à ne pas utiliser afin de limiter les risques de
| vulnérabilités dans les codes développés dans différents langages
| (Visual Basic, C#, C++, J#, JScript et XAML).

Donc sauf erreur ou omission, c'est HS ici.
Voir aussi le schmiblic dans une autre partie de la discussion.


| Microsoft vient récemment d'ajouter à sa liste [...] memcpy()

Là c'est déjà plus intéressant. Sauf que... sauf que le lien est mal
orthographié, et que si l'on va sur le bloc-note en question
(http://blogs.msdn.com/sdl, à propos de memcpy()), on y lit que
Microsoft _pense_ à _modifier_ le statut de memcpy() et la passer de
« non recommandé » à « banni ». Presque pareil.

Et encore plus surprenant, avec les autres liens, je n'ai pas été
capable de trouver la référence réelle dans le site de MS à cette
recommandation; une recherche http://www.google.com/search?q=memcpy+sdl
donne plein de commentaires (plus ou moins corrects, comme la citation
du CERTA) sur le bloc-note en question, mais point de lien vers
http://www.microsoft.com/sdl ...

Bref, s'il s'agissait en fait d'une manœuvre marketing pour essayer de
convaincre les programmeurs de passer à memcpy_s() et ainsi d'augmenter
le poids spécifique de TR24731, je ne serais pas outre mesure surpris.


On trouve strncpy() dans les appels mal sécurisés



Si « mal sécurisées » signifie que l'on peut les utiliser de manière
incorrecte, TOUTES les fonctions de manipulations de chaînes le sont, ou
alors elles ne sont pas largement portables. Et la conclusion la plus
évidente (que rappelle le recueil du CERT que tu cites, STR08-C) est
qu'il vaut alors mieux tout supprimer et utiliser un autre format de
données à la place ; le seul souci, c'est que les chaînes terminées par
, c'est quand même bien pratique dans les « petits projets »...

Et on peut tirer la même conclusion à propos du langage C en général.


Antoine
Avatar
Xavier Roche
Eric Levenez a écrit :
En §8.2, il est indiqué qu'au lieu d'utiliser strcpy il vaut mieux utiliser
strncpy. <http://www.levenez.com/lang/c/faq/fclc008.html#q_2>



Encore une fois c'est amha un mauvais conseil: on déplace le bug de
sécurité plus loin, et avec une probabilité moindre (et donc bug plus
difficilement traçable)

Le souci c'est qu'il n'y a pas de solution miracle:

fonction |conséquence du débordement de la source source
|et problèmes liés à la fonction
-------- +---------------------------------------------
strcpy |débordement de tampon (écriture invalide)
strncpy |débordement de tampon en lecture (lecture invalide)
zero+strncat |pas de détection d'erreur (troncation silencieuse)
strlcpy |non standard, calcule strlen(source) en cas d'erreur
strcpy_s |non standard (refusé dans la glibc)
snprintf |perf du code d'erreur en O(strlen(source))

A tout prendre snprintf() est la seule solution qui (1) n'introduit pas
de problème de sécurité, (2) permet une détection d'erreur facile, et
(3) est totalement standard.

Mais si d'autres ici veulent une modification de la FAQ, merci de me donner
le texte à ajouter ou à corriger dans celle-ci.



Je proposerai bien quelque chose comme:

- Pour une copie plus sécurisée, on préférera la fonction strncpy().
+ Pour une copie plus sécurisée, on préférera la fonction snprintf(dest,
size_dest, "%s", source), qui prend comme second argument la taille de
l'espace de destination, et renvoi le nombre d'octets nécessaire pour
compléter l'opération. Si ce nombre est supérieur ou égal à la taille de
la destination fournie, la copie a été interrompue.
+
+ Exemple:
+ if (snprintf(destination,
+ taille_destination, "%s", source) >= taille_destination) {
+ fprintf(stderr, "débordement détecté!n");
+ exit(EXIT_FAILURE);
+ }
Avatar
Xavier Roche
Eric Levenez a écrit :
En §8.2, il est indiqué qu'au lieu d'utiliser strcpy il vaut mieux utiliser
strncpy. <http://www.levenez.com/lang/c/faq/fclc008.html#q_2>



Encore une fois c'est amha un mauvais conseil: on déplace le bug de
sécurité plus loin, et avec une probabilité moindre (et donc bug plus
difficilement traçable)

Le souci c'est qu'il n'y a pas de solution miracle:

fonction |conséquence du débordement de la source source
|et problèmes liés à la fonction
-------- +---------------------------------------------
strcpy |débordement de tampon (écriture invalide)
strncpy |débordement de tampon en lecture (lecture invalide)
zero+strncat |pas de détection d'erreur (troncation silencieuse)
strlcpy |non standard, calcule strlen(source) en cas d'erreur
strcpy_s |non standard (refusé dans la glibc)
snprintf |perf du code d'erreur en O(strlen(source))

A tout prendre snprintf() est la seule solution qui (1) n'introduit pas
de problème de sécurité, (2) permet une détection d'erreur facile, et
(3) est totalement standard.

Mais si d'autres ici veulent une modification de la FAQ, merci de me donner
le texte à ajouter ou à corriger dans celle-ci.



Je proposerai bien quelque chose comme:

- Pour une copie plus sécurisée, on préférera la fonction strncpy().
+ Pour une copie plus sécurisée, on préférera la fonction snprintf(dest,
size_dest, "%s", source), qui prend comme second argument la taille de
l'espace de destination, et renvoi le nombre de caractères de
destination effectivement nécessaires. Si ce nombre est supérieur ou
égal à la taille de la destination fournie, c'est que la la copie a été
tronquée.
+
+ Exemple:
+ if (snprintf(destination,
+ taille_destination, "%s", source) >= taille_destination) {
+ fprintf(stderr, "destination trop petite!n");
+ exit(EXIT_FAILURE);
+ }
Avatar
-ed-
On 23 mai, 14:57, Xavier Roche wrote:
Le souci c'est qu'il n'y a pas de solution miracle:



zero+strncat    |pas de détection d'erreur (troncation silencieuse)



C'est quand même ce qu'il y a de plus sûr...

Une autre façon de faire est d'utiliser un ADT qui gère la dimension
requise...

Par exemple :

http://www.bien-programmer.fr/clib.htm
Module FSTR (Flexible STRing).
1 2 3 4 5