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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
Alain Montfranc écrivait :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 ?
Tout dépend de comment a été alloué p.
Alain Montfranc <x@x.con> écrivait :
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 ?
Tout dépend de comment a été alloué p.
Alain Montfranc écrivait :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 ?
Tout dépend de comment a été alloué p.
Le 06-09-2008, à propos de
strcpy sur un char[1] ???,
Alain Montfranc écrivait dans fr.comp.lang.c :Bonjour
Rebonjour ;-)Dans un code source je trouve cela :
struct NAME
{
struct NAME * next;
char name[1];
};
puis :
strcpy(p->name, dp2->d_name);
Des noms, des noms, des noms ! ;-)
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 ?
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 06-09-2008, à propos de
strcpy sur un char[1] ???,
Alain Montfranc écrivait dans fr.comp.lang.c :
Bonjour
Rebonjour ;-)
Dans un code source je trouve cela :
struct NAME
{
struct NAME * next;
char name[1];
};
puis :
strcpy(p->name, dp2->d_name);
Des noms, des noms, des noms ! ;-)
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 ?
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 06-09-2008, à propos de
strcpy sur un char[1] ???,
Alain Montfranc écrivait dans fr.comp.lang.c :Bonjour
Rebonjour ;-)Dans un code source je trouve cela :
struct NAME
{
struct NAME * next;
char name[1];
};
puis :
strcpy(p->name, dp2->d_name);
Des noms, des noms, des noms ! ;-)
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 ?
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
Erwan David a écritAlain Montfranc écrivait :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 ?
Tout dépend de comment a été alloué p.
Par un malloc. Ca change quoi ?
Erwan David a écrit
Alain Montfranc <x@x.con> écrivait :
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 ?
Tout dépend de comment a été alloué p.
Par un malloc. Ca change quoi ?
Erwan David a écritAlain Montfranc écrivait :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 ?
Tout dépend de comment a été alloué p.
Par un malloc. Ca change quoi ?
Alain Montfranc écrivait :Erwan David a écritAlain Montfranc écrivait :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 ?
Tout dépend de comment a été alloué p.
Par un malloc. Ca change 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.
Alain Montfranc <x@x.con> écrivait :
Erwan David a écrit
Alain Montfranc <x@x.con> écrivait :
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 ?
Tout dépend de comment a été alloué p.
Par un malloc. Ca change 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.
Alain Montfranc écrivait :Erwan David a écritAlain Montfranc écrivait :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 ?
Tout dépend de comment a été alloué p.
Par un malloc. Ca change 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 06-09-2008, à propos de strcpy sur un char[1] ???,
Alain Montfranc écrivait dans fr.comp.lang.c :struct NAME { struct NAME * next; char name[1]; };
strcpy(p->name, dp2->d_name);
Il me semble que strcpy copie jusqu'au premier ?
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
Le 06-09-2008, à propos de strcpy sur un char[1] ???,
Alain Montfranc écrivait dans fr.comp.lang.c :
struct NAME { struct NAME * next; char name[1]; };
strcpy(p->name, dp2->d_name);
Il me semble que strcpy copie jusqu'au premier ?
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
Le 06-09-2008, à propos de strcpy sur un char[1] ???,
Alain Montfranc écrivait dans fr.comp.lang.c :struct NAME { struct NAME * next; char name[1]; };
strcpy(p->name, dp2->d_name);
Il me semble que strcpy copie jusqu'au premier ?
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
En news:, JKB va escriure:Le 06-09-2008, à propos de strcpy sur un char[1] ???,
Alain Montfranc écrivait dans fr.comp.lang.c :struct NAME { struct NAME * next; char name[1]; };
strcpy(p->name, dp2->d_name);
Il me semble que strcpy copie jusqu'au premier ?
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.
Et...Ça déborde dès que la chaine source est de taille strictement
supérieure à 0
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.
En news:slrngc5jaf.mmh.knatschke@rayleigh.systella.fr, JKB va escriure:
Le 06-09-2008, à propos de strcpy sur un char[1] ???,
Alain Montfranc écrivait dans fr.comp.lang.c :
struct NAME { struct NAME * next; char name[1]; };
strcpy(p->name, dp2->d_name);
Il me semble que strcpy copie jusqu'au premier ?
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.
Et...
Ça déborde dès que la chaine source est de taille strictement
supérieure à 0
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.
En news:, JKB va escriure:Le 06-09-2008, à propos de strcpy sur un char[1] ???,
Alain Montfranc écrivait dans fr.comp.lang.c :struct NAME { struct NAME * next; char name[1]; };
strcpy(p->name, dp2->d_name);
Il me semble que strcpy copie jusqu'au premier ?
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.
Et...Ça déborde dès que la chaine source est de taille strictement
supérieure à 0
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 Leca écrivait dans fr.comp.lang.c :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.
Nous sommes d'accord, mais je réagissais avec le source sous les
yeux [...]. 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.
Antoine Leca écrivait dans fr.comp.lang.c :
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.
Nous sommes d'accord, mais je réagissais avec le source sous les
yeux [...]. 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.
Antoine Leca écrivait dans fr.comp.lang.c :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.
Nous sommes d'accord, mais je réagissais avec le source sous les
yeux [...]. 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.
En news:, JKB va escriure:Antoine Leca écrivait dans fr.comp.lang.c :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.
Nous sommes d'accord, mais je réagissais avec le source sous les
yeux [...]. 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.
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.
En news:slrngcce7p.rul.knatschke@rayleigh.systella.fr, JKB va escriure:
Antoine Leca écrivait dans fr.comp.lang.c :
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.
Nous sommes d'accord, mais je réagissais avec le source sous les
yeux [...]. 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.
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.
En news:, JKB va escriure:Antoine Leca écrivait dans fr.comp.lang.c :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.
Nous sommes d'accord, mais je réagissais avec le source sous les
yeux [...]. 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.
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.