🚀 go-pugleaf

En <news:mn.b3997d59480be176.31483@laposte.net>,
    Pierre Maurette va escriure:
> 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
> :-(

Avec quelle machine, quelle compilo, quelle libc ?
Chez moi (P4, gcc/MingW, MSVCRT, en magouillant pour utiliser les double et
sqrt()), c'est off by 1...


> const uintmax_t borne =
>    UINTMAX_MAX >> (sizeof(UINTMAX_MAX) * CHAR_BIT / 2);
>
> Je ne sais pas si c'est toujours bon.

C'est nettement moins mauvais. Cela va foir� sur une machine avec un num�ro
impair de bits, mais je ne pense pas que ce soit un souci. Cela va foirer
aussi sur une machine qui a des bits inutilis� (en d'autres termes,
sizeof(uintmax_t)*CHAR_BIT n'est PAS le nombre de bits significatifs, il y
aurait du remplissage interne); pas courant du tout, mais cela peut arriver.


> 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.

SEULEMENT pour les types intN_t. Les autres, intmax_t ou uint_atleastN_t
etc., n'ont pas ces contraintes et poeuvent ne pas les respecter. Quant aux
machines qui ne remplissent pas les contraintes (genre PDP-10 ou Unisys), il
leur suffit de ne _pas_ fournir les types intN_t, ce qui fera foirer les
programmes qui exigent/s'attendent � une machine � r�guli�re �.


>> 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.

strcspn() (oui, c'�tait un gag, mais de ma part) ou le test pour supprimer
le signe - (qui a son importance, si tu le sautes cela va faire des trucs
bizarres.)


>>>   entier = strtoumax(pvaleur, NULL, 0);
>>
> Je me suis tromp� sur le sens du 0, j'aurais
> du utiliser 10, et modifier d'ailleurs le texte dans usage().

Il faut utiliser le second param�tre, et agir si strtoxxx() n'a pas su
convertir la totalit� de l'argument...


>>>   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)...

Mauvaise id�e.

D'abord, si tu veux utiliser errno, en dehors d'#inclure <errno.h> sinon �a
hurle, il faut toujours le remettre � 0 avant l'op�ration que tu veux
tester. On ne sait jamais ce qui peux tra�ner, ici l'appel ant�rieur �
sqrt() semble inoffensif mais ...

Ensuite, ne pr�suppose jamais que l'impl�mentation va respecter la norme si
par ailleurs tu peux �crire un code � peine diff�rent (ici, ne _pas_ tester
sp�cifquement ERANGE) qui peut rattraper au passage des petites
variations... donc exit le == ERANGE.

Enfin, en l'occurence le test de errno n'apporte rien: en cas de
d�bordement, strtoxxx() va renvoyer UINTmachin_MAX, qui va faire sauter le
cocotier de l'autre c�t�. Et le cas o� la conversion a loup� compl�tement
(return 0) n'est pas sens� positionner errno d'apr�s la norme (genre de cas
o� tu as une chance sur trois d'avoir l'impl�mentation qui se gourre).


>> � propos, que donne ton programme sur ta machine pour icarre
>> 4294967296 ?
> Pourquoi ? Il me donne ce que j'attendais, c'est � dire :
> Oh my God, c'est hainaurme !

Bon. Alors essaye de remplacer ton code par

  const uintmax_t borne = sqrt((double)UINTMAX_MAX);


>> Exercice compl�mentaire pour ceux qui n'ont rien �
>> faire : Expliquer pourquoi. ;-)


Antoine