J'ai un léger souci avec ce code très simple du K&R2.
/* ---------------------------*/
#include <stdio.h>
main()
{
int nc ;
nc = 0 ;
while (getchar() != EOF)
++nc ;
printf("%d\n", nc) ;
}
/* ---------------------------*/
Il doit compter les caractères que je tape avec mon clavier et afficher
le résultat. Or, tant qu'il y a des éventuels caractères à lire en
entrée, le résultat ne s'affiche pas, même après avoir tapé ENTER, ce
qui est normal.
Si je mets "10" à la place "EOF", quand je tape ENTER, là le résultat
s'affiche, c'est bien normal aussi.
Voici ma question. Comme je me dit que le code devrait marcher tel quel,
je me demandais s'il n'y avait pas une touche du clavier qui serait
interprétée en entré comme "EOF" ?
Il me semble que globalement une touche du clavier correspond à un
caractère, mais peut-être pas toutes. Si je n'ai aucun moyen envoyer en
entrée un "EOF", je ne vois pas comment ce petit code peut fonctionner
tel quel.
En news:20080320112504$, Vincent Lefevre va escriure:
Dans l'article <fre43i$k1f$, Antoine Leca écrit:
Une question un peu différente est d'expliquer pourquoi il faut éviter void main() [même si dans la pratique cela fonctionne partout, c'est nettement moins « correct » que main() tout seul, main(void) ou int main(). ]
Ça ne fonctionne pas sous Linux:
Pour moi, « fonctionne » ou « ne fonctionne pas » signifie que le programme exécute ses instructions comme demandé par le programmeur. Ce qu'il fait ici (même s'il n'y a pas d'instructions du tout).
Évidemment, le fait que le compilateur ne génère pas l'instruction du code de retour fait que sur ton système en particulier, il n'y a pas de code de retour disponible, donc le comportement à ce niveau est bizarre. Un programmeur qui omet délibérement le code de retour n'est manifestement pas intéressé par le comportement du système à ce niveau ; et en dehors de cela, le programme fonctionne.
Antoine
En news:20080320112504$3ead@prunille.vinc17.org, Vincent Lefevre va
escriure:
Dans l'article <fre43i$k1f$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> écrit:
Une question un peu différente est d'expliquer pourquoi il faut
éviter void main()
[même si dans la pratique cela fonctionne partout, c'est nettement
moins « correct » que main() tout seul, main(void) ou int main(). ]
Ça ne fonctionne pas sous Linux:
Pour moi, « fonctionne » ou « ne fonctionne pas » signifie que le programme
exécute ses instructions comme demandé par le programmeur. Ce qu'il fait ici
(même s'il n'y a pas d'instructions du tout).
Évidemment, le fait que le compilateur ne génère pas l'instruction du code
de retour fait que sur ton système en particulier, il n'y a pas de code de
retour disponible, donc le comportement à ce niveau est bizarre.
Un programmeur qui omet délibérement le code de retour n'est manifestement
pas intéressé par le comportement du système à ce niveau ; et en dehors de
cela, le programme fonctionne.
En news:20080320112504$, Vincent Lefevre va escriure:
Dans l'article <fre43i$k1f$, Antoine Leca écrit:
Une question un peu différente est d'expliquer pourquoi il faut éviter void main() [même si dans la pratique cela fonctionne partout, c'est nettement moins « correct » que main() tout seul, main(void) ou int main(). ]
Ça ne fonctionne pas sous Linux:
Pour moi, « fonctionne » ou « ne fonctionne pas » signifie que le programme exécute ses instructions comme demandé par le programmeur. Ce qu'il fait ici (même s'il n'y a pas d'instructions du tout).
Évidemment, le fait que le compilateur ne génère pas l'instruction du code de retour fait que sur ton système en particulier, il n'y a pas de code de retour disponible, donc le comportement à ce niveau est bizarre. Un programmeur qui omet délibérement le code de retour n'est manifestement pas intéressé par le comportement du système à ce niveau ; et en dehors de cela, le programme fonctionne.
Antoine
espie
In article <fsap2i$s21$, Antoine Leca wrote:
En news:20080320112504$, Vincent Lefevre va escriure:
Dans l'article <fre43i$k1f$, Antoine Leca écrit:
Une question un peu différente est d'expliquer pourquoi il faut éviter void main() [même si dans la pratique cela fonctionne partout, c'est nettement moins « correct » que main() tout seul, main(void) ou int main(). ]
Ça ne fonctionne pas sous Linux:
Pour moi, « fonctionne » ou « ne fonctionne pas » signifie que le programme exécute ses instructions comme demandé par le programmeur. Ce qu'il fait ici (même s'il n'y a pas d'instructions du tout).
Évidemment, le fait que le compilateur ne génère pas l'instruction du code de retour fait que sur ton système en particulier, il n'y a pas de code de retour disponible, donc le comportement à ce niveau est bizarre. Un programmeur qui omet délibérement le code de retour n'est manifestement pas intéressé par le comportement du système à ce niveau ; et en dehors de cela, le programme fonctionne.
La j'avoue, j'espere que c'est un cas ou les choses vont changer dans l'avenir. J'aimerais bien que, par defaut, sauf si je le passe en mode compatibilite avec le passe, mon compilateur C me sorte des *erreurs* sur des cas de code visiblement non definis.
Sur un systeme Unix, void main() est une faute, sans gravite sans doute, mais qui donne de mauvaises habitudes (et conduit a du code qui deconne).
Sur du code K&R, on avait des fonctions sans type de retour (l'ancienne convention de void) qui ne renvoyaient rien. Sur du code moderne, une fonction qui peut ne rien renvoyer alors qu'elle devrait renvoyer quelque chose, c'est une erreur. Ca serait bien que ca le devienne (par defaut).
Je sais, je suis un peu avocat du diable, puisqu'il y a des cas rigolos tels que abort() (c'est dommage qu'on n'ait pas de marqueur norme pour pouvoir annoter ce genre de choses), et qu'il faudrait un peu d'intelligence du compilateur pour pouvoir implementer ce genre de chose convenablement.
In article <fsap2i$s21$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> wrote:
En news:20080320112504$3ead@prunille.vinc17.org, Vincent Lefevre va
escriure:
Dans l'article <fre43i$k1f$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> écrit:
Une question un peu différente est d'expliquer pourquoi il faut
éviter void main()
[même si dans la pratique cela fonctionne partout, c'est nettement
moins « correct » que main() tout seul, main(void) ou int main(). ]
Ça ne fonctionne pas sous Linux:
Pour moi, « fonctionne » ou « ne fonctionne pas » signifie que le programme
exécute ses instructions comme demandé par le programmeur. Ce qu'il fait ici
(même s'il n'y a pas d'instructions du tout).
Évidemment, le fait que le compilateur ne génère pas l'instruction du code
de retour fait que sur ton système en particulier, il n'y a pas de code de
retour disponible, donc le comportement à ce niveau est bizarre.
Un programmeur qui omet délibérement le code de retour n'est manifestement
pas intéressé par le comportement du système à ce niveau ; et en dehors de
cela, le programme fonctionne.
La j'avoue, j'espere que c'est un cas ou les choses vont changer dans
l'avenir. J'aimerais bien que, par defaut, sauf si je le passe en mode
compatibilite avec le passe, mon compilateur C me sorte des *erreurs* sur
des cas de code visiblement non definis.
Sur un systeme Unix, void main() est une faute, sans gravite sans doute,
mais qui donne de mauvaises habitudes (et conduit a du code qui deconne).
Sur du code K&R, on avait des fonctions sans type de retour (l'ancienne
convention de void) qui ne renvoyaient rien. Sur du code moderne, une
fonction qui peut ne rien renvoyer alors qu'elle devrait renvoyer quelque
chose, c'est une erreur. Ca serait bien que ca le devienne (par defaut).
Je sais, je suis un peu avocat du diable, puisqu'il y a des cas rigolos
tels que abort() (c'est dommage qu'on n'ait pas de marqueur norme pour
pouvoir annoter ce genre de choses), et qu'il faudrait un peu d'intelligence
du compilateur pour pouvoir implementer ce genre de chose convenablement.
En news:20080320112504$, Vincent Lefevre va escriure:
Dans l'article <fre43i$k1f$, Antoine Leca écrit:
Une question un peu différente est d'expliquer pourquoi il faut éviter void main() [même si dans la pratique cela fonctionne partout, c'est nettement moins « correct » que main() tout seul, main(void) ou int main(). ]
Ça ne fonctionne pas sous Linux:
Pour moi, « fonctionne » ou « ne fonctionne pas » signifie que le programme exécute ses instructions comme demandé par le programmeur. Ce qu'il fait ici (même s'il n'y a pas d'instructions du tout).
Évidemment, le fait que le compilateur ne génère pas l'instruction du code de retour fait que sur ton système en particulier, il n'y a pas de code de retour disponible, donc le comportement à ce niveau est bizarre. Un programmeur qui omet délibérement le code de retour n'est manifestement pas intéressé par le comportement du système à ce niveau ; et en dehors de cela, le programme fonctionne.
La j'avoue, j'espere que c'est un cas ou les choses vont changer dans l'avenir. J'aimerais bien que, par defaut, sauf si je le passe en mode compatibilite avec le passe, mon compilateur C me sorte des *erreurs* sur des cas de code visiblement non definis.
Sur un systeme Unix, void main() est une faute, sans gravite sans doute, mais qui donne de mauvaises habitudes (et conduit a du code qui deconne).
Sur du code K&R, on avait des fonctions sans type de retour (l'ancienne convention de void) qui ne renvoyaient rien. Sur du code moderne, une fonction qui peut ne rien renvoyer alors qu'elle devrait renvoyer quelque chose, c'est une erreur. Ca serait bien que ca le devienne (par defaut).
Je sais, je suis un peu avocat du diable, puisqu'il y a des cas rigolos tels que abort() (c'est dommage qu'on n'ait pas de marqueur norme pour pouvoir annoter ce genre de choses), et qu'il faudrait un peu d'intelligence du compilateur pour pouvoir implementer ce genre de chose convenablement.
