[RESOLU]0927i2 : bug critique de lect./ecrit des variables

Bonjour à tous,

essayer ce code, il affiche une valeur négative!!! Faite varier le nombre de 1 en 1, l'affichage ne change pas.

Code:

' 0927i2
dim b%
b%=2147483640
print b%

Une autre ex. avec poke: la valeur attendu de b% est 16777215, mais ce n'est pas le cas!

Code:

' 0927i2
dim i,n,cible%,b%

b%=0
cible%=adr(b%)

' on ecrit 16777215 dans b%
print "on ecrit : 00 FF FF FF"
for i=0 to 2
   poke cible%+i,255
next i

' lire les octets qui compose b%
n=3
print "on lit : ";
for i=n to 0 step -1
   print hex$(peek(cible%+i));" ";
next i
print
print "on attend 00 FF FF FF, mais ce n'est pas le cas"
print

'
print "16777215 est la valeur de b% attendu"
print b%," est la valeur de b% lu"

end

Cela affecte les DLL également, car une commande du type 'call_dll1("function",adr(a$))' ne fonctionnera pas(c'est de cette manière que je suis tombé sur ce bug).
Je repasse sur la version 0926 jusqu'à la correction, car ce bug est trop sévère pour moi.

Bonjour.

De plus, le code suivant affiche toujours le même résultat !!
Même si l'on remplace '100' par une autre valeur !

Code:

' 0927i2
dim b%
b%=2147483640+100
message str$(b%)

Peut-être a-t-on atteint la limite des nombres entiers ?

silverman a écrit:

b%=2147483640

Cette valeur est vraiment très proche des limites du codage d'un entier sur 4 octets !

Un entier est codable de -2147483648 à 2147483647. L'écart vient peut-être du fait qu'en interne les entiers sont convertis en flottants, puis le PRINT reconvertit le flottant en entier avant affichage et dans cette double conversion des unités se perdent car on déborde peut-être à un moment.
Cela m'étonnerait que ton source fonctionne avec V 0.9.26. Si c'est le cas, il y a un bug que je rechercherai.

Pareil pour ton deuxième exemple : s'il fonctionne avec V 0.9.26, c'est qu'il y a un bug et je le rechercherai.

La différence entre V 0.9.26 et V 0.9.27i2, mis à part les modifications sur les calculs trigonométriques et quelques bugs corrigés, c'est que je n'utilise plus le même compilateur pour produire Panoramic. Je suis donc particulièrement motivé pour savoir si le nouveau compilateur ne jouerait pas des tours. J'étudie cela dès que possible (je ne peux pas en ce moment) et je donne des nouvelles.

Merci de de répondre si rapidement jack!

les 2 codes fonctionnent parfaitement sous la version 0926, et il fonctionnait aussi avec la 0925(c'est la version avec laquelle j'ai appris à utiliser peek et poke, j'avais fait pleins d'essais avec les variables et adr()...)

Aie. Ouille.

Bonsoir à tous !

Je n'ai pas le problème cité plus haut avec la version 0.9.27i3.

Il semblerait que seules les versions 0.9.27i1 et 0.9.27i2 soient affectées.

J'ai détecté ce bug à partir de la version 0927i2, donc je ne sais pas si il se produisait avec la version 0927i1.

Je confirme que ça fonctionne corectement avec la version 0927i3

Les versions 0.9.27i1 et 0.9.27i2 ont le problème.
La version 0.9.27i3 ne l'a plus. Elle n'a pas été générée sur le même ordinateur, et ce dernier n'a pas tout à fait la même version de compilateur que celui qui a généré les versions buggées.

L'enquête continue ...
Mais on touche au but.