Tu as raison, mais il faut être pragmatique : quand un OP demande comment
utiliser scanf() pour faire un split() de chaines, je ne suis pas de ceux qui
proposent le format %[^:] , je préconise d'utiliser strchr() et d'éviter
scanf().
Où est cette solution qui préconise strchr ?
Celle que j'ai vu, est signé Yves Roman, et n'est pas complètement
satisfaisante : écrit dans la chaine de départ, ne vérifie pas grand
chose, lente (parcours 2 fois la chaine), longue (7 lignes contre 1 pour
le sscanf), etc.
C'est exact
Il faut quand même noter que sscanf parcours systématiquement toute la chaine de
départ au moins une fois, même s'il n'en extrait que le 1er caractère :
Tu as raison, mais il faut être pragmatique : quand un OP demande comment
utiliser scanf() pour faire un split() de chaines, je ne suis pas de ceux qui
proposent le format %[^:] , je préconise d'utiliser strchr() et d'éviter
scanf().
Où est cette solution qui préconise strchr ?
Celle que j'ai vu, est signé Yves Roman, et n'est pas complètement
satisfaisante : écrit dans la chaine de départ, ne vérifie pas grand
chose, lente (parcours 2 fois la chaine), longue (7 lignes contre 1 pour
le sscanf), etc.
C'est exact
Il faut quand même noter que sscanf parcours systématiquement toute la chaine de
départ au moins une fois, même s'il n'en extrait que le 1er caractère :
Tu as raison, mais il faut être pragmatique : quand un OP demande comment
utiliser scanf() pour faire un split() de chaines, je ne suis pas de ceux qui
proposent le format %[^:] , je préconise d'utiliser strchr() et d'éviter
scanf().
Où est cette solution qui préconise strchr ?
Celle que j'ai vu, est signé Yves Roman, et n'est pas complètement
satisfaisante : écrit dans la chaine de départ, ne vérifie pas grand
chose, lente (parcours 2 fois la chaine), longue (7 lignes contre 1 pour
le sscanf), etc.
C'est exact
Il faut quand même noter que sscanf parcours systématiquement toute la chaine de
départ au moins une fois, même s'il n'en extrait que le 1er caractère :
"Targeur fou" wrote in message
news:Charlie Gordon wrote:Conclusion : NE PAS UTILISER SCANF !
Il est où le problème avec scanf ? ;-) Dans ce qui suit, quelle
est
la différence avec fgets() d'un point de vue pratique par exemple
?
#include <stdio.h>
#define LG_SAISIE_STDIN 20
#define STR_(s) #s
#define STR(s) STR_(s)
int main(void)
{
int rc;
char tamponSaisie[LG_SAISIE_STDIN+1] = { ' ' };
rc = scanf("%"STR(LG_SAISIE_STDIN)"[^n]%*[^n]",tamponSaisie);
getchar();
if (rc != EOF) {
printf("Donnees saisies : n%sn", tamponSaisie);
}
else {
puts("Erreur lors de la saisie");
}
return 0;
}
Comme je l'écris dans ma réponse à Antoine, ta proposition est
très
lourde à mettre en oeuvre, hors de portée du débutant, et très
limitée en pratique :
tes macros ne fonctionnent que si LG_SAISIE_STDIN est elle-même une
macro s'expansant à une constante numérique décimale isolée.
exemples de définitions qui incompatibles avec ton approche :
#define LG_SAISIE_STDIN +20
#define LG_SAISIE_STDIN 0x20
#define LG_SAISIE_STDIN (20)
#define LG_SAISIE_STDIN (19+1)
enum { LG_SAISIE_STDIN = 20 };
int LG_SAISIE_STDIN = 20; // en variable locale de main(), C99
Quant à la différence avec fgets(), elle existe bel et bien :
- fgets() ne consomme pas la partie de la ligne d'input qui ne
"tient" pas dans le buffer, contrairement au format (cryptique)
%*[^n] dont c'est précisément l'objet.
- fgets() laisse le n à la fin du buffer sauf en cas de ligne trop
longue ou de fin de fichier sans n
- fgets() consomme le n en fin de ligne, alors que dans ta
proposition, n est remis dans stdin en fin de ligne, qu'il faut
consommer avec le getchar() incongru et sans explication.
- en cas de lignes vides dans l'input, scanf() retourne une valeur 0
et le contenu du buffer est indéterminé, ce que tu ne testes pas
correctement.
- l'utilisation de fgets() est beaucoup plus lisible.
- je parierais fort que l'efficacité d'un fgets() en lieu et place
du
scanf() serait sans commune mesure. Mais il faudrait un programme
qui execute massivement ce code sur une grande quantité de
données
pour mesurer une réelle différence de performances. J'ai testé
avec
un gros fichier et c'est 4 fois plus lent avec scanf que avec
fgets()
ou la fonction fgetline que je propose plus bas.
Certains de ces comportements de fgets() sont parfois inadéquats,
mais la solution consistant à lui substituer un format de scanf
totalement cryptique est peu recommandable.
"Targeur fou" <rtroadec@yahoo.fr> wrote in message
news:1114597700.714435.132380@l41g2000cwc.googlegroups.com...
Charlie Gordon wrote:
Conclusion : NE PAS UTILISER SCANF !
Il est où le problème avec scanf ? ;-) Dans ce qui suit, quelle
est
la différence avec fgets() d'un point de vue pratique par exemple
?
#include <stdio.h>
#define LG_SAISIE_STDIN 20
#define STR_(s) #s
#define STR(s) STR_(s)
int main(void)
{
int rc;
char tamponSaisie[LG_SAISIE_STDIN+1] = { ' ' };
rc = scanf("%"STR(LG_SAISIE_STDIN)"[^n]%*[^n]",tamponSaisie);
getchar();
if (rc != EOF) {
printf("Donnees saisies : n%sn", tamponSaisie);
}
else {
puts("Erreur lors de la saisie");
}
return 0;
}
Comme je l'écris dans ma réponse à Antoine, ta proposition est
très
lourde à mettre en oeuvre, hors de portée du débutant, et très
limitée en pratique :
tes macros ne fonctionnent que si LG_SAISIE_STDIN est elle-même une
macro s'expansant à une constante numérique décimale isolée.
exemples de définitions qui incompatibles avec ton approche :
#define LG_SAISIE_STDIN +20
#define LG_SAISIE_STDIN 0x20
#define LG_SAISIE_STDIN (20)
#define LG_SAISIE_STDIN (19+1)
enum { LG_SAISIE_STDIN = 20 };
int LG_SAISIE_STDIN = 20; // en variable locale de main(), C99
Quant à la différence avec fgets(), elle existe bel et bien :
- fgets() ne consomme pas la partie de la ligne d'input qui ne
"tient" pas dans le buffer, contrairement au format (cryptique)
%*[^n] dont c'est précisément l'objet.
- fgets() laisse le n à la fin du buffer sauf en cas de ligne trop
longue ou de fin de fichier sans n
- fgets() consomme le n en fin de ligne, alors que dans ta
proposition, n est remis dans stdin en fin de ligne, qu'il faut
consommer avec le getchar() incongru et sans explication.
- en cas de lignes vides dans l'input, scanf() retourne une valeur 0
et le contenu du buffer est indéterminé, ce que tu ne testes pas
correctement.
- l'utilisation de fgets() est beaucoup plus lisible.
- je parierais fort que l'efficacité d'un fgets() en lieu et place
du
scanf() serait sans commune mesure. Mais il faudrait un programme
qui execute massivement ce code sur une grande quantité de
données
pour mesurer une réelle différence de performances. J'ai testé
avec
un gros fichier et c'est 4 fois plus lent avec scanf que avec
fgets()
ou la fonction fgetline que je propose plus bas.
Certains de ces comportements de fgets() sont parfois inadéquats,
mais la solution consistant à lui substituer un format de scanf
totalement cryptique est peu recommandable.
"Targeur fou" wrote in message
news:Charlie Gordon wrote:Conclusion : NE PAS UTILISER SCANF !
Il est où le problème avec scanf ? ;-) Dans ce qui suit, quelle
est
la différence avec fgets() d'un point de vue pratique par exemple
?
#include <stdio.h>
#define LG_SAISIE_STDIN 20
#define STR_(s) #s
#define STR(s) STR_(s)
int main(void)
{
int rc;
char tamponSaisie[LG_SAISIE_STDIN+1] = { ' ' };
rc = scanf("%"STR(LG_SAISIE_STDIN)"[^n]%*[^n]",tamponSaisie);
getchar();
if (rc != EOF) {
printf("Donnees saisies : n%sn", tamponSaisie);
}
else {
puts("Erreur lors de la saisie");
}
return 0;
}
Comme je l'écris dans ma réponse à Antoine, ta proposition est
très
lourde à mettre en oeuvre, hors de portée du débutant, et très
limitée en pratique :
tes macros ne fonctionnent que si LG_SAISIE_STDIN est elle-même une
macro s'expansant à une constante numérique décimale isolée.
exemples de définitions qui incompatibles avec ton approche :
#define LG_SAISIE_STDIN +20
#define LG_SAISIE_STDIN 0x20
#define LG_SAISIE_STDIN (20)
#define LG_SAISIE_STDIN (19+1)
enum { LG_SAISIE_STDIN = 20 };
int LG_SAISIE_STDIN = 20; // en variable locale de main(), C99
Quant à la différence avec fgets(), elle existe bel et bien :
- fgets() ne consomme pas la partie de la ligne d'input qui ne
"tient" pas dans le buffer, contrairement au format (cryptique)
%*[^n] dont c'est précisément l'objet.
- fgets() laisse le n à la fin du buffer sauf en cas de ligne trop
longue ou de fin de fichier sans n
- fgets() consomme le n en fin de ligne, alors que dans ta
proposition, n est remis dans stdin en fin de ligne, qu'il faut
consommer avec le getchar() incongru et sans explication.
- en cas de lignes vides dans l'input, scanf() retourne une valeur 0
et le contenu du buffer est indéterminé, ce que tu ne testes pas
correctement.
- l'utilisation de fgets() est beaucoup plus lisible.
- je parierais fort que l'efficacité d'un fgets() en lieu et place
du
scanf() serait sans commune mesure. Mais il faudrait un programme
qui execute massivement ce code sur une grande quantité de
données
pour mesurer une réelle différence de performances. J'ai testé
avec
un gros fichier et c'est 4 fois plus lent avec scanf que avec
fgets()
ou la fonction fgetline que je propose plus bas.
Certains de ces comportements de fgets() sont parfois inadéquats,
mais la solution consistant à lui substituer un format de scanf
totalement cryptique est peu recommandable.
En <news:d4q7s8$8sv$,
Charlie Gordon va escriure:"Richard Delorme" wrote in message
news:42700131$0$26067$Où est cette solution qui préconise strchr ?
Celle que j'ai vu, est signé Yves Roman, et n'est pas complètement
satisfaisante : écrit dans la chaine de départ, ne vérifie pas grand
chose, lente (parcours 2 fois la chaine), longue (7 lignes contre 1
pour le sscanf), etc.
Je ne vois pas en quoi la solution de Yves Roman est plus lente que
d'utiliser strtok()
Normalement strtok() est implémenté par un appel à strspn() pour sauter les
séparateurs initiaux (inutile ici, coût négligeable), suivi d'un autre à (au
choix) strpbrk() ou strcspn() pour aller chercher le séparateur suivant. Au
total un seul parcours de la chaîne cible (et pléthore de parcours de la
chaîne des séparateurs). *Si* la chaîne cible est potentiellement très
longue, cela peut valoir le coût. D'un autre côté, dans le cas contraire,
strtok() (et sscanf() ) sont probablement moins intéressants.qui écrit AUSSI dans la chaine de départ, qui ce est souvent méconnu
On est quand même sensé savoir lire un peu plus loin que le bout de son nez:
le premier paramètre de strtok() est un char*, *pas* un char const*;
autrement dit, la chaîne sera modifiée.et une raison supplémentaire de s'en méfier.
Certes.Elle n'est sans doute pas plus lente non plus que scanf qui n'est
jamais implémenté en ligne et doit avec le format approprié faire
beaucoup plus de tests pour chaque caractère de msg.
« doit » ???
Par rapport à strtok(), sscanf() doit mettre en place son infrstructure et
parcourir la chaîne de format, ce qui a un coût certain mais unique. De
l'autre côté strtok() fait un appel inutile à strspn() pour sauter les
séparateurs initiaux (coût très faible). Après, tu as en fait la même chose:
chacun des deux lis la chaîne caractère par caractère, vérifie que le dit
caractère n'est pas dans la chaîne de référence ":" (le scanset pour
sscanf() et les séparateurs pour strtok()), puis recommence.
En fait, sscanf() peut être plus efficace que strtok(), car l'extraction du
scanset permet gratuitement de compter la longueur donc d'utiliser memchr()
pour la vérification, voire créer un arbre balancé (;-)), tandis que
strtok() va souvent utiliser strchr() pour cela, qui peut être moins
efficace.
Évidemment, on est à la merci des implémentations... par exemple, on peut
avoir un scanner qui à chaque vérification teste si on a un %[ (inclusif) ou
un %[^ (exclusif)... Ou encore une implémentation qui laisse le scanset en
place et qui traite l'extension a-z à chaque itération, donc un test pour
'-' à chaque caractère... :-(
En <news:d4q7s8$8sv$1@reader1.imaginet.fr>,
Charlie Gordon <news@chqrlie.org> va escriure:
"Richard Delorme" <abulmo@nospam.fr> wrote in message
news:42700131$0$26067$7a628cd7@news.club-internet.fr...
Où est cette solution qui préconise strchr ?
Celle que j'ai vu, est signé Yves Roman, et n'est pas complètement
satisfaisante : écrit dans la chaine de départ, ne vérifie pas grand
chose, lente (parcours 2 fois la chaine), longue (7 lignes contre 1
pour le sscanf), etc.
Je ne vois pas en quoi la solution de Yves Roman est plus lente que
d'utiliser strtok()
Normalement strtok() est implémenté par un appel à strspn() pour sauter les
séparateurs initiaux (inutile ici, coût négligeable), suivi d'un autre à (au
choix) strpbrk() ou strcspn() pour aller chercher le séparateur suivant. Au
total un seul parcours de la chaîne cible (et pléthore de parcours de la
chaîne des séparateurs). *Si* la chaîne cible est potentiellement très
longue, cela peut valoir le coût. D'un autre côté, dans le cas contraire,
strtok() (et sscanf() ) sont probablement moins intéressants.
qui écrit AUSSI dans la chaine de départ, qui ce est souvent méconnu
On est quand même sensé savoir lire un peu plus loin que le bout de son nez:
le premier paramètre de strtok() est un char*, *pas* un char const*;
autrement dit, la chaîne sera modifiée.
et une raison supplémentaire de s'en méfier.
Certes.
Elle n'est sans doute pas plus lente non plus que scanf qui n'est
jamais implémenté en ligne et doit avec le format approprié faire
beaucoup plus de tests pour chaque caractère de msg.
« doit » ???
Par rapport à strtok(), sscanf() doit mettre en place son infrstructure et
parcourir la chaîne de format, ce qui a un coût certain mais unique. De
l'autre côté strtok() fait un appel inutile à strspn() pour sauter les
séparateurs initiaux (coût très faible). Après, tu as en fait la même chose:
chacun des deux lis la chaîne caractère par caractère, vérifie que le dit
caractère n'est pas dans la chaîne de référence ":" (le scanset pour
sscanf() et les séparateurs pour strtok()), puis recommence.
En fait, sscanf() peut être plus efficace que strtok(), car l'extraction du
scanset permet gratuitement de compter la longueur donc d'utiliser memchr()
pour la vérification, voire créer un arbre balancé (;-)), tandis que
strtok() va souvent utiliser strchr() pour cela, qui peut être moins
efficace.
Évidemment, on est à la merci des implémentations... par exemple, on peut
avoir un scanner qui à chaque vérification teste si on a un %[ (inclusif) ou
un %[^ (exclusif)... Ou encore une implémentation qui laisse le scanset en
place et qui traite l'extension a-z à chaque itération, donc un test pour
'-' à chaque caractère... :-(
En <news:d4q7s8$8sv$,
Charlie Gordon va escriure:"Richard Delorme" wrote in message
news:42700131$0$26067$Où est cette solution qui préconise strchr ?
Celle que j'ai vu, est signé Yves Roman, et n'est pas complètement
satisfaisante : écrit dans la chaine de départ, ne vérifie pas grand
chose, lente (parcours 2 fois la chaine), longue (7 lignes contre 1
pour le sscanf), etc.
Je ne vois pas en quoi la solution de Yves Roman est plus lente que
d'utiliser strtok()
Normalement strtok() est implémenté par un appel à strspn() pour sauter les
séparateurs initiaux (inutile ici, coût négligeable), suivi d'un autre à (au
choix) strpbrk() ou strcspn() pour aller chercher le séparateur suivant. Au
total un seul parcours de la chaîne cible (et pléthore de parcours de la
chaîne des séparateurs). *Si* la chaîne cible est potentiellement très
longue, cela peut valoir le coût. D'un autre côté, dans le cas contraire,
strtok() (et sscanf() ) sont probablement moins intéressants.qui écrit AUSSI dans la chaine de départ, qui ce est souvent méconnu
On est quand même sensé savoir lire un peu plus loin que le bout de son nez:
le premier paramètre de strtok() est un char*, *pas* un char const*;
autrement dit, la chaîne sera modifiée.et une raison supplémentaire de s'en méfier.
Certes.Elle n'est sans doute pas plus lente non plus que scanf qui n'est
jamais implémenté en ligne et doit avec le format approprié faire
beaucoup plus de tests pour chaque caractère de msg.
« doit » ???
Par rapport à strtok(), sscanf() doit mettre en place son infrstructure et
parcourir la chaîne de format, ce qui a un coût certain mais unique. De
l'autre côté strtok() fait un appel inutile à strspn() pour sauter les
séparateurs initiaux (coût très faible). Après, tu as en fait la même chose:
chacun des deux lis la chaîne caractère par caractère, vérifie que le dit
caractère n'est pas dans la chaîne de référence ":" (le scanset pour
sscanf() et les séparateurs pour strtok()), puis recommence.
En fait, sscanf() peut être plus efficace que strtok(), car l'extraction du
scanset permet gratuitement de compter la longueur donc d'utiliser memchr()
pour la vérification, voire créer un arbre balancé (;-)), tandis que
strtok() va souvent utiliser strchr() pour cela, qui peut être moins
efficace.
Évidemment, on est à la merci des implémentations... par exemple, on peut
avoir un scanner qui à chaque vérification teste si on a un %[ (inclusif) ou
un %[^ (exclusif)... Ou encore une implémentation qui laisse le scanset en
place et qui traite l'extension a-z à chaque itération, donc un test pour
'-' à chaque caractère... :-(
Celle que j'ai vu, est signé Yves Roman, et n'est pas complètement
satisfaisante : écrit dans la chaine de départ, ne vérifie pas grand
chose, lente (parcours 2 fois la chaine), longue (7 lignes contre 1 pour
le sscanf), etc.
Je ne vois pas en quoi la solution de Yves Roman est plus lente que
d'utiliser
strtok() qui écrit AUSSI dans la chaine de départ, qui ce est souvent
méconnu et
une raison supplémentaire de s'en méfier.
Oui, mais dans l'esprit de strtok, on ne recopie pas la chaine, mais on
met des pointeurs vers chaque champs :
char *var1, *var2;
var1 = msg;
var2 = strtok(msg, ":");
Elle n'est sans doute pas plus lente non plus que scanf qui n'est jamais
implémenté en ligne et doit avec le format approprié faire beaucoup plus de
tests pour chaque caractère de msg.
scanf a le mérite de la concision.
Bref, à part être plus long que scanf, je ne vois pas ce qu'apporte
d'utiliser strchr.
Celle que j'ai vu, est signé Yves Roman, et n'est pas complètement
satisfaisante : écrit dans la chaine de départ, ne vérifie pas grand
chose, lente (parcours 2 fois la chaine), longue (7 lignes contre 1 pour
le sscanf), etc.
Je ne vois pas en quoi la solution de Yves Roman est plus lente que
d'utiliser
strtok() qui écrit AUSSI dans la chaine de départ, qui ce est souvent
méconnu et
une raison supplémentaire de s'en méfier.
Oui, mais dans l'esprit de strtok, on ne recopie pas la chaine, mais on
met des pointeurs vers chaque champs :
char *var1, *var2;
var1 = msg;
var2 = strtok(msg, ":");
Elle n'est sans doute pas plus lente non plus que scanf qui n'est jamais
implémenté en ligne et doit avec le format approprié faire beaucoup plus de
tests pour chaque caractère de msg.
scanf a le mérite de la concision.
Bref, à part être plus long que scanf, je ne vois pas ce qu'apporte
d'utiliser strchr.
Celle que j'ai vu, est signé Yves Roman, et n'est pas complètement
satisfaisante : écrit dans la chaine de départ, ne vérifie pas grand
chose, lente (parcours 2 fois la chaine), longue (7 lignes contre 1 pour
le sscanf), etc.
Je ne vois pas en quoi la solution de Yves Roman est plus lente que
d'utiliser
strtok() qui écrit AUSSI dans la chaine de départ, qui ce est souvent
méconnu et
une raison supplémentaire de s'en méfier.
Oui, mais dans l'esprit de strtok, on ne recopie pas la chaine, mais on
met des pointeurs vers chaque champs :
char *var1, *var2;
var1 = msg;
var2 = strtok(msg, ":");
Elle n'est sans doute pas plus lente non plus que scanf qui n'est jamais
implémenté en ligne et doit avec le format approprié faire beaucoup plus de
tests pour chaque caractère de msg.
scanf a le mérite de la concision.
Bref, à part être plus long que scanf, je ne vois pas ce qu'apporte
d'utiliser strchr.
Mais la plupart des programmeurs C ne lisent pas le manuel et intuitent la
sémantique de strncat de son prototype et de la méconnaissance de celle de
strncpy. Donc ils l'utilisent le plus souvent de facon erronée.
Mais la plupart des programmeurs C ne lisent pas le manuel et intuitent la
sémantique de strncat de son prototype et de la méconnaissance de celle de
strncpy. Donc ils l'utilisent le plus souvent de facon erronée.
Mais la plupart des programmeurs C ne lisent pas le manuel et intuitent la
sémantique de strncat de son prototype et de la méconnaissance de celle de
strncpy. Donc ils l'utilisent le plus souvent de facon erronée.
Tu n'as pas tort, mais ton exemple est faux : var2 == var1 sauf
dans le cas ou msg commence par un ou des ':'
L'utilisation "classique" de strtok() donne ceci :
char *var1, *var2;
var1 = strtok(msg, ":");
var2 = strtok(NULL, ":");
Mais le cas ou var1 est vide n'est pas supporté.
Bref strchr() est bien plus clair, et Ô combien plus rapide :
char *var1, *var2;
var1 = msg;
if ((var2 = strchr(msg, ':')) != NULL)
var2++;
scanf a le mérite de la concision.
Au prix d'une syntaxe cryptique, et d'une difficulté hors de portée du débutant
en particulier pour éviter les débordements de tableau.
Bref, à part être plus long que scanf, je ne vois pas ce qu'apporte
d'utiliser strchr.
C'est plus précis : le cas ou le séparateur est absent est facile à détecter.
Le cas ou var1 ou var2 sont vides n'apparaît pas comme une erreur alors que
scanf retournerait un nombre de champs traités inférieur à 2.
Tu n'as pas tort, mais ton exemple est faux : var2 == var1 sauf
dans le cas ou msg commence par un ou des ':'
L'utilisation "classique" de strtok() donne ceci :
char *var1, *var2;
var1 = strtok(msg, ":");
var2 = strtok(NULL, ":");
Mais le cas ou var1 est vide n'est pas supporté.
Bref strchr() est bien plus clair, et Ô combien plus rapide :
char *var1, *var2;
var1 = msg;
if ((var2 = strchr(msg, ':')) != NULL)
var2++;
scanf a le mérite de la concision.
Au prix d'une syntaxe cryptique, et d'une difficulté hors de portée du débutant
en particulier pour éviter les débordements de tableau.
Bref, à part être plus long que scanf, je ne vois pas ce qu'apporte
d'utiliser strchr.
C'est plus précis : le cas ou le séparateur est absent est facile à détecter.
Le cas ou var1 ou var2 sont vides n'apparaît pas comme une erreur alors que
scanf retournerait un nombre de champs traités inférieur à 2.
Tu n'as pas tort, mais ton exemple est faux : var2 == var1 sauf
dans le cas ou msg commence par un ou des ':'
L'utilisation "classique" de strtok() donne ceci :
char *var1, *var2;
var1 = strtok(msg, ":");
var2 = strtok(NULL, ":");
Mais le cas ou var1 est vide n'est pas supporté.
Bref strchr() est bien plus clair, et Ô combien plus rapide :
char *var1, *var2;
var1 = msg;
if ((var2 = strchr(msg, ':')) != NULL)
var2++;
scanf a le mérite de la concision.
Au prix d'une syntaxe cryptique, et d'une difficulté hors de portée du débutant
en particulier pour éviter les débordements de tableau.
Bref, à part être plus long que scanf, je ne vois pas ce qu'apporte
d'utiliser strchr.
C'est plus précis : le cas ou le séparateur est absent est facile à détecter.
Le cas ou var1 ou var2 sont vides n'apparaît pas comme une erreur alors que
scanf retournerait un nombre de champs traités inférieur à 2.
Mais
s'ils sont comme je l'imagine consultants en logiciel embarqué sous-traitants
de l'industrie, ça revient à laisser jouer les enfants dans une salle
d'opération avec les instruments chirurgicaux : gare aux dégats. Les tests
exhaustifs, quelle fumisterie!
Mais
s'ils sont comme je l'imagine consultants en logiciel embarqué sous-traitants
de l'industrie, ça revient à laisser jouer les enfants dans une salle
d'opération avec les instruments chirurgicaux : gare aux dégats. Les tests
exhaustifs, quelle fumisterie!
Mais
s'ils sont comme je l'imagine consultants en logiciel embarqué sous-traitants
de l'industrie, ça revient à laisser jouer les enfants dans une salle
d'opération avec les instruments chirurgicaux : gare aux dégats. Les tests
exhaustifs, quelle fumisterie!
Quant à strncpy() et strncat() : relisez la spec et vous
verrez qu'elles ne font
pas ce que la plupart des programmeurs pensent savoir ou
comprendre.
Il y a la doc, s'ils ne la comprennent parfois un peu de travers
comme moi ce n'est pas un problème, comme ils font des tests
exhaustifs ils finissent par comprendre ce qu'ils font.
C'est une plaisanterie !
Qu'on laisse jouer les bambins avec logo ou java, c'est pas bien
grave. Mais s'ils sont comme je l'imagine consultants en logiciel
embarqué sous-traitants de l'industrie, ça revient à laisser jouer les
enfants dans une salle d'opération
avec les instruments chirurgicaux : gare aux dégats. Les tests
exhaustifs, quelle fumisterie!
Quant à strncpy() et strncat() : relisez la spec et vous
verrez qu'elles ne font
pas ce que la plupart des programmeurs pensent savoir ou
comprendre.
Il y a la doc, s'ils ne la comprennent parfois un peu de travers
comme moi ce n'est pas un problème, comme ils font des tests
exhaustifs ils finissent par comprendre ce qu'ils font.
C'est une plaisanterie !
Qu'on laisse jouer les bambins avec logo ou java, c'est pas bien
grave. Mais s'ils sont comme je l'imagine consultants en logiciel
embarqué sous-traitants de l'industrie, ça revient à laisser jouer les
enfants dans une salle d'opération
avec les instruments chirurgicaux : gare aux dégats. Les tests
exhaustifs, quelle fumisterie!
Quant à strncpy() et strncat() : relisez la spec et vous
verrez qu'elles ne font
pas ce que la plupart des programmeurs pensent savoir ou
comprendre.
Il y a la doc, s'ils ne la comprennent parfois un peu de travers
comme moi ce n'est pas un problème, comme ils font des tests
exhaustifs ils finissent par comprendre ce qu'ils font.
C'est une plaisanterie !
Qu'on laisse jouer les bambins avec logo ou java, c'est pas bien
grave. Mais s'ils sont comme je l'imagine consultants en logiciel
embarqué sous-traitants de l'industrie, ça revient à laisser jouer les
enfants dans une salle d'opération
avec les instruments chirurgicaux : gare aux dégats. Les tests
exhaustifs, quelle fumisterie!
Tu utilises strncat pour réaliser en fait une copie avec limitation de
taille, c'est un peu surprenant pour le lecteur non averti, mais ce n'est pas
un bug, en revanche ton sprintf causera un debordement de tableau :-(
Utilises un tampon intermédiaire ou snprintf().
Meme chose pour FIC_str_time, et plus généralement partout ou tu utilises
sprintf.
Je vois que tu n'as pas vu à quoi servaient
Dans FIC_str_size, dans le cas d'une taille nulle, tu utilises strncat sans
avoir au préalable initialisé la destination (BUG!)
Tu utilises strncat pour réaliser en fait une copie avec limitation de
taille, c'est un peu surprenant pour le lecteur non averti, mais ce n'est pas
un bug, en revanche ton sprintf causera un debordement de tableau :-(
Utilises un tampon intermédiaire ou snprintf().
Meme chose pour FIC_str_time, et plus généralement partout ou tu utilises
sprintf.
Je vois que tu n'as pas vu à quoi servaient
Dans FIC_str_size, dans le cas d'une taille nulle, tu utilises strncat sans
avoir au préalable initialisé la destination (BUG!)
Tu utilises strncat pour réaliser en fait une copie avec limitation de
taille, c'est un peu surprenant pour le lecteur non averti, mais ce n'est pas
un bug, en revanche ton sprintf causera un debordement de tableau :-(
Utilises un tampon intermédiaire ou snprintf().
Meme chose pour FIC_str_time, et plus généralement partout ou tu utilises
sprintf.
Je vois que tu n'as pas vu à quoi servaient
Dans FIC_str_size, dans le cas d'une taille nulle, tu utilises strncat sans
avoir au préalable initialisé la destination (BUG!)
Tu utilises strncat pour réaliser en fait une copie avec limitation de
taille, c'est un peu surprenant pour le lecteur non averti, mais ce n'est
pas un bug, en revanche ton sprintf causera un debordement de tableau :-(
Utilises un tampon intermédiaire ou snprintf().
Meme chose pour FIC_str_time, et plus généralement partout ou tu utilises
sprintf.
Je vois que tu n'as pas vu à quoi servaient
Dans FIC_str_size, dans le cas d'une taille nulle, tu utilises strncat sans
avoir au préalable initialisé la destination (BUG!)
Tu utilises strncat pour réaliser en fait une copie avec limitation de
taille, c'est un peu surprenant pour le lecteur non averti, mais ce n'est
pas un bug, en revanche ton sprintf causera un debordement de tableau :-(
Utilises un tampon intermédiaire ou snprintf().
Meme chose pour FIC_str_time, et plus généralement partout ou tu utilises
sprintf.
Je vois que tu n'as pas vu à quoi servaient
Dans FIC_str_size, dans le cas d'une taille nulle, tu utilises strncat sans
avoir au préalable initialisé la destination (BUG!)
Tu utilises strncat pour réaliser en fait une copie avec limitation de
taille, c'est un peu surprenant pour le lecteur non averti, mais ce n'est
pas un bug, en revanche ton sprintf causera un debordement de tableau :-(
Utilises un tampon intermédiaire ou snprintf().
Meme chose pour FIC_str_time, et plus généralement partout ou tu utilises
sprintf.
Je vois que tu n'as pas vu à quoi servaient
Dans FIC_str_size, dans le cas d'une taille nulle, tu utilises strncat sans
avoir au préalable initialisé la destination (BUG!)