Cela est sans doute quelque chose de très facile, mais que je ne sais pas
faire (en cherchant je n'ai trouvé que des fonctions non ANSI-C :
itoa et ltoa sur DOS par exemple).
Cela est sans doute quelque chose de très facile, mais que je ne sais pas faire (en cherchant je n'ai trouvé que des fonctions non ANSI-C : itoa et ltoa sur DOS par exemple). sprintf(), peut-être ?
-- Pierre
Helfer Thomas <helferthomas@free.fr> a écrit:
Bonjour,
Cela est sans doute quelque chose de très facile, mais que je ne sais pas
faire (en cherchant je n'ai trouvé que des fonctions non ANSI-C :
itoa et ltoa sur DOS par exemple).
sprintf(), peut-être ?
Cela est sans doute quelque chose de très facile, mais que je ne sais pas faire (en cherchant je n'ai trouvé que des fonctions non ANSI-C : itoa et ltoa sur DOS par exemple). sprintf(), peut-être ?
-- Pierre
Helfer Thomas
Le Sun, 26 Sep 2004 11:12:55 +0200, Pierre Maurette a écrit :
Helfer Thomas a écrit:
Bonjour,
Cela est sans doute quelque chose de très facile, mais que je ne sais pas faire (en cherchant je n'ai trouvé que des fonctions non ANSI-C : itoa et ltoa sur DOS par exemple). sprintf(), peut-être ?
Oui, il y a sprintf(), mais cette solution suppose que l'on connaisse à l'avance la taille de la chaine de caractères qui contiendra mon double. J'espérai en fin une solution plus "propre" :)
Le Sun, 26 Sep 2004 11:12:55 +0200, Pierre Maurette a écrit :
Helfer Thomas <helferthomas@free.fr> a écrit:
Bonjour,
Cela est sans doute quelque chose de très facile, mais que je ne sais pas
faire (en cherchant je n'ai trouvé que des fonctions non ANSI-C :
itoa et ltoa sur DOS par exemple).
sprintf(), peut-être ?
Oui, il y a sprintf(), mais cette solution suppose que l'on connaisse à
l'avance la taille de la chaine de caractères qui contiendra mon double.
J'espérai en fin une solution plus "propre" :)
Le Sun, 26 Sep 2004 11:12:55 +0200, Pierre Maurette a écrit :
Helfer Thomas a écrit:
Bonjour,
Cela est sans doute quelque chose de très facile, mais que je ne sais pas faire (en cherchant je n'ai trouvé que des fonctions non ANSI-C : itoa et ltoa sur DOS par exemple). sprintf(), peut-être ?
Oui, il y a sprintf(), mais cette solution suppose que l'on connaisse à l'avance la taille de la chaine de caractères qui contiendra mon double. J'espérai en fin une solution plus "propre" :)
Jean-Marc
"Helfer Thomas" a écrit dans le message de news:
Helfer Thomas a écrit:
Bonjour,
Cela est sans doute quelque chose de très facile, mais que je ne sais pas
faire (en cherchant je n'ai trouvé que des fonctions non ANSI-C : itoa et ltoa sur DOS par exemple). sprintf(), peut-être ?
Oui, il y a sprintf(), mais cette solution suppose que l'on connaisse à l'avance la taille de la chaine de caractères qui contiendra mon double. J'espérai en fin une solution plus "propre" :)
Hello,
c'est la façon "propre" et standard de faire. Tu dois juste dimensionner un buffer assez grand pour stocker le résultat. C'est d'autant plus facile qu'avec sprintf tu peux spécifier le format de sortie.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
"Helfer Thomas" <helferthomas@free.fr> a écrit dans le message de
news:pan.2004.09.26.09.35.21.596436@free.fr...
Helfer Thomas <helferthomas@free.fr> a écrit:
Bonjour,
Cela est sans doute quelque chose de très facile, mais que je ne sais
pas
faire (en cherchant je n'ai trouvé que des fonctions non ANSI-C :
itoa et ltoa sur DOS par exemple).
sprintf(), peut-être ?
Oui, il y a sprintf(), mais cette solution suppose que l'on connaisse à
l'avance la taille de la chaine de caractères qui contiendra mon double.
J'espérai en fin une solution plus "propre" :)
Hello,
c'est la façon "propre" et standard de faire.
Tu dois juste dimensionner un buffer assez grand pour
stocker le résultat. C'est d'autant plus facile qu'avec sprintf
tu peux spécifier le format de sortie.
--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
Cela est sans doute quelque chose de très facile, mais que je ne sais pas
faire (en cherchant je n'ai trouvé que des fonctions non ANSI-C : itoa et ltoa sur DOS par exemple). sprintf(), peut-être ?
Oui, il y a sprintf(), mais cette solution suppose que l'on connaisse à l'avance la taille de la chaine de caractères qui contiendra mon double. J'espérai en fin une solution plus "propre" :)
Hello,
c'est la façon "propre" et standard de faire. Tu dois juste dimensionner un buffer assez grand pour stocker le résultat. C'est d'autant plus facile qu'avec sprintf tu peux spécifier le format de sortie.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
Erwann ABALEA
On Sun, 26 Sep 2004, Helfer Thomas wrote:
[...]
Oui, il y a sprintf(), mais cette solution suppose que l'on connaisse à l'avance la taille de la chaine de caractères qui contiendra mon double. J'espérai en fin une solution plus "propre" :)
Si tu as un compilateur C99, tu as alors snprintf(), qui te permet de connaître la taille de la chaîne à allouer, au prix d'un appel supplémentaire à snprintf. Tu fais donc 2 appels: un premier pour avoir la taille, et un deuxième pour effectuer la transformation et obtenir le résultat.
Attention aux différentes implémentations de snprintf, certaines n'autorisent pas une taille nulle, certaines n'autorisent pas un pointeur destination nul, ...
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Malheureusement c'est dur, a force de découper les points godwin que je gagne, de lire quoi que ce soit sur mon écran. -+- JC in GNU : couper (au burin) - coller (à la glue) -+-
On Sun, 26 Sep 2004, Helfer Thomas wrote:
[...]
Oui, il y a sprintf(), mais cette solution suppose que l'on connaisse à
l'avance la taille de la chaine de caractères qui contiendra mon double.
J'espérai en fin une solution plus "propre" :)
Si tu as un compilateur C99, tu as alors snprintf(), qui te permet de
connaître la taille de la chaîne à allouer, au prix d'un appel
supplémentaire à snprintf. Tu fais donc 2 appels: un premier pour avoir la
taille, et un deuxième pour effectuer la transformation et obtenir le
résultat.
Attention aux différentes implémentations de snprintf, certaines
n'autorisent pas une taille nulle, certaines n'autorisent pas un pointeur
destination nul, ...
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Malheureusement c'est dur, a force de découper les points godwin que
je gagne, de lire quoi que ce soit sur mon écran.
-+- JC in GNU : couper (au burin) - coller (à la glue) -+-
Oui, il y a sprintf(), mais cette solution suppose que l'on connaisse à l'avance la taille de la chaine de caractères qui contiendra mon double. J'espérai en fin une solution plus "propre" :)
Si tu as un compilateur C99, tu as alors snprintf(), qui te permet de connaître la taille de la chaîne à allouer, au prix d'un appel supplémentaire à snprintf. Tu fais donc 2 appels: un premier pour avoir la taille, et un deuxième pour effectuer la transformation et obtenir le résultat.
Attention aux différentes implémentations de snprintf, certaines n'autorisent pas une taille nulle, certaines n'autorisent pas un pointeur destination nul, ...
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Malheureusement c'est dur, a force de découper les points godwin que je gagne, de lire quoi que ce soit sur mon écran. -+- JC in GNU : couper (au burin) - coller (à la glue) -+-
Vincent Lefevre
Dans l'article , Erwann ABALEA écrit:
Si tu as un compilateur C99, tu as alors snprintf(), qui te permet de connaître la taille de la chaîne à allouer, au prix d'un appel supplémentaire à snprintf. Tu fais donc 2 appels: un premier pour avoir la taille, et un deuxième pour effectuer la transformation et obtenir le résultat.
Question efficacité, il est préférable de faire un sprintf dans un buffer trop grand, puis de faire une copie, non?
Dans l'article <Pine.LNX.4.58.0409261251330.28102@shining.seclogd.org>,
Erwann ABALEA <erwann@abalea.com> écrit:
Si tu as un compilateur C99, tu as alors snprintf(), qui te permet
de connaître la taille de la chaîne à allouer, au prix d'un appel
supplémentaire à snprintf. Tu fais donc 2 appels: un premier pour
avoir la taille, et un deuxième pour effectuer la transformation et
obtenir le résultat.
Question efficacité, il est préférable de faire un sprintf dans un
buffer trop grand, puis de faire une copie, non?
Si tu as un compilateur C99, tu as alors snprintf(), qui te permet de connaître la taille de la chaîne à allouer, au prix d'un appel supplémentaire à snprintf. Tu fais donc 2 appels: un premier pour avoir la taille, et un deuxième pour effectuer la transformation et obtenir le résultat.
Question efficacité, il est préférable de faire un sprintf dans un buffer trop grand, puis de faire une copie, non?
Si tu as un compilateur C99, tu as alors snprintf(), qui te permet de connaître la taille de la chaîne à allouer, au prix d'un appel supplémentaire à snprintf. Tu fais donc 2 appels: un premier pour avoir la taille, et un deuxième pour effectuer la transformation et obtenir le résultat.
Question efficacité, il est préférable de faire un sprintf dans un buffer trop grand, puis de faire une copie, non?
Si tu es certain que ton buffer est trop grand, c'est une solution moins coûteuse, en effet.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Ma femme a appris sur une 400 four que je revends également si ça t'intéresse. C'est pas trop puissant et tu as une position bien droite. Même elle qui est couillonne comme pas deux s'est bien amusée deçu. -+- OW in http://neuneu.mine.nu : Gai gai, marions nous -+-
On Sun, 26 Sep 2004, Vincent Lefevre wrote:
Dans l'article <Pine.LNX.4.58.0409261251330.28102@shining.seclogd.org>,
Erwann ABALEA <erwann@abalea.com> écrit:
Si tu as un compilateur C99, tu as alors snprintf(), qui te permet
de connaître la taille de la chaîne à allouer, au prix d'un appel
supplémentaire à snprintf. Tu fais donc 2 appels: un premier pour
avoir la taille, et un deuxième pour effectuer la transformation et
obtenir le résultat.
Question efficacité, il est préférable de faire un sprintf dans un
buffer trop grand, puis de faire une copie, non?
Si tu es certain que ton buffer est trop grand, c'est une solution moins
coûteuse, en effet.
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Ma femme a appris sur une 400 four que je revends également si ça
t'intéresse. C'est pas trop puissant et tu as une position bien droite.
Même elle qui est couillonne comme pas deux s'est bien amusée deçu.
-+- OW in http://neuneu.mine.nu : Gai gai, marions nous -+-
Si tu as un compilateur C99, tu as alors snprintf(), qui te permet de connaître la taille de la chaîne à allouer, au prix d'un appel supplémentaire à snprintf. Tu fais donc 2 appels: un premier pour avoir la taille, et un deuxième pour effectuer la transformation et obtenir le résultat.
Question efficacité, il est préférable de faire un sprintf dans un buffer trop grand, puis de faire une copie, non?
Si tu es certain que ton buffer est trop grand, c'est une solution moins coûteuse, en effet.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Ma femme a appris sur une 400 four que je revends également si ça t'intéresse. C'est pas trop puissant et tu as une position bien droite. Même elle qui est couillonne comme pas deux s'est bien amusée deçu. -+- OW in http://neuneu.mine.nu : Gai gai, marions nous -+-
Antoine Leca
En , Helfer Thomas va escriure:
Oui, il y a sprintf(), mais cette solution suppose que l'on connaisse à l'avance la taille de la chaine de caractères qui contiendra mon double. J'espérai en fin une solution plus "propre" :)
Je ne comprends pas ton problème.
En C, les chaînes de caractères ne se créent pas par magie, il faut les allouer avant de faire appel aux fonctions de bibliothèque. C'est vrai pour s*printf comme pour itoa.
Si tu veux dimensioner correctement la chaîne de caractères, tu peux le faire avec les éléments du format, en particulier la précision; attention seulement aux exposants, qui peuvent facilement provoquer des débordements suite à des erreurs de calcul, surtout si les calculs ne sont pas contrôlés par ailleurs; c'est particulièrement vrai pour les formats %f, évidemment.
Antoine
En pan.2004.09.26.09.35.21.596436@free.fr, Helfer Thomas va escriure:
Oui, il y a sprintf(), mais cette solution suppose que l'on connaisse
à l'avance la taille de la chaine de caractères qui contiendra mon
double. J'espérai en fin une solution plus "propre" :)
Je ne comprends pas ton problème.
En C, les chaînes de caractères ne se créent pas par magie, il faut les
allouer avant de faire appel aux fonctions de bibliothèque. C'est vrai pour
s*printf comme pour itoa.
Si tu veux dimensioner correctement la chaîne de caractères, tu peux le
faire avec les éléments du format, en particulier la précision; attention
seulement aux exposants, qui peuvent facilement provoquer des débordements
suite à des erreurs de calcul, surtout si les calculs ne sont pas contrôlés
par ailleurs; c'est particulièrement vrai pour les formats %f, évidemment.
Oui, il y a sprintf(), mais cette solution suppose que l'on connaisse à l'avance la taille de la chaine de caractères qui contiendra mon double. J'espérai en fin une solution plus "propre" :)
Je ne comprends pas ton problème.
En C, les chaînes de caractères ne se créent pas par magie, il faut les allouer avant de faire appel aux fonctions de bibliothèque. C'est vrai pour s*printf comme pour itoa.
Si tu veux dimensioner correctement la chaîne de caractères, tu peux le faire avec les éléments du format, en particulier la précision; attention seulement aux exposants, qui peuvent facilement provoquer des débordements suite à des erreurs de calcul, surtout si les calculs ne sont pas contrôlés par ailleurs; c'est particulièrement vrai pour les formats %f, évidemment.
Antoine
Antoine Leca
En 20040926183307$, Vincent Lefevre va escriure:
Erwann ABALEA écrit:
Si tu as un compilateur C99, tu as alors snprintf(),
Pas un problème de compilateur. Suffit d'une bibliothèque standard compatible C99. Par exemple, glibc depuis des années.
Question efficacité, il est préférable de faire un sprintf dans un buffer trop grand, puis de faire une copie, non?
Question sûreté (débordements de tampons), vaut mieux utiliser snprintf, non?
Ce n'est pas tant pour aller dans le sens des ayatollahs qui veulent interdire purement et simplement l'utilisation de fonctions comme sprintf, que parce que avec les deux appels à snprintf, l'intention est claire, il n'y a pas de doutes à avoir et donc le petit malin qui passe derrière toi pour « optimiser » ton code ne va pas se permettre de remplacer ton tampon « trop grand » par un tampon qui va se réveler « trop juste », et envoyer ta superbe fusée au fin fond de l'Atlantique ou ailleurs...
D'autre part, si tu as le choix d'utiliser snprintf, tu as la ressource d'utiliser snprintf avec comme paramètre la taille de ton tampon « calculé juste » (autrement dit, l'utilisation naturelle de snprintf), qui est aussi efficace sinon plus que sprintf.
Par ailleurs, pour revenir au cas présent, je ne sais pas ce que veut exactement le questionneur initial, mais peut-être veut-il une allocation dynamique du résultat. Et à ce moment-là, les questions de performances de s*printf doivent être comparées à celles du malloc, + l'éventuel realloc si on choisit l'allocation a priori et que l'on veut économiser la mémoire...
Antoine
En 20040926183307$54c3@vinc17.org, Vincent Lefevre va escriure:
Erwann ABALEA écrit:
Si tu as un compilateur C99, tu as alors snprintf(),
Pas un problème de compilateur. Suffit d'une bibliothèque standard
compatible C99. Par exemple, glibc depuis des années.
Question efficacité, il est préférable de faire un sprintf dans un
buffer trop grand, puis de faire une copie, non?
Question sûreté (débordements de tampons), vaut mieux utiliser snprintf,
non?
Ce n'est pas tant pour aller dans le sens des ayatollahs qui veulent
interdire purement et simplement l'utilisation de fonctions comme sprintf,
que parce que avec les deux appels à snprintf, l'intention est claire, il
n'y a pas de doutes à avoir et donc le petit malin qui passe derrière toi
pour « optimiser » ton code ne va pas se permettre de remplacer ton tampon
« trop grand » par un tampon qui va se réveler « trop juste », et envoyer ta
superbe fusée au fin fond de l'Atlantique ou ailleurs...
D'autre part, si tu as le choix d'utiliser snprintf, tu as la ressource
d'utiliser snprintf avec comme paramètre la taille de ton tampon « calculé
juste » (autrement dit, l'utilisation naturelle de snprintf), qui est aussi
efficace sinon plus que sprintf.
Par ailleurs, pour revenir au cas présent, je ne sais pas ce que veut
exactement le questionneur initial, mais peut-être veut-il une allocation
dynamique du résultat. Et à ce moment-là, les questions de performances de
s*printf doivent être comparées à celles du malloc, + l'éventuel realloc si
on choisit l'allocation a priori et que l'on veut économiser la mémoire...
Si tu as un compilateur C99, tu as alors snprintf(),
Pas un problème de compilateur. Suffit d'une bibliothèque standard compatible C99. Par exemple, glibc depuis des années.
Question efficacité, il est préférable de faire un sprintf dans un buffer trop grand, puis de faire une copie, non?
Question sûreté (débordements de tampons), vaut mieux utiliser snprintf, non?
Ce n'est pas tant pour aller dans le sens des ayatollahs qui veulent interdire purement et simplement l'utilisation de fonctions comme sprintf, que parce que avec les deux appels à snprintf, l'intention est claire, il n'y a pas de doutes à avoir et donc le petit malin qui passe derrière toi pour « optimiser » ton code ne va pas se permettre de remplacer ton tampon « trop grand » par un tampon qui va se réveler « trop juste », et envoyer ta superbe fusée au fin fond de l'Atlantique ou ailleurs...
D'autre part, si tu as le choix d'utiliser snprintf, tu as la ressource d'utiliser snprintf avec comme paramètre la taille de ton tampon « calculé juste » (autrement dit, l'utilisation naturelle de snprintf), qui est aussi efficace sinon plus que sprintf.
Par ailleurs, pour revenir au cas présent, je ne sais pas ce que veut exactement le questionneur initial, mais peut-être veut-il une allocation dynamique du résultat. Et à ce moment-là, les questions de performances de s*printf doivent être comparées à celles du malloc, + l'éventuel realloc si on choisit l'allocation a priori et que l'on veut économiser la mémoire...
Antoine
Erwann ABALEA
On Mon, 27 Sep 2004, Antoine Leca wrote:
En 20040926183307$, Vincent Lefevre va escriure:
Erwann ABALEA écrit:
Si tu as un compilateur C99, tu as alors snprintf(),
Pas un problème de compilateur. Suffit d'une bibliothèque standard compatible C99. Par exemple, glibc depuis des années.
Ma gueule. C'est exact, je m'en sers depuis plus longtemps que l'installation de mon gcc 3.x.
[...]
Par ailleurs, pour revenir au cas présent, je ne sais pas ce que veut exactement le questionneur initial, mais peut-être veut-il une allocation dynamique du résultat. Et à ce moment-là, les questions de performances de s*printf doivent être comparées à celles du malloc, + l'éventuel realloc si on choisit l'allocation a priori et que l'on veut économiser la mémoire...
Je pense que Vincent comparait un ----- char *buf; int taille; taille=snprintf(NULL, ...); buf=malloc(taille) snprintf(buf, taille, ...); -----
et un ----- char staticbuf[assezgrand]; char *buf; sprintf(staticbuf, ...); buf=strdup(staticbuf); -----
Dans le deuxième cas, pas de realloc, mais il faut être certain que "assezgrand" le soit réellement.
De plus, sans avoir lu le source d'une implémentation classique, je pense que le coût d'un snprintf() devrait être supérieur au coût d'un sprintf(). Quant à comparer le coût d'un snprintf() au coût d'un strdup (qui est une suite strlen, malloc, et strcpy), il faudrait prendre en compte le cas où de la mémoire doit être demandée à l'OS, le cas où la machine n'a pas de MMU, ... Difficile de trancher.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- SJ> Just do it. TM> Traduction ? Bouge toi le cul. -+- RMD in <http://neuneu.mine.nu> : Move your ass -+-
On Mon, 27 Sep 2004, Antoine Leca wrote:
En 20040926183307$54c3@vinc17.org, Vincent Lefevre va escriure:
Erwann ABALEA écrit:
Si tu as un compilateur C99, tu as alors snprintf(),
Pas un problème de compilateur. Suffit d'une bibliothèque standard
compatible C99. Par exemple, glibc depuis des années.
Ma gueule. C'est exact, je m'en sers depuis plus longtemps que
l'installation de mon gcc 3.x.
[...]
Par ailleurs, pour revenir au cas présent, je ne sais pas ce que veut
exactement le questionneur initial, mais peut-être veut-il une allocation
dynamique du résultat. Et à ce moment-là, les questions de performances de
s*printf doivent être comparées à celles du malloc, + l'éventuel realloc si
on choisit l'allocation a priori et que l'on veut économiser la mémoire...
Je pense que Vincent comparait un
-----
char *buf;
int taille;
taille=snprintf(NULL, ...);
buf=malloc(taille)
snprintf(buf, taille, ...);
-----
et un
-----
char staticbuf[assezgrand];
char *buf;
sprintf(staticbuf, ...);
buf=strdup(staticbuf);
-----
Dans le deuxième cas, pas de realloc, mais il faut être certain que
"assezgrand" le soit réellement.
De plus, sans avoir lu le source d'une implémentation classique, je pense
que le coût d'un snprintf() devrait être supérieur au coût d'un sprintf().
Quant à comparer le coût d'un snprintf() au coût d'un strdup (qui est une
suite strlen, malloc, et strcpy), il faudrait prendre en compte le cas où
de la mémoire doit être demandée à l'OS, le cas où la machine n'a pas de
MMU, ... Difficile de trancher.
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
SJ> Just do it.
TM> Traduction ?
Bouge toi le cul.
-+- RMD in <http://neuneu.mine.nu> : Move your ass -+-
Si tu as un compilateur C99, tu as alors snprintf(),
Pas un problème de compilateur. Suffit d'une bibliothèque standard compatible C99. Par exemple, glibc depuis des années.
Ma gueule. C'est exact, je m'en sers depuis plus longtemps que l'installation de mon gcc 3.x.
[...]
Par ailleurs, pour revenir au cas présent, je ne sais pas ce que veut exactement le questionneur initial, mais peut-être veut-il une allocation dynamique du résultat. Et à ce moment-là, les questions de performances de s*printf doivent être comparées à celles du malloc, + l'éventuel realloc si on choisit l'allocation a priori et que l'on veut économiser la mémoire...
Je pense que Vincent comparait un ----- char *buf; int taille; taille=snprintf(NULL, ...); buf=malloc(taille) snprintf(buf, taille, ...); -----
et un ----- char staticbuf[assezgrand]; char *buf; sprintf(staticbuf, ...); buf=strdup(staticbuf); -----
Dans le deuxième cas, pas de realloc, mais il faut être certain que "assezgrand" le soit réellement.
De plus, sans avoir lu le source d'une implémentation classique, je pense que le coût d'un snprintf() devrait être supérieur au coût d'un sprintf(). Quant à comparer le coût d'un snprintf() au coût d'un strdup (qui est une suite strlen, malloc, et strcpy), il faudrait prendre en compte le cas où de la mémoire doit être demandée à l'OS, le cas où la machine n'a pas de MMU, ... Difficile de trancher.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- SJ> Just do it. TM> Traduction ? Bouge toi le cul. -+- RMD in <http://neuneu.mine.nu> : Move your ass -+-
Vincent Lefevre
Dans l'article <cj8t0n$r3e$, Antoine Leca écrit:
En 20040926183307$, Vincent Lefevre va escriure:
Question efficacité, il est préférable de faire un sprintf dans un buffer trop grand, puis de faire une copie, non?
Question sûreté (débordements de tampons), vaut mieux utiliser snprintf, non?
Rien n'empêche de limiter et vérifier les débordements a priori. Sinon, on peut toujours utiliser snprintf + une copie éventuelle au lieu de 2 snprintf.
Dans l'article <cj8t0n$r3e$2@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.gov> écrit:
En 20040926183307$54c3@vinc17.org, Vincent Lefevre va escriure:
Question efficacité, il est préférable de faire un sprintf dans un
buffer trop grand, puis de faire une copie, non?
Question sûreté (débordements de tampons), vaut mieux utiliser snprintf,
non?
Rien n'empêche de limiter et vérifier les débordements a priori.
Sinon, on peut toujours utiliser snprintf + une copie éventuelle
au lieu de 2 snprintf.
Question efficacité, il est préférable de faire un sprintf dans un buffer trop grand, puis de faire une copie, non?
Question sûreté (débordements de tampons), vaut mieux utiliser snprintf, non?
Rien n'empêche de limiter et vérifier les débordements a priori. Sinon, on peut toujours utiliser snprintf + une copie éventuelle au lieu de 2 snprintf.
