Non, non. Apprend a citer correctement deja, c'est pas moi qui ait ecrit ca.
en tout cas, il n'est pas dans Studio qui préfère strcpy_s ...
?!? on ne peut répondre qu'à Marc lorsque l'on poste après Marc ??
citer ce point pour indiquer que Microsoft a introduit des fonctions (que tu commentes plus bas) aussi absentes des standards que strlcpy était pertinent pour illustrer l'état des lieux.
Tutut! 30 secondes de google t'ameneront sans probleme sur toute la doc que tu veux sur strlcpy/strlcat. Faut quand meme pas faire preuve de trop de mauvaise foi.
ce n'était pas mon point - et 5 sec. de google suffisait.
Xavier (oui, non Marc, mais je répondais au fil) suggère strlcpy sans détail (ou le feature invalide un memset sur les octets non utilisés) et tu n'as qu'ajouter ton militantisme pour cette fonction; soit google existe en complément mais si l'échanges d'avis et d'expériences passent par le seul échange de liens google on y perdra un peu et pas qu'en bonne foi.
Si tu veux vraiment un resume rapide, strncpy n'est pas efficace [...]
assurément.
strcpy_s n'est pas super-bien foutue en cas de debordement. En particulier, tu ne sais pas vraiment de combien tu debordes.
en général on s'en tape, si on n'a calculé les tailles avant la copie c'est que cela "devait suffire", un flag "échec" est alors suffisant pour trapper et recommencer avec une autre stratégie.
quand tu en es au 3e programmeur ruse qui se plante dans ses calculs de strcpy, ou qui utilise strncat de facon incorrecte, tu vois strlcpy et strlcat comme vachement bien, finalement.
je ne code jamais en russe, et assez peu en C en fait, quand je le fais j'utilise une struct codant séparement la longueur de la chaîne (à l'image des SafeStr etc), je me range ici à l'avis de Gabriel qu'une structure claire et une nouvelle famille de fonctions permettent (seules?) une utilisation maîtrisée des chaînes (je parle ici d'appl. dont celles de débutant, pas de code bas niveau qui peuvent exiger l'emploi de la libc).
Sylvain.
>>
Peut-être qu'un jour strlcpy sera dans la norme
Non, non. Apprend a citer correctement deja, c'est pas moi qui ait ecrit ca.
en tout cas, il n'est pas dans Studio qui préfère strcpy_s ...
?!? on ne peut répondre qu'à Marc lorsque l'on poste après Marc ??
citer ce point pour indiquer que Microsoft a introduit des fonctions
(que tu commentes plus bas) aussi absentes des standards que strlcpy
était pertinent pour illustrer l'état des lieux.
Tutut! 30 secondes de google t'ameneront sans probleme sur toute la doc
que tu veux sur strlcpy/strlcat. Faut quand meme pas faire preuve de trop
de mauvaise foi.
ce n'était pas mon point - et 5 sec. de google suffisait.
Xavier (oui, non Marc, mais je répondais au fil) suggère strlcpy sans
détail (ou le feature invalide un memset sur les octets non utilisés)
et tu n'as qu'ajouter ton militantisme pour cette fonction; soit
google existe en complément mais si l'échanges d'avis et d'expériences
passent par le seul échange de liens google on y perdra un peu et pas
qu'en bonne foi.
Si tu veux vraiment un resume rapide, strncpy n'est pas efficace [...]
assurément.
strcpy_s n'est pas super-bien foutue en cas de debordement. En particulier,
tu ne sais pas vraiment de combien tu debordes.
en général on s'en tape, si on n'a calculé les tailles avant la copie
c'est que cela "devait suffire", un flag "échec" est alors suffisant
pour trapper et recommencer avec une autre stratégie.
quand tu en es au 3e programmeur ruse qui se plante dans ses calculs de strcpy,
ou qui utilise strncat de facon incorrecte, tu vois strlcpy et strlcat comme
vachement bien, finalement.
je ne code jamais en russe, et assez peu en C en fait, quand je le
fais j'utilise une struct codant séparement la longueur de la chaîne
(à l'image des SafeStr etc), je me range ici à l'avis de Gabriel
qu'une structure claire et une nouvelle famille de fonctions permettent
(seules?) une utilisation maîtrisée des chaînes (je parle ici d'appl.
dont celles de débutant, pas de code bas niveau qui peuvent exiger
l'emploi de la libc).
Non, non. Apprend a citer correctement deja, c'est pas moi qui ait ecrit ca.
en tout cas, il n'est pas dans Studio qui préfère strcpy_s ...
?!? on ne peut répondre qu'à Marc lorsque l'on poste après Marc ??
citer ce point pour indiquer que Microsoft a introduit des fonctions (que tu commentes plus bas) aussi absentes des standards que strlcpy était pertinent pour illustrer l'état des lieux.
Tutut! 30 secondes de google t'ameneront sans probleme sur toute la doc que tu veux sur strlcpy/strlcat. Faut quand meme pas faire preuve de trop de mauvaise foi.
ce n'était pas mon point - et 5 sec. de google suffisait.
Xavier (oui, non Marc, mais je répondais au fil) suggère strlcpy sans détail (ou le feature invalide un memset sur les octets non utilisés) et tu n'as qu'ajouter ton militantisme pour cette fonction; soit google existe en complément mais si l'échanges d'avis et d'expériences passent par le seul échange de liens google on y perdra un peu et pas qu'en bonne foi.
Si tu veux vraiment un resume rapide, strncpy n'est pas efficace [...]
assurément.
strcpy_s n'est pas super-bien foutue en cas de debordement. En particulier, tu ne sais pas vraiment de combien tu debordes.
en général on s'en tape, si on n'a calculé les tailles avant la copie c'est que cela "devait suffire", un flag "échec" est alors suffisant pour trapper et recommencer avec une autre stratégie.
quand tu en es au 3e programmeur ruse qui se plante dans ses calculs de strcpy, ou qui utilise strncat de facon incorrecte, tu vois strlcpy et strlcat comme vachement bien, finalement.
je ne code jamais en russe, et assez peu en C en fait, quand je le fais j'utilise une struct codant séparement la longueur de la chaîne (à l'image des SafeStr etc), je me range ici à l'avis de Gabriel qu'une structure claire et une nouvelle famille de fonctions permettent (seules?) une utilisation maîtrisée des chaînes (je parle ici d'appl. dont celles de débutant, pas de code bas niveau qui peuvent exiger l'emploi de la libc).
Sylvain.
Gabriel Dos Reis
Richard Delorme writes:
[...]
| Beside, those who are using strcat or variants deserved to be punished.
Je doute que cette méthode soit effective.
(est-elle retroactive ?)
-- Gaby
Richard Delorme <abulmo@nospam.fr> writes:
[...]
| Beside, those who are using strcat or variants deserved to be punished.
Non, non. Apprend a citer correctement deja, c'est pas moi qui ait ecrit ca.
en tout cas, il n'est pas dans Studio qui préfère strcpy_s ...
| ?!? on ne peut répondre qu'à Marc lorsque l'on poste après Marc ??
Je suppose qu'il parle de l'attribution, et non de la citation.
-- Gaby
espie
In article <4a116806$0$17771$, Sylvain SF wrote:
?!? on ne peut répondre qu'à Marc lorsque l'on poste après Marc ??
Bien sur que non, mais ca demande de garder des attributions correctes. (ce que d'ailleur tu n'as pas fait, et donc j'ai zappe tout ce qui n'etait pas attribue). Je rappelle que les news sont un systeme asynchrone, que les messages peuvent arriver dans le desordre. La netiquette demande qu'en general on fasse un minimum d'effort pour garder les noms d'auteur au bon endroit dans les messages cites...
In article <4a116806$0$17771$ba4acef3@news.orange.fr>,
Sylvain SF <sylvain@boiteaspam.info> wrote:
?!? on ne peut répondre qu'à Marc lorsque l'on poste après Marc ??
Bien sur que non, mais ca demande de garder des attributions correctes.
(ce que d'ailleur tu n'as pas fait, et donc j'ai zappe tout ce qui n'etait
pas attribue). Je rappelle que les news sont un systeme asynchrone, que les
messages peuvent arriver dans le desordre. La netiquette demande qu'en general
on fasse un minimum d'effort pour garder les noms d'auteur au bon endroit
dans les messages cites...
?!? on ne peut répondre qu'à Marc lorsque l'on poste après Marc ??
Bien sur que non, mais ca demande de garder des attributions correctes. (ce que d'ailleur tu n'as pas fait, et donc j'ai zappe tout ce qui n'etait pas attribue). Je rappelle que les news sont un systeme asynchrone, que les messages peuvent arriver dans le desordre. La netiquette demande qu'en general on fasse un minimum d'effort pour garder les noms d'auteur au bon endroit dans les messages cites...
Manuel Pégourié-Gonnard
Xavier Roche scripsit:
C'est un conseil idiot, à mon humble avis. Au lieu de provoquer un débordement sur strcpy(), on crée une chaine non terminée, qui vous explosera à la figure de manière aléatoire, bien plus tard. Autant avoir un crash direct, débuggable. Bref, strncpy() est une fonction horrible que l'on ne devrait absolument jamais utiliser (c'est vraiment la fonction la plus débile de la libc amha)
Mais strlcpy() est une solution beaucoup plus propre - à réimplémenter au besoin, mais c'est le type de fonction utile.
J'ai gouglé un peu pour me faire une idée sur le débat strbcpy vs srtlcpy qui a suivi, et j'ai trouvé des trucs intéressants qui ont satisfait ma curiosité sur le fond, mais je je crois pas avoir vu d'explication des noms : n, l ?
-- Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
Xavier Roche scripsit:
C'est un conseil idiot, à mon humble avis. Au lieu de provoquer un
débordement sur strcpy(), on crée une chaine non terminée, qui vous
explosera à la figure de manière aléatoire, bien plus tard. Autant avoir
un crash direct, débuggable. Bref, strncpy() est une fonction horrible
que l'on ne devrait absolument jamais utiliser (c'est vraiment la
fonction la plus débile de la libc amha)
Mais strlcpy() est une solution beaucoup plus propre - à réimplémenter
au besoin, mais c'est le type de fonction utile.
J'ai gouglé un peu pour me faire une idée sur le débat strbcpy vs
srtlcpy qui a suivi, et j'ai trouvé des trucs intéressants qui ont
satisfait ma curiosité sur le fond, mais je je crois pas avoir vu
d'explication des noms : n, l ?
--
Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu
http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
C'est un conseil idiot, à mon humble avis. Au lieu de provoquer un débordement sur strcpy(), on crée une chaine non terminée, qui vous explosera à la figure de manière aléatoire, bien plus tard. Autant avoir un crash direct, débuggable. Bref, strncpy() est une fonction horrible que l'on ne devrait absolument jamais utiliser (c'est vraiment la fonction la plus débile de la libc amha)
Mais strlcpy() est une solution beaucoup plus propre - à réimplémenter au besoin, mais c'est le type de fonction utile.
J'ai gouglé un peu pour me faire une idée sur le débat strbcpy vs srtlcpy qui a suivi, et j'ai trouvé des trucs intéressants qui ont satisfait ma curiosité sur le fond, mais je je crois pas avoir vu d'explication des noms : n, l ?
-- Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
espie
In article <4a112c43$0$17080$, Richard Delorme wrote:
On trouve aussi assez rapidement l'avis de Ulrich Drepper (c'est lui qui interdit l'addition de ces fonctions dans la glibc). Il dit à propos de strlcpy et stlcat :
This is horribly inefficient BSD crap. Using these function only leads to other errors. Correct string handling means that you always know how long your strings are and therefore you can you memcpy (instead of strcpy). Beside, those who are using strcat or variants deserved to be punished.
C'est l'un des points sur lesquels Ulrich Drepper est un sale con.
It hides bugs in programs. If a string is too long for an allocated memory block the copying must not simply silently stop. Instead the program must reallocate or signal an error.
[...]
En quoi tronquer une chaîne n'est pas une erreur ?
D'une part, ca n'est pas toujours une erreur grave. Tu peux etre en train de construire un message de diagnostic pour l'utilisateur, et avoir le message un peu court, ca n'est pas genant (si c'est pour lui dire qu'il n'y a plus assez de ressources, je doute qu'allouer plus de memoire soit une bonne idee par exemple). D'autre part, les consequences d'un debordement de tampon sont bien plus immediates et dangereuses qu'une troncature de chaine.
Idealement, tu fais ton boulot correctement. Idealement, tu peux meme utiliser autre chose que des chaines classiques C. Mais voila. Il y a aussi le monde reel, et un peu de damage control pour les programmes et programmeurs existants ne fait pas de mal... et dans ce contexte, strlcpy est tres utile.
Elle permet entre autres, quand tu fais de l'audit de code, de reparer vite fait l'essentiel des enormes problemes d'un code C cochonne par d'autres que tu n'as pas le temps de reecrire en totalite...
In article <4a112c43$0$17080$ba4acef3@news.orange.fr>,
Richard Delorme <abulmo@nospam.fr> wrote:
On trouve aussi assez rapidement l'avis de Ulrich Drepper (c'est lui qui
interdit l'addition de ces fonctions dans la glibc). Il dit à propos
de strlcpy et stlcat :
This is horribly inefficient BSD crap. Using these function only
leads to other errors. Correct string handling means that you always
know how long your strings are and therefore you can you memcpy
(instead of strcpy).
Beside, those who are using strcat or variants deserved to be punished.
C'est l'un des points sur lesquels Ulrich Drepper est un sale con.
It hides bugs in programs. If a string is
too long for an allocated memory block the copying must not simply
silently stop. Instead the program must reallocate or signal an
error.
[...]
En quoi tronquer une chaîne n'est pas une erreur ?
D'une part, ca n'est pas toujours une erreur grave. Tu peux etre en train
de construire un message de diagnostic pour l'utilisateur, et avoir le message
un peu court, ca n'est pas genant (si c'est pour lui dire qu'il n'y a plus
assez de ressources, je doute qu'allouer plus de memoire soit une bonne
idee par exemple). D'autre part, les consequences d'un debordement de tampon
sont bien plus immediates et dangereuses qu'une troncature de chaine.
Idealement, tu fais ton boulot correctement. Idealement, tu peux meme utiliser
autre chose que des chaines classiques C. Mais voila. Il y a aussi le monde
reel, et un peu de damage control pour les programmes et programmeurs existants
ne fait pas de mal... et dans ce contexte, strlcpy est tres utile.
Elle permet entre autres, quand tu fais de l'audit de code, de reparer vite
fait l'essentiel des enormes problemes d'un code C cochonne par d'autres
que tu n'as pas le temps de reecrire en totalite...
In article <4a112c43$0$17080$, Richard Delorme wrote:
On trouve aussi assez rapidement l'avis de Ulrich Drepper (c'est lui qui interdit l'addition de ces fonctions dans la glibc). Il dit à propos de strlcpy et stlcat :
This is horribly inefficient BSD crap. Using these function only leads to other errors. Correct string handling means that you always know how long your strings are and therefore you can you memcpy (instead of strcpy). Beside, those who are using strcat or variants deserved to be punished.
C'est l'un des points sur lesquels Ulrich Drepper est un sale con.
It hides bugs in programs. If a string is too long for an allocated memory block the copying must not simply silently stop. Instead the program must reallocate or signal an error.
[...]
En quoi tronquer une chaîne n'est pas une erreur ?
D'une part, ca n'est pas toujours une erreur grave. Tu peux etre en train de construire un message de diagnostic pour l'utilisateur, et avoir le message un peu court, ca n'est pas genant (si c'est pour lui dire qu'il n'y a plus assez de ressources, je doute qu'allouer plus de memoire soit une bonne idee par exemple). D'autre part, les consequences d'un debordement de tampon sont bien plus immediates et dangereuses qu'une troncature de chaine.
Idealement, tu fais ton boulot correctement. Idealement, tu peux meme utiliser autre chose que des chaines classiques C. Mais voila. Il y a aussi le monde reel, et un peu de damage control pour les programmes et programmeurs existants ne fait pas de mal... et dans ce contexte, strlcpy est tres utile.
Elle permet entre autres, quand tu fais de l'audit de code, de reparer vite fait l'essentiel des enormes problemes d'un code C cochonne par d'autres que tu n'as pas le temps de reecrire en totalite...
espie
In article , Manuel Pégourié-Gonnard <mpg+ wrote:
J'ai gouglé un peu pour me faire une idée sur le débat strbcpy vs srtlcpy qui a suivi, et j'ai trouvé des trucs intéressants qui ont satisfait ma curiosité sur le fond, mais je je crois pas avoir vu d'explication des noms : n, l ?
l pour length, je crois.
Pour le n, il y a plein de fonctions comme strncmp qui prennent un argument de taille n.
Historiquement, strncpy et strncat ont un but bien precis: remplir des structures de taille fixe, qui contiennent un tableau de caracteres de taille fixe. Ce tableau peut etre fini par un zero, ou pas. strncpy met plein de zeros au bout pour etre sur qu'on a bien vire tout ce qui pouvait trainer comme restes dans le tableau...
Bref, strncpy et strncat sont la pour gerer l'utmp, les entetes d'archives de ar, et pas grand chose d'autre. Dans ce contexte, elles sont parfaitement appropriees, et font exactement ce qu'il faut.
Dans tout autre contexte, en particulier pour essayer de securiser des chaines C classiques, bof, bof, bof.
In article <20090518154121.25158.87025.XPN@roth.elzevir.fr>,
Manuel Pégourié-Gonnard <mpg+news@elzevir.fr> wrote:
J'ai gouglé un peu pour me faire une idée sur le débat strbcpy vs
srtlcpy qui a suivi, et j'ai trouvé des trucs intéressants qui ont
satisfait ma curiosité sur le fond, mais je je crois pas avoir vu
d'explication des noms : n, l ?
l pour length, je crois.
Pour le n, il y a plein de fonctions comme strncmp qui prennent un
argument de taille n.
Historiquement, strncpy et strncat ont un but bien precis: remplir des
structures de taille fixe, qui contiennent un tableau de caracteres de
taille fixe. Ce tableau peut etre fini par un zero, ou pas.
strncpy met plein de zeros au bout pour etre sur qu'on a bien vire tout
ce qui pouvait trainer comme restes dans le tableau...
Bref, strncpy et strncat sont la pour gerer l'utmp, les entetes d'archives
de ar, et pas grand chose d'autre. Dans ce contexte, elles sont parfaitement
appropriees, et font exactement ce qu'il faut.
Dans tout autre contexte, en particulier pour essayer de securiser des chaines
C classiques, bof, bof, bof.
J'ai gouglé un peu pour me faire une idée sur le débat strbcpy vs srtlcpy qui a suivi, et j'ai trouvé des trucs intéressants qui ont satisfait ma curiosité sur le fond, mais je je crois pas avoir vu d'explication des noms : n, l ?
l pour length, je crois.
Pour le n, il y a plein de fonctions comme strncmp qui prennent un argument de taille n.
Historiquement, strncpy et strncat ont un but bien precis: remplir des structures de taille fixe, qui contiennent un tableau de caracteres de taille fixe. Ce tableau peut etre fini par un zero, ou pas. strncpy met plein de zeros au bout pour etre sur qu'on a bien vire tout ce qui pouvait trainer comme restes dans le tableau...
Bref, strncpy et strncat sont la pour gerer l'utmp, les entetes d'archives de ar, et pas grand chose d'autre. Dans ce contexte, elles sont parfaitement appropriees, et font exactement ce qu'il faut.
Dans tout autre contexte, en particulier pour essayer de securiser des chaines C classiques, bof, bof, bof.
JKB
Le 18-05-2009, ? propos de Re: passer une chaîne d'un char [] à un autre char [], Marc Espie ?crivait dans fr.comp.lang.c :
In article <4a112c43$0$17080$, Richard Delorme wrote:
On trouve aussi assez rapidement l'avis de Ulrich Drepper (c'est lui qui interdit l'addition de ces fonctions dans la glibc). Il dit à propos de strlcpy et stlcat :
This is horribly inefficient BSD crap. Using these function only leads to other errors. Correct string handling means that you always know how long your strings are and therefore you can you memcpy (instead of strcpy). Beside, those who are using strcat or variants deserved to be punished.
C'est l'un des points sur lesquels Ulrich Drepper est un sale con.
Le problème, c'est que c'est l'un _des_ points où ce type est un sale con, mais pas le seul ! Il est nocif et on devrait l'empêcher une bonne fois pour toute de nuire...
JKB
Le 18-05-2009, ? propos de
Re: passer une chaîne d'un char [] à un autre char [],
Marc Espie ?crivait dans fr.comp.lang.c :
In article <4a112c43$0$17080$ba4acef3@news.orange.fr>,
Richard Delorme <abulmo@nospam.fr> wrote:
On trouve aussi assez rapidement l'avis de Ulrich Drepper (c'est lui qui
interdit l'addition de ces fonctions dans la glibc). Il dit à propos
de strlcpy et stlcat :
This is horribly inefficient BSD crap. Using these function only
leads to other errors. Correct string handling means that you always
know how long your strings are and therefore you can you memcpy
(instead of strcpy).
Beside, those who are using strcat or variants deserved to be punished.
C'est l'un des points sur lesquels Ulrich Drepper est un sale con.
Le problème, c'est que c'est l'un _des_ points où ce type est un
sale con, mais pas le seul ! Il est nocif et on devrait l'empêcher une
bonne fois pour toute de nuire...
Le 18-05-2009, ? propos de Re: passer une chaîne d'un char [] à un autre char [], Marc Espie ?crivait dans fr.comp.lang.c :
In article <4a112c43$0$17080$, Richard Delorme wrote:
On trouve aussi assez rapidement l'avis de Ulrich Drepper (c'est lui qui interdit l'addition de ces fonctions dans la glibc). Il dit à propos de strlcpy et stlcat :
This is horribly inefficient BSD crap. Using these function only leads to other errors. Correct string handling means that you always know how long your strings are and therefore you can you memcpy (instead of strcpy). Beside, those who are using strcat or variants deserved to be punished.
C'est l'un des points sur lesquels Ulrich Drepper est un sale con.
Le problème, c'est que c'est l'un _des_ points où ce type est un sale con, mais pas le seul ! Il est nocif et on devrait l'empêcher une bonne fois pour toute de nuire...
JKB
Antoine Leca
Le 18/05/2009 05:35Z, Gabriel Dos Regis écrivit :
Marc Espie writes:
| quand tu en es au 3e programmeur ruse qui se plante dans ses calculs de strcpy, | ou qui utilise strncat de facon incorrecte, tu vois strlcpy et strlcat comme | vachement bien, finalement.
Peut-être que ce qu'il faut c'est un vrai type de données « string » au lieu de cette notion floue de pointeur vers un « char » qu'on avance jusqu'à ce qu'on tombe sur zéro ?
Mmmm... La seule chose, c'est que si tu supprimes les pointeurs (parce que c'est dangereux), les char* (parce que c'est flou) et aussi malloc (parce que cela peut rater, ou parce qu'il faut s'occuper de libérer, cela donne trop de boulot), tu peux probablement arrêter de faire du C et passer tout de go à n'importe lequel de ces langages « bien faits », qui incorpore ramasse-miettes, type String et références...
... pour t'apercevoir que le résultat n'est plus aussi portable.
strlcpy est une rustine, qui permet à peu de frais de continuer à faire du C, et donc de capitaliser sur l'existant : ce n'est peut-être pas la panacée ou la voie du futur, mais franchement, je ne suis pas sûr que C soit sur cette voie.
A contrario, il me semble que *_s() (les fonctions « de sûreté », qui semblent être une partie importante de C1X) soient plutôt un emplâtre, dont je ne suis pas sûr qu'il prenne.
Antoine
Le 18/05/2009 05:35Z, Gabriel Dos Regis écrivit :
Marc Espie writes:
| quand tu en es au 3e programmeur ruse qui se plante dans ses calculs de strcpy,
| ou qui utilise strncat de facon incorrecte, tu vois strlcpy et strlcat comme
| vachement bien, finalement.
Peut-être que ce qu'il faut c'est un vrai type de données « string » au
lieu de cette notion floue de pointeur vers un « char » qu'on avance jusqu'à
ce qu'on tombe sur zéro ?
Mmmm... La seule chose, c'est que si tu supprimes les pointeurs (parce
que c'est dangereux), les char* (parce que c'est flou) et aussi malloc
(parce que cela peut rater, ou parce qu'il faut s'occuper de libérer,
cela donne trop de boulot), tu peux probablement arrêter de faire du C
et passer tout de go à n'importe lequel de ces langages « bien faits »,
qui incorpore ramasse-miettes, type String et références...
... pour t'apercevoir que le résultat n'est plus aussi portable.
strlcpy est une rustine, qui permet à peu de frais de continuer à faire
du C, et donc de capitaliser sur l'existant : ce n'est peut-être pas la
panacée ou la voie du futur, mais franchement, je ne suis pas sûr que C
soit sur cette voie.
A contrario, il me semble que *_s() (les fonctions « de sûreté », qui
semblent être une partie importante de C1X) soient plutôt un emplâtre,
dont je ne suis pas sûr qu'il prenne.
| quand tu en es au 3e programmeur ruse qui se plante dans ses calculs de strcpy, | ou qui utilise strncat de facon incorrecte, tu vois strlcpy et strlcat comme | vachement bien, finalement.
Peut-être que ce qu'il faut c'est un vrai type de données « string » au lieu de cette notion floue de pointeur vers un « char » qu'on avance jusqu'à ce qu'on tombe sur zéro ?
Mmmm... La seule chose, c'est que si tu supprimes les pointeurs (parce que c'est dangereux), les char* (parce que c'est flou) et aussi malloc (parce que cela peut rater, ou parce qu'il faut s'occuper de libérer, cela donne trop de boulot), tu peux probablement arrêter de faire du C et passer tout de go à n'importe lequel de ces langages « bien faits », qui incorpore ramasse-miettes, type String et références...
... pour t'apercevoir que le résultat n'est plus aussi portable.
strlcpy est une rustine, qui permet à peu de frais de continuer à faire du C, et donc de capitaliser sur l'existant : ce n'est peut-être pas la panacée ou la voie du futur, mais franchement, je ne suis pas sûr que C soit sur cette voie.
A contrario, il me semble que *_s() (les fonctions « de sûreté », qui semblent être une partie importante de C1X) soient plutôt un emplâtre, dont je ne suis pas sûr qu'il prenne.
Antoine
Sylvain SF
Marc Espie a écrit :
ca demande de garder des attributions correctes.
hors sujet, inintéressant et idiot, l'important n'est pas [*] qui a dit quoi mais plutôt quels arguments sont proposés; non Gabriel je n'attribue pas à Marc en laissant son nom, je cite seulement la dernière intervention; comprendre autre chose est se fixer sur des détails nombrilistes sans intérêt.
[*] hors argumentaire dont on citerait auteur et contexte.
ce que d'ailleur tu n'as pas fait, et donc j'ai zappe tout ce qui n'etait pas attribue. []
tu couines quand on laisse ton nom, tu zappes quand on l'enlève ?! puérile attitude.
SF.
Marc Espie a écrit :
ca demande de garder des attributions correctes.
hors sujet, inintéressant et idiot, l'important n'est pas [*] qui
a dit quoi mais plutôt quels arguments sont proposés; non Gabriel
je n'attribue pas à Marc en laissant son nom, je cite seulement
la dernière intervention; comprendre autre chose est se fixer sur
des détails nombrilistes sans intérêt.
[*] hors argumentaire dont on citerait auteur et contexte.
ce que d'ailleur tu n'as pas fait, et donc j'ai zappe tout ce qui
n'etait pas attribue. []
tu couines quand on laisse ton nom, tu zappes quand on l'enlève ?!
puérile attitude.
hors sujet, inintéressant et idiot, l'important n'est pas [*] qui a dit quoi mais plutôt quels arguments sont proposés; non Gabriel je n'attribue pas à Marc en laissant son nom, je cite seulement la dernière intervention; comprendre autre chose est se fixer sur des détails nombrilistes sans intérêt.
[*] hors argumentaire dont on citerait auteur et contexte.
ce que d'ailleur tu n'as pas fait, et donc j'ai zappe tout ce qui n'etait pas attribue. []
tu couines quand on laisse ton nom, tu zappes quand on l'enlève ?! puérile attitude.
