strcpy sur un char[1] ???
Le
Alain Montfranc
Bonjour
Dans un code source je trouve cela :
struct NAME
{
struct NAME * next;
char name[1];
};
puis :
strcpy(p->name, dp2->d_name);
Il me semble que strcpy copie jusqu'au premier ? A moins que la
chaine soit vide, ce genre de truc va forcément "déborder", non et
corrompre la stack ?
Dans un code source je trouve cela :
struct NAME
{
struct NAME * next;
char name[1];
};
puis :
strcpy(p->name, dp2->d_name);
Il me semble que strcpy copie jusqu'au premier ? A moins que la
chaine soit vide, ce genre de truc va forcément "déborder", non et
corrompre la stack ?
strcpy sur un char[1] ???,
Alain Montfranc écrivait dans fr.comp.lang.c :
Rebonjour ;-)
Des noms, des noms, des noms ! ;-)
Oui. Je site :
La fonction strcpy() copie la chaîne pointée par src, y compris le car
actère nul (« ») final dans la chaîne pointée par dest.
Ça déborde dès que la chaine source est de taille strictement supérieure
à 0
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Tout dépend de comment a été alloué p.
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Par un malloc. Ca change quoi ?
openqm, version gpl
beurk quoi...
malloc avec quelle taille ? C'est une technique classique en C pré 99
d'avoir une structure qui déclare un dernier composant qui est un
tableau de taille 1, mais la taille allouée est celle qu'il faut.
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
ok
Et...
Cela ne déborde que si la chaîne finale (la vraie, pas la déclaration) a une
taille réservée inférieure à la taille réelle (strlen+1) de la chaîne
origine.
Et en C, du fait de l'équivalence pointeur-tableau, la déclaration
« visible » d'un tableau n'est pas forcément la déclaration réelle, en
particulier en ce qui concerne la taille du tableau.
Antoine
Re: strcpy sur un char[1] ???,
Antoine Leca écrivait dans fr.comp.lang.c :
Nous sommes d'accord, mais je réagissais avec le source sous les
yeux (ce fil est issu d'une discussion avec un psychopathe sur un
autre forum). Dans le code en question, une structure est déclarée,
et _jamais_ on ne contrôle que le strcpy ne va pas écraser quelque
chose.
Cordialement,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Avec strcpy tout seul, il est virtuellement impossible de contrôler que tu
ne vas pas écraser quelque chose.
Problème, la logique de nommage de la norme semble proposer strncpy quand tu
veux contrôler, et pour des raisons historiques strncpy n'a pas cette
fonction ; il faudrait utiliser strlcpy qui n'est pas normalisée, ou
snprintf qui est d'une part C99 et d'autre part demande plus de ressources,
ou sprintf(,"%.*s",) qui demande aussi beaucoup de ressources et n'est pas
facile à relire car ce n'est pas « idiomatique »¹, ou strcpy_s qui est la
réponse officielle du comité mais n'est pas très répandue, voire strncpy_s
qui cumule tous les inconvénients : 4 arguments, sémantique différente à la
fois de strncpy et de strlcpy, peu utilisée, possibilité de mettre en jeu un
mécanisme d'exception à rebond multiple, fonction des implémentations et
potentiellement différent à la fois de signal/raise et de setjmp/longjmp.
Par ailleurs, et c'était mon propos ci-dessus, lorsque tu utilises
fct_qui_modifie_arg1(p->name, ...), la structure qui est déclarée pour &p
importe peu, c'est la structure réellement utilisée pour l'allocation qui
importe (le C a une règle spéciale pour permettre justement ce genre
d'utilisation); note bien que dans le cas d'une allocation dynamique, même
la déclaration utilisée pour l'allocation de la structure qui va être passée
ensuite dans le pointeur p [ouf!] n'importe pas vraiment, c'est en fait le
paramètre passé à malloc/calloc/realloc ou équivalent qui va déterminer
indirectement la taille des éléments de la structure.
Antoine
__________
¹: Techniquement c'est-à-dire dans le respect strict de la norme, s[n]printf
sont de plus limitées à des chaînes de 4095 caractères avec C99, voire 509
en C90.
Re: strcpy sur un char[1] ???,
Antoine Leca écrivait dans fr.comp.lang.c :
Je sais bien, on contrôle les longueurs _avant_ d'appliquer le
strcpy. Ce qui n'est pas fait dans le code dont on parle.
Nous sommes bien d'accord. Sauf que dans le cas présent, on alloue
une structure d'une certaine taille et on écrit brutalement
derrière. C'est assez casse-gueule comme manipulation. Note que je
ne parle que du code en question et non de la programmation C en
général.
Cordialement,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.