Les entrees sont compliquees. C'est le cas dans tous les langages.
Il faudra bien tot ou tard l'expliquer a tes debutants.
Bof, ça dépend à qui tu t'adresses. Il y a
énormément de gens qui ne font du C qu'à
l'école ou à la fac.
Les entrees sont compliquees. C'est le cas dans tous les langages.
Il faudra bien tot ou tard l'expliquer a tes debutants.
Bof, ça dépend à qui tu t'adresses. Il y a
énormément de gens qui ne font du C qu'à
l'école ou à la fac.
Les entrees sont compliquees. C'est le cas dans tous les langages.
Il faudra bien tot ou tard l'expliquer a tes debutants.
Bof, ça dépend à qui tu t'adresses. Il y a
énormément de gens qui ne font du C qu'à
l'école ou à la fac.
Marc Espie a écrit :Mais sortir gets de sa poubelle, surtout avec tous les arguments
fallacieux que tu avances:
1/ c'est grotesque
2/ c'est une faute qui peut avoir des consequences graves.
Le Rationale est pourtant bien modéré concernant cette fonction :
The Committee decided that gets was useful and convenient in those
special circumstances when the programmer does have adequate control
over the input, and as longstanding existing practice, it needed a
standard specification.
Marc Espie a écrit :
Mais sortir gets de sa poubelle, surtout avec tous les arguments
fallacieux que tu avances:
1/ c'est grotesque
2/ c'est une faute qui peut avoir des consequences graves.
Le Rationale est pourtant bien modéré concernant cette fonction :
The Committee decided that gets was useful and convenient in those
special circumstances when the programmer does have adequate control
over the input, and as longstanding existing practice, it needed a
standard specification.
Marc Espie a écrit :Mais sortir gets de sa poubelle, surtout avec tous les arguments
fallacieux que tu avances:
1/ c'est grotesque
2/ c'est une faute qui peut avoir des consequences graves.
Le Rationale est pourtant bien modéré concernant cette fonction :
The Committee decided that gets was useful and convenient in those
special circumstances when the programmer does have adequate control
over the input, and as longstanding existing practice, it needed a
standard specification.
Marc Boyer a écrit :
> Et c'est quoi le code d'erreur de scanf ? Et pourquoi getc ne retou rne pas
> un char ? Et ça veut dire quoi que la valeur de retour est "unsigned char
> cast to an int" ?
Ici et dans tes messages précédents, tu as parfaitement traduit les
réactions des étudiants (et encore d'étudiants qui réagissent !)
> Non, les codes de retour, c'était la partie "maintenant, on fait attention",
> et ça va aussi avec les retours de malloc, etc.
Absolument. Question de progressivité qui s'impose pour moi comme une
évidence.
Marc Boyer a écrit :
> Et c'est quoi le code d'erreur de scanf ? Et pourquoi getc ne retou rne pas
> un char ? Et ça veut dire quoi que la valeur de retour est "unsigned char
> cast to an int" ?
Ici et dans tes messages précédents, tu as parfaitement traduit les
réactions des étudiants (et encore d'étudiants qui réagissent !)
> Non, les codes de retour, c'était la partie "maintenant, on fait attention",
> et ça va aussi avec les retours de malloc, etc.
Absolument. Question de progressivité qui s'impose pour moi comme une
évidence.
Marc Boyer a écrit :
> Et c'est quoi le code d'erreur de scanf ? Et pourquoi getc ne retou rne pas
> un char ? Et ça veut dire quoi que la valeur de retour est "unsigned char
> cast to an int" ?
Ici et dans tes messages précédents, tu as parfaitement traduit les
réactions des étudiants (et encore d'étudiants qui réagissent !)
> Non, les codes de retour, c'était la partie "maintenant, on fait attention",
> et ça va aussi avec les retours de malloc, etc.
Absolument. Question de progressivité qui s'impose pour moi comme une
évidence.
Une fois de plus, le C n'est pas un langage pour débutants en
informatique...
Trop de subtilités à gérer d'un coup...
Une fois de plus, le C n'est pas un langage pour débutants en
informatique...
Trop de subtilités à gérer d'un coup...
Une fois de plus, le C n'est pas un langage pour débutants en
informatique...
Trop de subtilités à gérer d'un coup...
Je crois que c'est incorrect car si je termine le flux par eof, alors
fgets() ne renverra pas NULL et il n'y aura pas de 'n' (le buffer est
vide) et pourtant la ligne a été lue entièrement.
Je crois que c'est incorrect car si je termine le flux par eof, alors
fgets() ne renverra pas NULL et il n'y aura pas de 'n' (le buffer est
vide) et pourtant la ligne a été lue entièrement.
Je crois que c'est incorrect car si je termine le flux par eof, alors
fgets() ne renverra pas NULL et il n'y aura pas de 'n' (le buffer est
vide) et pourtant la ligne a été lue entièrement.
Cote description, la page de man d'OpenBSD est on ne peut plus claire, et
rend la fonction parfaitement utilisable.
[Quitte a faire de la pub, c'est tres souvent le cas. C'est en grande
partie lie au fait que le projet utilise ces fonctions dans des conditions
reelles, et qu'il y a des gens que ca interesse de rendre ces pages les
plus claires possibles.]
Cote description, la page de man d'OpenBSD est on ne peut plus claire, et
rend la fonction parfaitement utilisable.
[Quitte a faire de la pub, c'est tres souvent le cas. C'est en grande
partie lie au fait que le projet utilise ces fonctions dans des conditions
reelles, et qu'il y a des gens que ca interesse de rendre ces pages les
plus claires possibles.]
Cote description, la page de man d'OpenBSD est on ne peut plus claire, et
rend la fonction parfaitement utilisable.
[Quitte a faire de la pub, c'est tres souvent le cas. C'est en grande
partie lie au fait que le projet utilise ces fonctions dans des conditions
reelles, et qu'il y a des gens que ca interesse de rendre ces pages les
plus claires possibles.]
Marc Espie scripsit :Cote description, la page de man d'OpenBSD est on ne peut plus claire, et
rend la fonction parfaitement utilisable.
[Quitte a faire de la pub, c'est tres souvent le cas. C'est en grande
partie lie au fait que le projet utilise ces fonctions dans des conditions
reelles, et qu'il y a des gens que ca interesse de rendre ces pages les
plus claires possibles.]
Merci pour la pub, je note. En plus on peut les consulter en ligne,
c'est pratique.
Marc Espie scripsit :
Cote description, la page de man d'OpenBSD est on ne peut plus claire, et
rend la fonction parfaitement utilisable.
[Quitte a faire de la pub, c'est tres souvent le cas. C'est en grande
partie lie au fait que le projet utilise ces fonctions dans des conditions
reelles, et qu'il y a des gens que ca interesse de rendre ces pages les
plus claires possibles.]
Merci pour la pub, je note. En plus on peut les consulter en ligne,
c'est pratique.
Marc Espie scripsit :Cote description, la page de man d'OpenBSD est on ne peut plus claire, et
rend la fonction parfaitement utilisable.
[Quitte a faire de la pub, c'est tres souvent le cas. C'est en grande
partie lie au fait que le projet utilise ces fonctions dans des conditions
reelles, et qu'il y a des gens que ca interesse de rendre ces pages les
plus claires possibles.]
Merci pour la pub, je note. En plus on peut les consulter en ligne,
c'est pratique.
> Cote description, la page de man d'OpenBSD est on ne peut plus claire,
et
rend la fonction parfaitement utilisable.
DESCRIPTION
The fgets() function reads at most size-1 characters from the given
stream and stores them in the string str. Reading stops when a newline
character is found, at end-of-file, or on error. The newline, if any, is
retained. The string will be NUL-terminated if fgets() succeeds; other-
wise the contents of str are undefined.
The gets() function is equivalent to fgets() with an infinite size and a
stream of stdin, except that the newline character (if any) is not stored
in the string. It is the caller's responsibility to ensure that the in-
put line, if any, is sufficiently short to fit in the string.
[nota bene: il n'est pas dit comment on peut s'assurer que la ligne en entree
va marcher pour gets(). Il n'y a pratiquement peu de cas ou l'appelant peut
assurer cette responsabilite -> gets() ne sert a rien].
RETURN VALUES
Upon successful completion, fgets() and gets() return a pointer to the
string. If end-of-file or an error occurs before any characters are
read, they return NULL. The fgets() and gets() functions do not distin-
guish between end-of-file and error, and callers must use feof(3) and
ferror(3) to determine which occurred. Whether fgets() can possibly fail
with a size argument of 1 is implementation-dependent. On OpenBSD,
fgets() will never return NULL when size is 1.
ferror. Et on peut considerer que c'est a la portee de n'importe qui dote
d'un cerveau en etat de fonctionner, chose un peu rare de nos jours.
Une autre facon de voir, c'est de dire que ca n'a pas de sens d'enseigner
le C a des gens:
- qui n'ont pas les prerequis necessaires;
- qui sont trop cons pour comprendre (desole, c'est pas du tout
politically-correct).
Du coup, c'est legitime de larguer le bagage en trop, et d'enseigner quelque
chose de correct pour les gens qui vont s'en servir en vrai.
A mon sens, le C correct est a la portee de qui s'en donne la peine. C'est
pas simple, ca demande du boulot et de l'opiniatrete. Mais il n'y a pas de
place pour les feignants qui ne feront pas les efforts necessaires, et ca ne
fait aucun sens de faire de la demagogie et d'essayer de faire croire que c'est
un langage simple et accessible au debutant sans faire d'efforts.
> Cote description, la page de man d'OpenBSD est on ne peut plus claire,
et
rend la fonction parfaitement utilisable.
DESCRIPTION
The fgets() function reads at most size-1 characters from the given
stream and stores them in the string str. Reading stops when a newline
character is found, at end-of-file, or on error. The newline, if any, is
retained. The string will be NUL-terminated if fgets() succeeds; other-
wise the contents of str are undefined.
The gets() function is equivalent to fgets() with an infinite size and a
stream of stdin, except that the newline character (if any) is not stored
in the string. It is the caller's responsibility to ensure that the in-
put line, if any, is sufficiently short to fit in the string.
[nota bene: il n'est pas dit comment on peut s'assurer que la ligne en entree
va marcher pour gets(). Il n'y a pratiquement peu de cas ou l'appelant peut
assurer cette responsabilite -> gets() ne sert a rien].
RETURN VALUES
Upon successful completion, fgets() and gets() return a pointer to the
string. If end-of-file or an error occurs before any characters are
read, they return NULL. The fgets() and gets() functions do not distin-
guish between end-of-file and error, and callers must use feof(3) and
ferror(3) to determine which occurred. Whether fgets() can possibly fail
with a size argument of 1 is implementation-dependent. On OpenBSD,
fgets() will never return NULL when size is 1.
ferror. Et on peut considerer que c'est a la portee de n'importe qui dote
d'un cerveau en etat de fonctionner, chose un peu rare de nos jours.
Une autre facon de voir, c'est de dire que ca n'a pas de sens d'enseigner
le C a des gens:
- qui n'ont pas les prerequis necessaires;
- qui sont trop cons pour comprendre (desole, c'est pas du tout
politically-correct).
Du coup, c'est legitime de larguer le bagage en trop, et d'enseigner quelque
chose de correct pour les gens qui vont s'en servir en vrai.
A mon sens, le C correct est a la portee de qui s'en donne la peine. C'est
pas simple, ca demande du boulot et de l'opiniatrete. Mais il n'y a pas de
place pour les feignants qui ne feront pas les efforts necessaires, et ca ne
fait aucun sens de faire de la demagogie et d'essayer de faire croire que c'est
un langage simple et accessible au debutant sans faire d'efforts.
> Cote description, la page de man d'OpenBSD est on ne peut plus claire,
et
rend la fonction parfaitement utilisable.
DESCRIPTION
The fgets() function reads at most size-1 characters from the given
stream and stores them in the string str. Reading stops when a newline
character is found, at end-of-file, or on error. The newline, if any, is
retained. The string will be NUL-terminated if fgets() succeeds; other-
wise the contents of str are undefined.
The gets() function is equivalent to fgets() with an infinite size and a
stream of stdin, except that the newline character (if any) is not stored
in the string. It is the caller's responsibility to ensure that the in-
put line, if any, is sufficiently short to fit in the string.
[nota bene: il n'est pas dit comment on peut s'assurer que la ligne en entree
va marcher pour gets(). Il n'y a pratiquement peu de cas ou l'appelant peut
assurer cette responsabilite -> gets() ne sert a rien].
RETURN VALUES
Upon successful completion, fgets() and gets() return a pointer to the
string. If end-of-file or an error occurs before any characters are
read, they return NULL. The fgets() and gets() functions do not distin-
guish between end-of-file and error, and callers must use feof(3) and
ferror(3) to determine which occurred. Whether fgets() can possibly fail
with a size argument of 1 is implementation-dependent. On OpenBSD,
fgets() will never return NULL when size is 1.
ferror. Et on peut considerer que c'est a la portee de n'importe qui dote
d'un cerveau en etat de fonctionner, chose un peu rare de nos jours.
Une autre facon de voir, c'est de dire que ca n'a pas de sens d'enseigner
le C a des gens:
- qui n'ont pas les prerequis necessaires;
- qui sont trop cons pour comprendre (desole, c'est pas du tout
politically-correct).
Du coup, c'est legitime de larguer le bagage en trop, et d'enseigner quelque
chose de correct pour les gens qui vont s'en servir en vrai.
A mon sens, le C correct est a la portee de qui s'en donne la peine. C'est
pas simple, ca demande du boulot et de l'opiniatrete. Mais il n'y a pas de
place pour les feignants qui ne feront pas les efforts necessaires, et ca ne
fait aucun sens de faire de la demagogie et d'essayer de faire croire que c'est
un langage simple et accessible au debutant sans faire d'efforts.
Au passage, je suis quand même allé regarder dans du code réel. Par
exemple dans les GNU core utilities, fichier getdate.c je trouve ceci :
/* ligne 0 */
#if TEST
#include <stdio.h>
int
main (int ac, char **av)
{
char buff[BUFSIZ];
time_t d;
printf ("Enter date, or blank line to exit.nt> ");
fflush (stdout);
buff[BUFSIZ - 1] = 0;
while (fgets (buff, BUFSIZ - 1, stdin) && buff[0])
{
d = get_date (buff, 0);
if (d == (time_t) -1)
printf ("Bad format - couldn't convert.n");
else
printf ("%s", ctime (&d));
printf ("t> ");
fflush (stdout);
}
return 0;
}
#endif /* defined TEST */
Pourquoi ligne 14 l'auteur place-t-il un 0 en final ?
Au passage, je suis quand même allé regarder dans du code réel. Par
exemple dans les GNU core utilities, fichier getdate.c je trouve ceci :
/* ligne 0 */
#if TEST
#include <stdio.h>
int
main (int ac, char **av)
{
char buff[BUFSIZ];
time_t d;
printf ("Enter date, or blank line to exit.nt> ");
fflush (stdout);
buff[BUFSIZ - 1] = 0;
while (fgets (buff, BUFSIZ - 1, stdin) && buff[0])
{
d = get_date (buff, 0);
if (d == (time_t) -1)
printf ("Bad format - couldn't convert.n");
else
printf ("%s", ctime (&d));
printf ("t> ");
fflush (stdout);
}
return 0;
}
#endif /* defined TEST */
Pourquoi ligne 14 l'auteur place-t-il un 0 en final ?
Au passage, je suis quand même allé regarder dans du code réel. Par
exemple dans les GNU core utilities, fichier getdate.c je trouve ceci :
/* ligne 0 */
#if TEST
#include <stdio.h>
int
main (int ac, char **av)
{
char buff[BUFSIZ];
time_t d;
printf ("Enter date, or blank line to exit.nt> ");
fflush (stdout);
buff[BUFSIZ - 1] = 0;
while (fgets (buff, BUFSIZ - 1, stdin) && buff[0])
{
d = get_date (buff, 0);
if (d == (time_t) -1)
printf ("Bad format - couldn't convert.n");
else
printf ("%s", ctime (&d));
printf ("t> ");
fflush (stdout);
}
return 0;
}
#endif /* defined TEST */
Pourquoi ligne 14 l'auteur place-t-il un 0 en final ?
Au passage, je suis quand même allé regarder dans du code réel. Par
exemple dans les GNU core utilities, fichier getdate.c je trouve ceci :
/* ligne 0 */
#if TEST
#include <stdio.h>
int
main (int ac, char **av)
{
char buff[BUFSIZ];
time_t d;
printf ("Enter date, or blank line to exit.nt> ");
fflush (stdout);
buff[BUFSIZ - 1] = 0;
while (fgets (buff, BUFSIZ - 1, stdin) && buff[0])
{
d = get_date (buff, 0);
if (d == (time_t) -1)
printf ("Bad format - couldn't convert.n");
else
printf ("%s", ctime (&d));
printf ("t> ");
fflush (stdout);
}
return 0;
}
#endif /* defined TEST */
Pourquoi ligne 14 l'auteur place-t-il un 0 en final ?
Au passage, je suis quand même allé regarder dans du code réel. Par
exemple dans les GNU core utilities, fichier getdate.c je trouve ceci :
/* ligne 0 */
#if TEST
#include <stdio.h>
int
main (int ac, char **av)
{
char buff[BUFSIZ];
time_t d;
printf ("Enter date, or blank line to exit.nt> ");
fflush (stdout);
buff[BUFSIZ - 1] = 0;
while (fgets (buff, BUFSIZ - 1, stdin) && buff[0])
{
d = get_date (buff, 0);
if (d == (time_t) -1)
printf ("Bad format - couldn't convert.n");
else
printf ("%s", ctime (&d));
printf ("t> ");
fflush (stdout);
}
return 0;
}
#endif /* defined TEST */
Pourquoi ligne 14 l'auteur place-t-il un 0 en final ?
Au passage, je suis quand même allé regarder dans du code réel. Par
exemple dans les GNU core utilities, fichier getdate.c je trouve ceci :
/* ligne 0 */
#if TEST
#include <stdio.h>
int
main (int ac, char **av)
{
char buff[BUFSIZ];
time_t d;
printf ("Enter date, or blank line to exit.nt> ");
fflush (stdout);
buff[BUFSIZ - 1] = 0;
while (fgets (buff, BUFSIZ - 1, stdin) && buff[0])
{
d = get_date (buff, 0);
if (d == (time_t) -1)
printf ("Bad format - couldn't convert.n");
else
printf ("%s", ctime (&d));
printf ("t> ");
fflush (stdout);
}
return 0;
}
#endif /* defined TEST */
Pourquoi ligne 14 l'auteur place-t-il un 0 en final ?
