bug à confirmer:

Archive.
jerexgrz
Messages : 279
Inscription : dim. 05/juin/2005 20:27

bug à confirmer:

Message par jerexgrz »

Code : Tout sélectionner


Global page.c

Structure test
x.l
y.l
page.b
EndStructure

Global Dim img.test (10)

img (1)\x = 10
img (1)\y = 20
img (1)\page = 155

For t=1 To 1
    page = img(t)\page
Next t

If page = 155
   Debug "youpi, y'a encore un autre bug !"
EndIf

Debug page
Debug img(1)\page
Ce test consiste à transférer la valeur numérique de img(1)\page, à la variable globale page !

Voici plusieurs bugs :
* Les types ne sont pas les memes, et "page" dans la structure img ne peut depasser 127 !
* La valeur retourner dans debug => -101 mais page = 155 !
C'était des durs à cuire ceux-la ! :lol:
ATHOW
Messages : 226
Inscription : mer. 29/déc./2004 16:54

Message par ATHOW »

Une variable de type ".b" va de -128 à 127, ça c'est pas un bug.
Pour le deuxième non, plus, c'est pas un bug, vu que tu rentres dans une variable ".b" une valeur excédant 127, ca foire forcément !

Change ton type de variable !
Avatar de l’utilisateur
djes
Messages : 4252
Inscription : ven. 11/févr./2005 17:34
Localisation : Arras, France

Message par djes »

C'est pourtant bien marqué dans la doc.

http://www.purebasic.com/french/documen ... ables.html

Pourquoi utiliser le type byte alors qu'il y a le long? C'est pour reproduire le bug de l'an 2000, c'est ça? Pourquoi ne pas travailler en octants pendant qu'on y est?
jerexgrz
Messages : 279
Inscription : dim. 05/juin/2005 20:27

Message par jerexgrz »

Justement, c'est pour ca que je l'ai indiqué ! On ne doit pas pouvoir rentrer de valeur > à 127 !
J'ai fait expres de mettre 155, pour voir s'il y aurait un msg !

ensuite, on transfere la valeur de img(1)\page vers page !
Normalement, la valeur de page ne peut pas etre 155 vu que img(1)\page ne peut retourner 155!
Verification: d'apres, debug on a "-101" pour img(1)\page.

On verifie quand meme la valeur de Page, et la, on s'aperçoit que la valeur est 155. La valeur a quand meme été transmise.

:?:
ATHOW
Messages : 226
Inscription : mer. 29/déc./2004 16:54

Message par ATHOW »

Ma théorie :

un ".b" est codé sur 8 bits, dont le bit de poids fort représente le signe (1: négatif, 0:positif).
Un ".c" est codé également sur 8 bits, sans bit de signe.
En ".c", 155 s'écrit 10011011 car 128 + 16 + 8 + 2 +1 = 155
En ".b" 10011011 représente -101 car :
Le "1" au bit de poids fort indique que c'est un nombre négatif.
Pour connaitre sa valeur en valeur absolue on effectue le "complément à 2", c'est à dire :

10011011 -> complément à 1 -> 01100100 -> plus 1 -> 01100101
Et 01100101 = 64 + 32 + 4 +1 = 101

Conclusion : 155 en ".c" = -101 en ".b"

Désolé pour le cours théorique :)

Plus d'infos ici : http://fr.wikipedia.org/wiki/Compl%C3%A ... C3%A0_deux

EDIT : j'ai corrigé mes erreurs de calcul :)
Avatar de l’utilisateur
djes
Messages : 4252
Inscription : ven. 11/févr./2005 17:34
Localisation : Arras, France

Message par djes »

Ca va j'ai compris. Tu es habitué à Access, ou à quelque chose du genre, avec un typage fort.

Ce qui veut dire que pour toi le programme devrait renvoyer une erreur en cas de dépassement.
Purebasic est plus orienté "bas niveau". C'est à dire que quand tu utilises une variable, c'est à toi de vérifier qu'elle est dans les limites valides.

Il faudrait que tu fasses un peu d'assembleur pour comprendre. En gros, quand tu travailles avec une variable de type octet (.b), seuls les bits significants sont copiés, sans vérification.

Ainsi, tu peux parfaitement mettre 271 ($10F ou %100001111) dans une variable de type octet (.b). Seuls les bits de poids faible seront copiés, et tu auras en retour 15 ($0F ou %00001111).

Tu comprends?
Répondre