#PB_Cipher_MD5 and val.b

[SPH]

Hi,
I wanted to upgrade a code from version 5.73 to version 6.11.
I encountered an "error". Actually, more of a fix.

Run this code on version 5.73:

Code: Select all

UseMD5Fingerprint()

RandomSeed(100)

Dim vingt.b(21)
For i=1 To 21
  vingt(i)=Random(255)
Next

mdp$="1"

StringFP$= StringFingerprint(mdp$+Chr(vingt(21)), #PB_Cipher_MD5)

For i=1 To 20
  StringFP$+ StringFingerprint(StringFP$+Chr(vingt(i)+mdp_sph), #PB_Cipher_MD5); erreur car "vingt.b". Hors, il faut un .w ou +
Next
Debug StringFP$
;;;

If CreateFile(6, "F:\TestSPH.txt")    ; Ouvre un fichier existant ou en crée un nouveau s'il n'existait pas
    FileSeek(6, Lof(6))           ; Place le pointeur à la fin du fichier en utilisant le résultat de Lof() 
    WriteString(6, StringFP$)
    CloseFile(6)
  EndIf
  
End:End

The file that is saved is this string:

"9bf31c7ff062936a96d3c8bd1f8f2ff3...5970e5cb7da573db02e7321f"

So far, so good.

Now, run this code on PB 6.11 (6.x+). It creates an error! Because PB_Cipher_MD5 doesn't want a .b value
BUT: compile the code and run it. It will create a file that is correct!

So, we can INDIRECTLY use .b with PB_Cipher_MD5!

==

I'm waiting to see what you have to say.... What do you think?

[jacdelad]

Random(255) emits a random value from 0..255. .b stores a value from -128..127. Theoretically it should create an overflow from time to time, but I don't know whether it simply continues with -128 after 127?!

Anyway, I guess that's the problem. Tried with .a?

[infratec]

The code is ... bad.

.a is the way to compile it without error, because what should Chr(-12) be
Chr() needs a positive value.

But what happens if your random value is 0
Is this expected?

[SPH]

It compiles without errors with a .b! That's what I wanted to point out in the first post...

[SPH]

With a .a, it gives another result!
It doesn't work like my original code in PB5.73. So not compatible. I stay in .b under PB6.11 but compiled so that it works.
Thx

Still, internally, the compiler does not apply what the notice says about #PB_Cipher_MD5 and the .b

[jacdelad]

Just because it works now, because of missing checks, does not mean it will work in the future...

[SPH]

Yes but my software is finished. So my future software will be compatible with PB 6.11+

[jacdelad]

What if future PB raises an error when trying to "Var.b=130"?

[SPH]

That will never happen. A LOT of codes regularly overflow.

[mk-soft]

I have no problem with the overflow here.
As a programmer you should understand something like this without problems and that the debug output is absolutely correct.

Code: Select all

var.b = 130
Debug var

[jacdelad]

I understand that, but it is somehow unnatural.

[mk-soft]

I understand that, but it is somehow unnatural.

For me as an old fart, that's not unnatural.
If you start with home computing when there were no paid PCs, you learn the basics of machine code of a Z80 processor (ZX81) to get some speed.
So number system, status registers, machine code and values by hand to translate everything into hex codes.

[jacdelad]

I understand that, but it is somehow unnatural.

For me as an old fart, that's not unnatural.
If you start with home computing when there were no paid PCs, you learn the basics of machine code of a Z80 processor (ZX81) to get some speed.
So number system, status registers, machine code and values by hand to translate everything into hex codes.

I'm glad, I'm wealthy enough to not have to do this.
But seriously, I fell a few times assigning a value >127 to a .b. Of course this does not throw an error and the result is somehow logical (I fully understand that it's up to the interpretion what the bytes represent). However, the result Random(255) is not logical for a .b. Doing this may lead to other problems, like still using .l for handles, because this still works for x86 code, and so on. But maybe I'm wrong.

[Quin]

I understand that, but it is somehow unnatural.

For me as an old fart, that's not unnatural.
If you start with home computing when there were no paid PCs, you learn the basics of machine code of a Z80 processor (ZX81) to get some speed.
So number system, status registers, machine code and values by hand to translate everything into hex codes.

I'm glad, I'm wealthy enough to not have to do this.
But seriously, I fell a few times assigning a value >127 to a .b. Of course this does not throw an error and the result is somehow logical (I fully understand that it's up to the interpretion what the bytes represent). However, the result Random(255) is not logical for a .b. Doing this may lead to other problems, like still using .l for handles, because this still works for x86 code, and so on. But maybe I'm wrong.

The reason the .l problem was as bad as it was is because it involved pointers, more specifically pointer addresses, overflowing. Standard overflow shouldn't make your applications crash just by virtue of happening.
Regardless, you're right that assigning a .b variable to Random(255) makes little sense.