Le unsigned est même inutile. Et puis mettre strlen(source) dans une variable serait plus efficace. Sinon, je suppose que la chaîne est reparcourue à chaque appel, non?
Le unsigned est même inutile. Et puis mettre strlen(source) dans une
variable serait plus efficace. Sinon, je suppose que la chaîne est
reparcourue à chaque appel, non?
Le unsigned est même inutile. Et puis mettre strlen(source) dans une variable serait plus efficace. Sinon, je suppose que la chaîne est reparcourue à chaque appel, non?
Mauvais nom de fonction, tout str* est reserve pour la bibliotheque standard.
char * strsub(char * source, int end){
char *dest = (char*)malloc(strlen(source)+1); char *tmp = source + end; Si end est plus grand que strlen(source), alors tmp n'est meme pas defini.
strcpy(dest, "a");
Merci d'eviter de laisser les cochonneries de debug dans le code que tu montres.
if(strlen(source)<255 && strlen(source) > (unsigned)source + end){ Je ne comprend pas l'interet de limiter arbitrairement a 255 caracteres.
Le 2e test est trivialement faux. D'ailleurs, tu as du mettre un cast. Mais bon, c'est pas surprenant, comme dirait un physicien, c'est pas homogene: tu es en train de comparer des pointeurs et des longueurs.
while(source++ < tmp){ *dest++ = *source; } dest = ' '; Bon, ton dest est un tantinet gros dans pas mal de cas.
return dest; }else{ return "Chaîne de plus de 255 lettres ou indice de fin trop grand."; } }
int main(void) { char *chaine = "Chaîne de plus de 255 lettres.";
Mauvais nom de fonction, tout str* est reserve pour la bibliotheque standard.
char * strsub(char * source, int end){
char *dest = (char*)malloc(strlen(source)+1);
char *tmp = source + end;
Si end est plus grand que strlen(source), alors tmp n'est meme pas defini.
strcpy(dest, "a");
Merci d'eviter de laisser les cochonneries de debug dans le code que tu
montres.
if(strlen(source)<255 && strlen(source) > (unsigned)source +
end){
Je ne comprend pas l'interet de limiter arbitrairement a 255 caracteres.
Le 2e test est trivialement faux. D'ailleurs, tu as du mettre un cast.
Mais bon, c'est pas surprenant, comme dirait un physicien, c'est pas
homogene: tu es en train de comparer des pointeurs et des longueurs.
while(source++ < tmp){
*dest++ = *source;
}
dest = ' ';
Bon, ton dest est un tantinet gros dans pas mal de cas.
return dest;
}else{
return "Chaîne de plus de 255 lettres ou indice de fin trop
grand.";
}
}
int main(void)
{
char *chaine = "Chaîne de plus de 255 lettres.";
Mauvais nom de fonction, tout str* est reserve pour la bibliotheque standard.
char * strsub(char * source, int end){
char *dest = (char*)malloc(strlen(source)+1); char *tmp = source + end; Si end est plus grand que strlen(source), alors tmp n'est meme pas defini.
strcpy(dest, "a");
Merci d'eviter de laisser les cochonneries de debug dans le code que tu montres.
if(strlen(source)<255 && strlen(source) > (unsigned)source + end){ Je ne comprend pas l'interet de limiter arbitrairement a 255 caracteres.
Le 2e test est trivialement faux. D'ailleurs, tu as du mettre un cast. Mais bon, c'est pas surprenant, comme dirait un physicien, c'est pas homogene: tu es en train de comparer des pointeurs et des longueurs.
while(source++ < tmp){ *dest++ = *source; } dest = ' '; Bon, ton dest est un tantinet gros dans pas mal de cas.
return dest; }else{ return "Chaîne de plus de 255 lettres ou indice de fin trop grand."; } }
int main(void) { char *chaine = "Chaîne de plus de 255 lettres.";
N'ayant pu trouver une fonction du genre sur google...
Tu as mal cherché ;) La fonction que tu cherches est strncpy, décrite dans le même manpage que strcpy : <http://www.linux-france.org/article/man-fr/man3/strcpy-3.html>
N'ayant pu trouver une fonction du genre sur google...
Tu as mal cherché ;) La fonction que tu cherches est strncpy, décrite
dans le même manpage que strcpy :
<http://www.linux-france.org/article/man-fr/man3/strcpy-3.html>
N'ayant pu trouver une fonction du genre sur google...
Tu as mal cherché ;) La fonction que tu cherches est strncpy, décrite dans le même manpage que strcpy : <http://www.linux-france.org/article/man-fr/man3/strcpy-3.html>
In article <479d3fd2$0$14905$, Mickaël Wolff wrote:
Bonjour à tous,
Bonjour,
N'ayant pu trouver une fonction du genre sur google...
Tu as mal cherché ;) La fonction que tu cherches est strncpy, décrite dans le même manpage que strcpy : <http://www.linux-france.org/article/man-fr/man3/strcpy-3.html>
Non, meme pas.
strncpy possede l'enorme gros defaut de *remplir* completement son buffer de zeros, quoi qu'il arrive. Et l'autre enorme gros defaut de ne pas mettre de zero final quand le buffer deborde.
strncpy a une utilisation bien precise, qui est de convertir des chaines du C en un format d'un autre age, tel que celui utilise par l'utmp ou par les entetes d'archive ar.
In article <479d3fd2$0$14905$426a34cc@news.free.fr>,
Mickaël Wolff <mickael.wolff@laposte.net> wrote:
Bonjour à tous,
Bonjour,
N'ayant pu trouver une fonction du genre sur google...
Tu as mal cherché ;) La fonction que tu cherches est strncpy, décrite
dans le même manpage que strcpy :
<http://www.linux-france.org/article/man-fr/man3/strcpy-3.html>
Non, meme pas.
strncpy possede l'enorme gros defaut de *remplir* completement son buffer
de zeros, quoi qu'il arrive. Et l'autre enorme gros defaut de ne pas mettre
de zero final quand le buffer deborde.
strncpy a une utilisation bien precise, qui est de convertir des chaines
du C en un format d'un autre age, tel que celui utilise par l'utmp ou par
les entetes d'archive ar.
In article <479d3fd2$0$14905$, Mickaël Wolff wrote:
Bonjour à tous,
Bonjour,
N'ayant pu trouver une fonction du genre sur google...
Tu as mal cherché ;) La fonction que tu cherches est strncpy, décrite dans le même manpage que strcpy : <http://www.linux-france.org/article/man-fr/man3/strcpy-3.html>
Non, meme pas.
strncpy possede l'enorme gros defaut de *remplir* completement son buffer de zeros, quoi qu'il arrive. Et l'autre enorme gros defaut de ne pas mettre de zero final quand le buffer deborde.
strncpy a une utilisation bien precise, qui est de convertir des chaines du C en un format d'un autre age, tel que celui utilise par l'utmp ou par les entetes d'archive ar.
Antoine Leca
Voir aussi les commentaires de Marc dans news:fnfmpa$rvo$,, je n'ai pas souligné tous les problèmes qu'il a soulevés à juste titre. Mais j'en vois plusieurs autres...
En news:Nyymj.2428$, Jean Pierre Daviau va escriure:
dest point*ait* vers une zone de mémoire allouée dynamiquement, et cette valeur n'est jamais sauvegardée, on va droit vers un problème de fuite mémoire...
} dest = ' ';
Je suppose qu'il y a une erreur de copier-collé, et qu'il s'agit de
*dest = ' ';
return dest;
Bah... l'intérêt de renvoyer un pointeur vers la fin d'une chaîne ?
}else{ return "Chaîne de plus de 255 lettres ou indice de fin trop grand.";
Mmmh... dans l'autre cas, la chaîne est allouée dynamiquemnt ; dans ce cas-ci, c'est une allocation statique. Ce genre de confusion mène à des problèmes quand il faudra plus tard déterminer s'il faut déallouer l'espace alloué.
Ce que tu sembles vouloir faire peut être écrit plus proprement avec deux appels, malloc() puis strlcpy(), en séparant les logiques de contrôle des cas pathologiques pour chacune des deux fonctions. Enfin je pense.
char *chaine = "Chaîne de plus de 255 lettres.";
Ah bon ?
Antoine
Voir aussi les commentaires de Marc dans
news:fnfmpa$rvo$1@biggoron.nerim.net,, je n'ai pas souligné tous les
problèmes qu'il a soulevés à juste titre. Mais j'en vois plusieurs autres...
En news:Nyymj.2428$W95.5894@weber.videotron.net, Jean Pierre Daviau va
escriure:
dest point*ait* vers une zone de mémoire allouée dynamiquement, et cette
valeur n'est jamais sauvegardée, on va droit vers un problème de fuite
mémoire...
}
dest = ' ';
Je suppose qu'il y a une erreur de copier-collé, et qu'il s'agit de
*dest = ' ';
return dest;
Bah... l'intérêt de renvoyer un pointeur vers la fin d'une chaîne ?
}else{
return "Chaîne de plus de 255 lettres ou indice de fin trop
grand.";
Mmmh... dans l'autre cas, la chaîne est allouée dynamiquemnt ; dans ce
cas-ci, c'est une allocation statique. Ce genre de confusion mène à des
problèmes quand il faudra plus tard déterminer s'il faut déallouer l'espace
alloué.
Ce que tu sembles vouloir faire peut être écrit plus proprement avec deux
appels, malloc() puis strlcpy(), en séparant les logiques de contrôle des
cas pathologiques pour chacune des deux fonctions.
Enfin je pense.
Voir aussi les commentaires de Marc dans news:fnfmpa$rvo$,, je n'ai pas souligné tous les problèmes qu'il a soulevés à juste titre. Mais j'en vois plusieurs autres...
En news:Nyymj.2428$, Jean Pierre Daviau va escriure:
dest point*ait* vers une zone de mémoire allouée dynamiquement, et cette valeur n'est jamais sauvegardée, on va droit vers un problème de fuite mémoire...
} dest = ' ';
Je suppose qu'il y a une erreur de copier-collé, et qu'il s'agit de
*dest = ' ';
return dest;
Bah... l'intérêt de renvoyer un pointeur vers la fin d'une chaîne ?
}else{ return "Chaîne de plus de 255 lettres ou indice de fin trop grand.";
Mmmh... dans l'autre cas, la chaîne est allouée dynamiquemnt ; dans ce cas-ci, c'est une allocation statique. Ce genre de confusion mène à des problèmes quand il faudra plus tard déterminer s'il faut déallouer l'espace alloué.
Ce que tu sembles vouloir faire peut être écrit plus proprement avec deux appels, malloc() puis strlcpy(), en séparant les logiques de contrôle des cas pathologiques pour chacune des deux fonctions. Enfin je pense.
char *chaine = "Chaîne de plus de 255 lettres.";
Ah bon ?
Antoine
Mickaël Wolff
Bonjour,
Non, meme pas.
Tout à fait.
« La fonction strncpy() est identique, sauf que seuls les n premiers octets de src sont copiés. Ainsi, s'il n'y a pas de caractère nul dans les n premiers octets de src, la chaîne résultante ne disposera de caractère nul final. »
strncpy possede l'enorme gros defaut de *remplir* completement son buffer de zeros, quoi qu'il arrive.
Ce qui est un avantage.
Et l'autre enorme gros defaut de ne pas mettre de zero final quand le buffer deborde.
Il ne peut pas déborder. Et combien même tu déborde, il y aurait un problème. Au fait, lorsque strcpy déborde, les données écrites en trop sont susceptible d'écraser le pointeur de retour (pour retrouver le point d'appel de la fonction) et la valeur de retour de la fonction, si ce n'est plus. Donc considérer qu'on peut tolérer un buffer overflow tant qu'il termine par un ' ', c'est cavalier.
strncpy a une utilisation bien precise, qui est de convertir des chaines du C en un format d'un autre age, tel que celui utilise par l'utmp ou par les entetes d'archive ar.
Euh... non, strncpy est une fonction relativement récente, qui vise à copier une chaine dans une zone mémoire réservée, avec une limite de sécurité. Bien sûr cette limite peut être détournée pour obtenir l'usage que tu recherche.
Essaye de mettre de l'eau dans ton vin, ça ne mange pas de pain, et on te passera plus volontier des erreurs grossières de comparaisons incohérentes ou d'affectations hasardeuses.
Mickaël (qui n'est pas plus doué, mais qui essaye de moins cracher dans la soupe). -- Mickaël Wolff aka Lupus Michaelis http://lupusmic.org
Bonjour,
Non, meme pas.
Tout à fait.
« La fonction strncpy() est identique, sauf que seuls les n
premiers octets de src sont copiés. Ainsi, s'il n'y a pas
de caractère nul dans les n premiers octets de src, la
chaîne résultante ne disposera de caractère nul final. »
strncpy possede l'enorme gros defaut de *remplir* completement son buffer
de zeros, quoi qu'il arrive.
Ce qui est un avantage.
Et l'autre enorme gros defaut de ne pas mettre
de zero final quand le buffer deborde.
Il ne peut pas déborder. Et combien même tu déborde, il y aurait un
problème. Au fait, lorsque strcpy déborde, les données écrites en trop
sont susceptible d'écraser le pointeur de retour (pour retrouver le
point d'appel de la fonction) et la valeur de retour de la fonction, si
ce n'est plus. Donc considérer qu'on peut tolérer un buffer overflow
tant qu'il termine par un ' ', c'est cavalier.
strncpy a une utilisation bien precise, qui est de convertir des chaines
du C en un format d'un autre age, tel que celui utilise par l'utmp ou par
les entetes d'archive ar.
Euh... non, strncpy est une fonction relativement récente, qui vise à
copier une chaine dans une zone mémoire réservée, avec une limite de
sécurité. Bien sûr cette limite peut être détournée pour obtenir l'usage
que tu recherche.
Essaye de mettre de l'eau dans ton vin, ça ne mange pas de pain, et on
te passera plus volontier des erreurs grossières de comparaisons
incohérentes ou d'affectations hasardeuses.
Mickaël (qui n'est pas plus doué, mais qui essaye de moins cracher
dans la soupe).
--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org
« La fonction strncpy() est identique, sauf que seuls les n premiers octets de src sont copiés. Ainsi, s'il n'y a pas de caractère nul dans les n premiers octets de src, la chaîne résultante ne disposera de caractère nul final. »
strncpy possede l'enorme gros defaut de *remplir* completement son buffer de zeros, quoi qu'il arrive.
Ce qui est un avantage.
Et l'autre enorme gros defaut de ne pas mettre de zero final quand le buffer deborde.
Il ne peut pas déborder. Et combien même tu déborde, il y aurait un problème. Au fait, lorsque strcpy déborde, les données écrites en trop sont susceptible d'écraser le pointeur de retour (pour retrouver le point d'appel de la fonction) et la valeur de retour de la fonction, si ce n'est plus. Donc considérer qu'on peut tolérer un buffer overflow tant qu'il termine par un ' ', c'est cavalier.
strncpy a une utilisation bien precise, qui est de convertir des chaines du C en un format d'un autre age, tel que celui utilise par l'utmp ou par les entetes d'archive ar.
Euh... non, strncpy est une fonction relativement récente, qui vise à copier une chaine dans une zone mémoire réservée, avec une limite de sécurité. Bien sûr cette limite peut être détournée pour obtenir l'usage que tu recherche.
Essaye de mettre de l'eau dans ton vin, ça ne mange pas de pain, et on te passera plus volontier des erreurs grossières de comparaisons incohérentes ou d'affectations hasardeuses.
Mickaël (qui n'est pas plus doué, mais qui essaye de moins cracher dans la soupe). -- Mickaël Wolff aka Lupus Michaelis http://lupusmic.org