Que ce soit un ou l'autre, c'est la meme si on reste avec la norme C, non? (Il me semble que c'est posix qui specifie que la valeur retournee est le nombre de caracteres ecrits et ce pour les deux).
#include <stdio.h> #include <stdlib.h> int main(void) { return puts("Free The World !") >= 0 ? EXIT_SUCCESS : EXIT_FAILURE; }
Quand puts retourne 0 (conforme, à vue de nez), tu retourne EXIT_FAILURE. Pas logique, je trouve.
Il y a un de nous deux qui n'a pas les yeux en face des trous.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
"Antoine Leca" <root@localhost.gov> writes:
En pxbfzbg9m61.fsf@news.bourguet.org, Jean-Marc Bourguet va escriure:
Ou est la gestion d'erreur?
Celle de printf, ou celle de puts ?
Que ce soit un ou l'autre, c'est la meme si on reste avec la norme C,
non? (Il me semble que c'est posix qui specifie que la valeur
retournee est le nombre de caracteres ecrits et ce pour les deux).
#include <stdio.h>
#include <stdlib.h>
int main(void) {
return puts("Free The World !") >= 0 ? EXIT_SUCCESS : EXIT_FAILURE;
}
Quand puts retourne 0 (conforme, à vue de nez), tu retourne EXIT_FAILURE.
Pas logique, je trouve.
Il y a un de nous deux qui n'a pas les yeux en face des trous.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Que ce soit un ou l'autre, c'est la meme si on reste avec la norme C, non? (Il me semble que c'est posix qui specifie que la valeur retournee est le nombre de caracteres ecrits et ce pour les deux).
#include <stdio.h> #include <stdlib.h> int main(void) { return puts("Free The World !") >= 0 ? EXIT_SUCCESS : EXIT_FAILURE; }
Quand puts retourne 0 (conforme, à vue de nez), tu retourne EXIT_FAILURE. Pas logique, je trouve.
Il y a un de nous deux qui n'a pas les yeux en face des trous.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
DINH Viêt Hoà
Quand puts retourne 0 (conforme, à vue de nez), tu retourne EXIT_FAILURE. Pas logique, je trouve.
Il y a un de nous deux qui n'a pas les yeux en face des trous.
tu as oublié d'ajouter que ce n'était pas toi :)
-- DINH V. Hoa,
"dans la famille, on est tous intelligents" -- sunZ
Quand puts retourne 0 (conforme, à vue de nez), tu retourne EXIT_FAILURE.
Pas logique, je trouve.
Il y a un de nous deux qui n'a pas les yeux en face des trous.
tu as oublié d'ajouter que ce n'était pas toi :)
--
DINH V. Hoa,
"dans la famille, on est tous intelligents" -- sunZ
Quand puts retourne 0 (conforme, à vue de nez), tu retourne EXIT_FAILURE. Pas logique, je trouve.
Il y a un de nous deux qui n'a pas les yeux en face des trous.
tu as oublié d'ajouter que ce n'était pas toi :)
-- DINH V. Hoa,
"dans la famille, on est tous intelligents" -- sunZ
Jean-Marc Bourguet
DINH Viêt Hoà writes:
Quand puts retourne 0 (conforme, à vue de nez), tu retourne EXIT_FAILURE. Pas logique, je trouve.
Il y a un de nous deux qui n'a pas les yeux en face des trous.
tu as oublié d'ajouter que ce n'était pas toi :)
En causant avec Antoine, c'est le genre de chose dont je ne suis sur qu'apres avoir consulte des references, ce dont je n'ai pas envie pour un fil [BRUIT].
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
DINH Viêt Hoà <dinh.viet.hoa@free.fr> writes:
Quand puts retourne 0 (conforme, à vue de nez), tu retourne EXIT_FAILURE.
Pas logique, je trouve.
Il y a un de nous deux qui n'a pas les yeux en face des trous.
tu as oublié d'ajouter que ce n'était pas toi :)
En causant avec Antoine, c'est le genre de chose dont je ne suis sur
qu'apres avoir consulte des references, ce dont je n'ai pas envie pour
un fil [BRUIT].
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Quand puts retourne 0 (conforme, à vue de nez), tu retourne EXIT_FAILURE. Pas logique, je trouve.
Il y a un de nous deux qui n'a pas les yeux en face des trous.
tu as oublié d'ajouter que ce n'était pas toi :)
En causant avec Antoine, c'est le genre de chose dont je ne suis sur qu'apres avoir consulte des references, ce dont je n'ai pas envie pour un fil [BRUIT].
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Antoine Leca
J'ai écrit ce matin
Quand puts retourne 0 (conforme, à vue de nez), tu retourne EXIT_FAILURE. Pas logique, je trouve.
Il y a un de nous deux qui n'a pas les yeux en face des trous.
Voui, cela a l'air d'être moi.
En , Jean-Marc Bourguet va escriure:
En causant avec Antoine, c'est le genre de chose dont je ne suis sur qu'apres avoir consulte des references, ce dont je n'ai pas envie pour un fil [BRUIT].
:-D
Antoine
J'ai écrit ce matin
Quand puts retourne 0 (conforme, à vue de nez), tu retourne
EXIT_FAILURE. Pas logique, je trouve.
Il y a un de nous deux qui n'a pas les yeux en face des trous.
Voui, cela a l'air d'être moi.
En pxbu0zw82aa.fsf@news.bourguet.org, Jean-Marc Bourguet va escriure:
En causant avec Antoine, c'est le genre de chose dont je ne suis sur
qu'apres avoir consulte des references, ce dont je n'ai pas envie pour
un fil [BRUIT].
Quand puts retourne 0 (conforme, à vue de nez), tu retourne EXIT_FAILURE. Pas logique, je trouve.
Il y a un de nous deux qui n'a pas les yeux en face des trous.
Voui, cela a l'air d'être moi.
En , Jean-Marc Bourguet va escriure:
En causant avec Antoine, c'est le genre de chose dont je ne suis sur qu'apres avoir consulte des references, ce dont je n'ai pas envie pour un fil [BRUIT].
:-D
Antoine
Richard Delorme
Pour C99, "%llu avec" (unsigned long long)
Encore raté, mais là tu devrais le savoir: en C99, il faut utiliser "%jd" avec (intmax_t), ou "%ju" avec (uintmax_t). Les types sont déclarés dans <inttypes.h> ou <stdint.h> (les deux sont valables pour un printf).
"%llu", c'est valable pour les compilateurs et bibliothèques (souvent Unix) du temps intermédiaire, entre ~1994 et la compatibilité C99 (~2001).
Faut-il comprendre que %llu n'est pas du C99 ?
-- Richard
Pour C99, "%llu avec" (unsigned long long)
Encore raté, mais là tu devrais le savoir: en C99, il faut utiliser "%jd"
avec (intmax_t), ou "%ju" avec (uintmax_t). Les types sont déclarés dans
<inttypes.h> ou <stdint.h> (les deux sont valables pour un printf).
"%llu", c'est valable pour les compilateurs et bibliothèques (souvent Unix)
du temps intermédiaire, entre ~1994 et la compatibilité C99 (~2001).
Encore raté, mais là tu devrais le savoir: en C99, il faut utiliser "%jd" avec (intmax_t), ou "%ju" avec (uintmax_t). Les types sont déclarés dans <inttypes.h> ou <stdint.h> (les deux sont valables pour un printf).
"%llu", c'est valable pour les compilateurs et bibliothèques (souvent Unix) du temps intermédiaire, entre ~1994 et la compatibilité C99 (~2001).
Faut-il comprendre que %llu n'est pas du C99 ?
-- Richard
Antoine Leca
En 4075617b$0$297$, Richard Delorme va escriure:
"%llu", c'est valable pour les compilateurs et bibliothèques (souvent Unix) du temps intermédiaire, entre ~1994 et la compatibilité C99 (~2001).
Faut-il comprendre que %llu n'est pas du C99 ?
Désolé si je n'étais pas clair.
"%llu" est bien sûr C99. Mais pour imprimer un grand entier, en C99, mieux vaut utiliser [u]intmax_t et "%jd"/"%ju" que les long long. Ce sont des bonnes habitudes qui éviteront des problèmes plus tard.
De même si on a /absolument/ besoin d'un type sur 64 bits, il faut se poser la question de savoir si on vraiment besoin d'un type de 64 bits, ou bien d'un type d'au moins 64 bits. Sauf dans le cas où on interface avec quelque chose d'existant (genre le FILETIME, et cela amène les joyeux problèmes d'alignements), la "bonne" réponse, c'est la seconde.
- si la réponse est quand même oui, "il faut 64 bits", alors se diriger vers [u]int64_t, et surtout pas long long qui pourrait bien valoir 128 bits un jour... Avec printf, on utilisera PRId64 ou PRIu64
- si la réponse est non, "mais il me faut au moins 64 bits", alors se diriger vers [u]int_least64_t s'il existe, pour éviter que quand le compilateur 64 bits aura des long long sur 128 bits, on ne subisse une pénalité inutile. Avec printf, on utilisera PRIdLEAST64 ou PRIuLEAST64 (je sais, ce n'est pas un modèle de lisibilité) C'est seulement si [u]int_least64_t n'est pas encore implanté (encore souvent le cas) que l'on se rabattera vers long long, en désespoir de cause.
De la même manière que long vers 1978 n'a pas été une bonne solution, parce que trop de programmeurs ont écrit du code avec l'idée "long = 32 bits", et que cela a été difficile (et pour Windows, cela a l'air fichu) de les faire changer d'avis, long long n'est pas une bonne solution pour palier la nécessité du 64 bits. Donc la norme C99 a créé une palanquée de nouveaux types, en essayant de couvrir tous les usages prévisibles. Maintenant, il faut en faire bon usage, et choisir celui qu'il faut pour l'usage que l'on veut en faire.
Antoine
En 4075617b$0$297$7a628cd7@news.club-internet.fr, Richard Delorme va
escriure:
"%llu", c'est valable pour les compilateurs et bibliothèques
(souvent Unix) du temps intermédiaire, entre ~1994 et la
compatibilité C99 (~2001).
Faut-il comprendre que %llu n'est pas du C99 ?
Désolé si je n'étais pas clair.
"%llu" est bien sûr C99. Mais pour imprimer un grand entier, en C99, mieux
vaut utiliser [u]intmax_t et "%jd"/"%ju" que les long long. Ce sont des
bonnes habitudes qui éviteront des problèmes plus tard.
De même si on a /absolument/ besoin d'un type sur 64 bits, il faut se poser
la question de savoir si on vraiment besoin d'un type de 64 bits, ou bien
d'un type d'au moins 64 bits. Sauf dans le cas où on interface avec quelque
chose d'existant (genre le FILETIME, et cela amène les joyeux problèmes
d'alignements), la "bonne" réponse, c'est la seconde.
- si la réponse est quand même oui, "il faut 64 bits", alors se diriger vers
[u]int64_t, et surtout pas long long qui pourrait bien valoir 128 bits un
jour... Avec printf, on utilisera PRId64 ou PRIu64
- si la réponse est non, "mais il me faut au moins 64 bits", alors se
diriger vers [u]int_least64_t s'il existe, pour éviter que quand le
compilateur 64 bits aura des long long sur 128 bits, on ne subisse une
pénalité inutile. Avec printf, on utilisera PRIdLEAST64 ou PRIuLEAST64 (je
sais, ce n'est pas un modèle de lisibilité)
C'est seulement si [u]int_least64_t n'est pas encore implanté (encore
souvent le cas) que l'on se rabattera vers long long, en désespoir de cause.
De la même manière que long vers 1978 n'a pas été une bonne solution, parce
que trop de programmeurs ont écrit du code avec l'idée "long = 32 bits", et
que cela a été difficile (et pour Windows, cela a l'air fichu) de les faire
changer d'avis, long long n'est pas une bonne solution pour palier la
nécessité du 64 bits. Donc la norme C99 a créé une palanquée de nouveaux
types, en essayant de couvrir tous les usages prévisibles. Maintenant, il
faut en faire bon usage, et choisir celui qu'il faut pour l'usage que l'on
veut en faire.
"%llu", c'est valable pour les compilateurs et bibliothèques (souvent Unix) du temps intermédiaire, entre ~1994 et la compatibilité C99 (~2001).
Faut-il comprendre que %llu n'est pas du C99 ?
Désolé si je n'étais pas clair.
"%llu" est bien sûr C99. Mais pour imprimer un grand entier, en C99, mieux vaut utiliser [u]intmax_t et "%jd"/"%ju" que les long long. Ce sont des bonnes habitudes qui éviteront des problèmes plus tard.
De même si on a /absolument/ besoin d'un type sur 64 bits, il faut se poser la question de savoir si on vraiment besoin d'un type de 64 bits, ou bien d'un type d'au moins 64 bits. Sauf dans le cas où on interface avec quelque chose d'existant (genre le FILETIME, et cela amène les joyeux problèmes d'alignements), la "bonne" réponse, c'est la seconde.
- si la réponse est quand même oui, "il faut 64 bits", alors se diriger vers [u]int64_t, et surtout pas long long qui pourrait bien valoir 128 bits un jour... Avec printf, on utilisera PRId64 ou PRIu64
- si la réponse est non, "mais il me faut au moins 64 bits", alors se diriger vers [u]int_least64_t s'il existe, pour éviter que quand le compilateur 64 bits aura des long long sur 128 bits, on ne subisse une pénalité inutile. Avec printf, on utilisera PRIdLEAST64 ou PRIuLEAST64 (je sais, ce n'est pas un modèle de lisibilité) C'est seulement si [u]int_least64_t n'est pas encore implanté (encore souvent le cas) que l'on se rabattera vers long long, en désespoir de cause.
De la même manière que long vers 1978 n'a pas été une bonne solution, parce que trop de programmeurs ont écrit du code avec l'idée "long = 32 bits", et que cela a été difficile (et pour Windows, cela a l'air fichu) de les faire changer d'avis, long long n'est pas une bonne solution pour palier la nécessité du 64 bits. Donc la norme C99 a créé une palanquée de nouveaux types, en essayant de couvrir tous les usages prévisibles. Maintenant, il faut en faire bon usage, et choisir celui qu'il faut pour l'usage que l'on veut en faire.
Antoine
Florent
Le Thu, 08 Apr 2004 19:26:10 +0200, Antoine Leca a écrit :
De la même manière que long vers 1978 n'a pas été une bonne solution, parce que trop de programmeurs ont écrit du code avec l'idée "long = 32 bits", et que cela a été difficile (et pour Windows, cela a l'air fichu) de les faire changer d'avis, long long n'est pas une bonne solution pour palier la nécessité du 64 bits. Donc la norme C99 a créé une palanquée de nouveaux types, en essayant de couvrir tous les usages prévisibles. Maintenant, il faut en faire bon usage, et choisir celui qu'il faut pour l'usage que l'on veut en faire.
Donc, si j'ai bien tout compris, en résumé, il faut éviter d'utiliser long ?
Florent.
Le Thu, 08 Apr 2004 19:26:10 +0200, Antoine Leca a écrit :
De la même manière que long vers 1978 n'a pas été une bonne solution, parce
que trop de programmeurs ont écrit du code avec l'idée "long = 32 bits", et
que cela a été difficile (et pour Windows, cela a l'air fichu) de les faire
changer d'avis, long long n'est pas une bonne solution pour palier la
nécessité du 64 bits. Donc la norme C99 a créé une palanquée de nouveaux
types, en essayant de couvrir tous les usages prévisibles. Maintenant, il
faut en faire bon usage, et choisir celui qu'il faut pour l'usage que l'on
veut en faire.
Donc, si j'ai bien tout compris, en résumé, il faut éviter d'utiliser
long ?
Le Thu, 08 Apr 2004 19:26:10 +0200, Antoine Leca a écrit :
De la même manière que long vers 1978 n'a pas été une bonne solution, parce que trop de programmeurs ont écrit du code avec l'idée "long = 32 bits", et que cela a été difficile (et pour Windows, cela a l'air fichu) de les faire changer d'avis, long long n'est pas une bonne solution pour palier la nécessité du 64 bits. Donc la norme C99 a créé une palanquée de nouveaux types, en essayant de couvrir tous les usages prévisibles. Maintenant, il faut en faire bon usage, et choisir celui qu'il faut pour l'usage que l'on veut en faire.
Donc, si j'ai bien tout compris, en résumé, il faut éviter d'utiliser long ?
Florent.
Emmanuel Delahaye
In 'fr.comp.lang.c', Yves ROMAN wrote:
Il manque le code de retour depuis qu'il est passé de void main a int main() int main(void) { return printf("Free The World !");} /* copyleft */
Pas obligatoire en C99.
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=cpp FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', Yves ROMAN <yves.roman@NO.unilog.SPAM.fr> wrote:
Il manque le code de retour depuis qu'il est passé de void main a int
main() int main(void) { return printf("Free The World !");} /*
copyleft */
Pas obligatoire en C99.
--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=cpp
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', DINH =?iso-8859-15?Q?Viêt_Hoà? wrote:
Qui s'y met pour une vraie version conforme et robuste?
extern int puts(const char * str); int main(void) {puts("Free The World !");exit(0)}
ou :
#include <stdio.h> #include <stdlib.h> int main(void) {printf("Free The World !n"); exit(EXIT_SUCCESS);}
Compliqué.
#include <stdio.h> int main(){puts("Kill Bush !");return 0;}
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=cpp FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Antoine Leca
Florent va escriture en news:
Donc, si j'ai bien tout compris, en résumé, il faut éviter d'utiliser long ?
Je crois que oui. En fait, aujourd'hui, en C99, si tu ne vises pas particulièrement la portabilité maximale et si tu n'as de "clients" sur 16 bits, tu n'utilises plus long.
Antoine
Florent va escriture en
news:pan.2004.04.08.17.36.30.618035@freePASDESPAM.fr...
Donc, si j'ai bien tout compris, en résumé, il faut éviter d'utiliser
long ?
Je crois que oui.
En fait, aujourd'hui, en C99, si tu ne vises pas particulièrement
la portabilité maximale et si tu n'as de "clients" sur 16 bits, tu
n'utilises plus long.
Donc, si j'ai bien tout compris, en résumé, il faut éviter d'utiliser long ?
Je crois que oui. En fait, aujourd'hui, en C99, si tu ne vises pas particulièrement la portabilité maximale et si tu n'as de "clients" sur 16 bits, tu n'utilises plus long.
