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

6 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
Xavier Roche
-ed- a écrit :
zero+strncat |pas de détection d'erreur (troncation silencieuse)


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



Non, c'est snprintf() le plus sûr. La troncation peut avoir des
conséquences ennuyeuses (exemple: un nom de fichier qui est tronqué, et
sur un binaire éxecuté en root, cela peut faire des choses affreuses) en
terme de sécurité.

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



Oui, certes, la solution de toute manière, est de ne plus utiliser du
tout la libc pour les chaînes, mais une bibliothèque encapsulée, qui
gère le redimensionnement et la copie de manière sûre et efficace.
Avatar
Alexandre Bacquart
Antoine Leca wrote:
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é,



Ils ont zappé le tiret entre *join* et *me*. L'URL est donc :

http://blogs.msdn.com/sdl/archive/2009/05/14/please-join-me-in-welcoming-memcpy-to-the-sdl-rogues-gallery.aspx

La vache ! Je vois difficilement comment ce tiret a pu disparaître
autrement que par une saisie manuelle de l'URL... ça craint. A moins que
Microsoft ait changé le nom de la page après quelques jours, ce qui
est aussi très con pour un sujet aussi sensible que la sécurité.

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.



A noter quand-même que c'est l'avis d'un gus... et que, toujours d'après
le même gus, la méthode purgative passe par des pragma (il y en a bien
un pour gcc, allez). Beuark. Et d'appliquer cela avec une fonction
memcpy_s() (M$-only) du même gabarit que strlcpy() (BSD) et autres
non-solutions. Et en plus, c'est très récent (14 mai 2009) et memcpy()
existe depuis 30 ans. Le réveil aura été long ! Bref, pas très sérieux
toussa.

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.



Ce que je trouve surprenant, c'est qu'à ce sujet, le point 3 du document
du CERTA, un organisme gouvernemental, cite 4 sources dont 3 d'origine
Microsoft. Alors oui, avec leur parc installé, ils sont sans doute les
plus concernés et ont leur mot à dire, mais limite quoi : C !=
Microsoft. On est en droit de demander d'autres sources.

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.



Mouais. Franchement, mettre sur le dos de C tous les malheurs du monde
me semble pour le moins hâtif. C'est un langage bas niveau (en dessous,
c'est l'assembleur), ça donne quelques pouvoirs non négligeables, gorets
s'abstenir. Ce n'est pas en remplaçant des fonctions standards dont le
comportement est clairement défini depuis des lustres par des fonctions
non standards qu'on fera avancer le shmilblick...


--
Alex
Avatar
Hamiral
Xavier Roche a écrit :
Une autre façon de faire est d'utiliser un ADT qui gère la dimensi on
requise...



Oui, certes, la solution de toute manière, est de ne plus utiliser du
tout la libc pour les chaînes, mais une bibliothèque encapsulée, qui
gère le redimensionnement et la copie de manière sûre et efficace .



C'est bien ce que je pense aussi, mais si on en arrive là, c'est bien
que le C a été très très très mal pensé pour la gestion des c haînes de
caractères.
Heureusement qu'il n'y a pas que ça dans la vie d'un programmeur :)

Ham
Avatar
-ed-
On 25 mai, 16:15, Hamiral wrote:
Xavier Roche a écrit :

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

> Oui, certes, la solution de toute manière, est de ne plus utiliser du
> tout la libc pour les chaînes, mais une bibliothèque encapsulée, qui
> gère le redimensionnement et la copie de manière sûre et efficace .

C'est bien ce que je pense aussi, mais si on en arrive là, c'est bien
que le C a été très très très mal pensé pour la gestion des c haînes de
caractères.
Heureusement qu'il n'y a pas que ça dans la vie d'un programmeur :)



Certes, il estcertains domaines où les ch
Avatar
-ed-
On 25 mai, 16:15, Hamiral wrote:
Xavier Roche a écrit :

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

> Oui, certes, la solution de toute manière, est de ne plus utiliser du
> tout la libc pour les chaînes, mais une bibliothèque encapsulée, qui
> gère le redimensionnement et la copie de manière sûre et efficace .

C'est bien ce que je pense aussi, mais si on en arrive là, c'est bien
que le C a été très très très mal pensé pour la gestion des c haînes de
caractères.
Heureusement qu'il n'y a pas que ça dans la vie d'un programmeur :)



certes, il est certains domaines où les chaines sont peu ou pas
utilisées (système, calculs etc.), mais il parait difficile de s'en
passer dans des domaines tels que le traitement de données, surtout si
il s'agit de couches de présentation comme html, par exemple. Il est
clair que le C est un langage de base, simple, de bas niveau, pour qui
les chaines de caractères sont une entité 'évoluée". Ce qu'on fait en
C est très proche de ce qu'on fait en assembleur en ce qui concerne
les chaines...

Si on a beaucoup de traitements à faire, soit un utilise un langage
plus évolué (java, php etc.), soit on 'enseigne' au C à gérer l'obj et
'chaine' de manière plus sûre. On peu regretter qu'il n'existe pas
d'objet 'STRING' comme il existe un objet 'FILE', dans le langage C,
mais c'est comme ça. L'avantage du C, c'est que lorsqu'un outil
manque, on a les moyens de le construire (et la fierté d'utiliser son
outil, comme le fait un artisan...)
Avatar
Antoine Leca
Le 25/05/2009 14:15, Hamiral écrivit :
Xavier Roche a écrit :
Oui, certes, la solution de toute manière, est de ne plus utiliser du
tout la libc pour les chaînes, mais une bibliothèque encapsulée, qui
gère le redimensionnement et la copie de manière sûre et efficace.



C'est bien ce que je pense aussi, mais si on en arrive là, c'est bien
que le C a été très très très mal pensé pour la gestion des chaînes de
caractères.



Non, c'est parce qu'il n'y a pas (encore) de consensus sur la manière de
modéliser ces objets.

La solution des années 70, en dehors d'être bien adaptée aux
contingences matérielles des années 70, donne encore satisfaction pour
pas mal d'utilisations (comme par exemple les constantes chaînes).
Ce sont les chaînes dynamiques qui posent problème; mais beaucoup de
programmes C n'ont pas besoin de les gérer, ce qui crée un frein naturel.

Par ailleurs, il ne devrait pas échapper que strdup() ne fait pas partie
de la bibliothèque standard de la norme C, ce qui est un indice que
l'utilisation mélangeant chaînes de caractère et allocation dynamique
est à la limite de l'épure du langage.


Antoine
1 2 3 4 5