🚀 go-pugleaf

Antoine Leca, le 22/09/2005, a �crit :
[...]
Vindiou !!! Des corrections de l'Emmanuel et de l'Antoine ! C'est la 
f�te au village ! J'va fair p�ter l'sauvignon et m'occuper d'la Marie, 
ten !

>> void usage(void)
>> {
>>   puts("[...]");
>>   exit(EXIT_SUCCESS);
>
> L'usage() est de ne pas indiquer cela comme un succ�s...
Ah, bon. Je pensais le contraire. Je pensais m�me l'avoir lu ici. En 
fait, je pensais que dans le contexte, je sors proprement apr�s avoir 
affich� mon message, et que vu de l'OS, le programme se sera termin� 
"normalement".
En d'autres termes, le programme a fait tout ce que je souhaitais, 
c'est l'utilisateur qui a d�conn�, et je lui ai signifi�.

Bien entendu, si le programme n'�tait pas une "commande" (utilis� au 
clavier), j'imaginerais d�finir un code de retour explicite, un 
EXIT_COMMANDERROR par exemple. Mais alors, quand j'affiche que le 
nombre est trop grand, dois-je renvoyer un EXIT_RANGEERROR ?

Je ne suis pas convaincu compl�tement, et je suis bien malheureux, 
parce que le bons sens veut que ce ne soit pas moi qui ait raison.

Il se trouve que je n'ai jamais exploit� de code de retour directement, 
hors des fonctions Windows:

unsigned long TermStatus;
CreateProcess(NULL,cmd.c_str(),NULL,NULL,false,0,NULL,NULL,&si,&pi);
do
  {
  GetExitCodeProcess(pi.hProcess, &TermStatus);
  }while(TermStatus == STILL_ACTIVE);


[...]
>
>> #include <errno.h>
>
> Quelle utilit� ?
Aucune.
Scorie d'une correction de derni�re seconde. C'�tait au d�part:
if((errno == ERANGE) || (entier > borne))



>> #include <inttypes.h>
>
>
> Contr�le C99 (__STDC_VERSION__>199901) avant d'utiliser <inttypes.h> de
> cette mani�re. Cet ent�te est pr�sent depuis de longues ann�es dans les
> environnements *nix, mais n'y d�finit qu'une petite partie de ce qui est
> dans le <inttypes.h> de C99, en gros les [u]intN_t.
Faut que je regarde �a de plus pr�s. Les types � taille exacte 
m'int�ressent, mais pas le C99 dans ce qu'il a de compatible avec rien 
(pour l'instant). J'essaie plut�t d'utiliser un tronc commun C90 et 
C++98, comme par exemple en castant le retour d'un malloc(). JE sais 
que c'est foireux, mais bon ...


>> int main(int argc, char * argv[])
>> {
>>   uintmax_t entier;
>>   char * pvaleur = NULL;
>>   const uintmax_t borne = sqrtl((long double)UINTMAX_MAX);
>
>  :-) En dehors du fait que tu passes un double � une fonction qui attend un
> long double, et que tu interpr�tes comme int cde qui est un long double
> (cela risque d'�tre rigolo, mais c'est facile � corriger), que se passe-t-il
> si UINTMAX_MAX est sup�rieur � [L]DBL_MAX ? Tu croises les doigts et tu
> esp�res que la conversion de l'infini renvoy� habituellement par sqrtl()
> dans un tel cas va �tre automatiquement traduit ?
>
> En fait, si le nombre de bits significatifs de UINTxxx_MAX est pair, cas
> courant, il se trouve que cette op�ration peut �tre facilement programm�e
> avec un d�calage tous les deux bits.
Je savais que le passage par les double �tait foireux, je suis all� au 
plus rapide en utilisant un truc abominable, j'ai test� aux limites :-( 
sur un seul compilateur. Ce que j'avais en t�te, c'�tait bien d'arriver 
� 2^32 - 1, soit UINT32_MAX (par exemple), � partir de UINTMAX_MAX. 
Genre:
const uintmax_t borne =
   UINTMAX_MAX >> (sizeof(UINTMAX_MAX) * CHAR_BIT / 2);

Je ne sais pas si c'est toujours bon. Il faut quand m�me se rappeler 
que l'existaence d'un type de <inttypes.h> induit des garanties quant � 
son format. Pas de padding, et compl�ment � 2 pour les sign�s. Ce qui 
me laisse un peu perplexe.

>>   while(pvaleur[0] == '-' || isspace(pvaleur[0])) pvaleur++;
>
> Tu peux faire la m�me chose avec
>         pvaleur+=strcpsn(pvaleur, "- \f\n\r\t\v");
> L'avantage, c'est que comme ce n'est pas � �vident �, tu te sens oblig� de
> mettre un commentaire, qui pourrait faire comprendre l'utilit� de cette
> op�ration (il se trouve que j'ai une id�e du pourquoi, mais pas forc�ment
> tous ceux qui nous lisent).
Certes. C'�tait un peu un gag. Et puis je ne connais pas strcpsn(). Il 
se trouve que je je suis un peu les discussions r�currrentes sur les 
fonctions de m�moire et de cha�nes et leur cot� hyper dangereux, et que 
je me dis parfois qu'il serait souvent plus simple de faire vite fait 
un truc exactement adapt� � ce qu'on veut.


>>   entier = strtoumax(pvaleur, NULL, 0);
>
> Mmm.
> icarre 1e4 ne va pas faire ce qui est attendu, pas plus que icarre 012.
> icarre 0x64 peut surprendre aussi. icarre zero va renvoyer le bon r�sultat,
> mais c'est plut�t un hasard.
J'ai fait une connerie. Je me suis tromp� sur le sens du 0, j'aurais du 
utiliser 10, et modifier d'ailleurs le texte dans usage().


>>   if(errno || (entier > borne))
>>             puts("Oh my God, c'est h�naurme !");
>
> Ou bien sqrtl a eu un probl�me...
Oui. J'ai �t� tent� par un if ((errno == ERANGE)...

>>   else
>>       printf("%" PRIuMAX "\n", entier * entier);
>>   return EXIT_SUCCESS;
>
> Autrement dit, tu retournes toujours "succ�s", que l'on ce soit tromp�
> d'arguments, que ce soit h�naurme, que le printf ait eu un probl�me ou
> quoique ce soit d'autre.
D�j� comment�. Sinc�rement, je n'ai jamais test� le retour du printf(). 
Si je le faisais, et que je d�cidais de sortir, je renverrais 
certainement un EXIT_FAILURE, ou le retour du printf(). Puisqu'il s'est 
pass� des trucs que j'ignore dans ce printf(), et que je ne ma�trise 
plus. Et, je me r�p�te, si j'affiche que le nombre saisi est trop 
grand, je ma�trise ce qui se passe.

> � propos, que donne ton programme sur ta machine pour icarre 4294967296 ?
> Exercice compl�mentaire pour ceux qui n'ont rien � faire : Expliquer
> pourquoi. ;-)
Pourquoi ? Il me donne ce que j'attendais, c'est � dire :
Oh my God, c'est hainaurme !
Si je force � l'affichage de entier * entier, j'ai bien 0. Et si je 
remplace par 4294967296, j'ai un gros nombre qui doit �tre le plus gros 
carr� parfait sous 64 bits. Non ?

-- 
Pierre Maurette