Page 1 of 1
#PB_Cipher_MD5 and val.b
Posted: Tue Aug 27, 2024 6:06 pm
by 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?
Re: #PB_Cipher_MD5 and val.b
Posted: Tue Aug 27, 2024 6:45 pm
by 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?
Re: #PB_Cipher_MD5 and val.b
Posted: Tue Aug 27, 2024 7:59 pm
by 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?
Re: #PB_Cipher_MD5 and val.b
Posted: Tue Aug 27, 2024 8:09 pm
by SPH
It compiles without errors with a .b! That's what I wanted to point out in the first post...
Re: #PB_Cipher_MD5 and val.b
Posted: Tue Aug 27, 2024 8:37 pm
by 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
Re: #PB_Cipher_MD5 and val.b
Posted: Tue Aug 27, 2024 9:21 pm
by jacdelad
Just because it works now, because of missing checks, does not mean it will work in the future...
Re: #PB_Cipher_MD5 and val.b
Posted: Tue Aug 27, 2024 9:26 pm
by SPH
Yes but my software is finished. So my future software will be compatible with PB 6.11+
Re: #PB_Cipher_MD5 and val.b
Posted: Wed Aug 28, 2024 6:31 am
by jacdelad
What if future PB raises an error when trying to "Var.b=130"?
Re: #PB_Cipher_MD5 and val.b
Posted: Wed Aug 28, 2024 7:13 am
by SPH
That will never happen. A LOT of codes regularly overflow.
Re: #PB_Cipher_MD5 and val.b
Posted: Wed Aug 28, 2024 2:36 pm
by 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.
Re: #PB_Cipher_MD5 and val.b
Posted: Wed Aug 28, 2024 3:06 pm
by jacdelad
I understand that, but it is somehow unnatural.
Re: #PB_Cipher_MD5 and val.b
Posted: Wed Aug 28, 2024 6:53 pm
by mk-soft
jacdelad wrote: Wed Aug 28, 2024 3:06 pm
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.
Re: #PB_Cipher_MD5 and val.b
Posted: Wed Aug 28, 2024 7:14 pm
by jacdelad
mk-soft wrote: Wed Aug 28, 2024 6:53 pm
jacdelad wrote: Wed Aug 28, 2024 3:06 pm
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.
Re: #PB_Cipher_MD5 and val.b
Posted: Wed Aug 28, 2024 7:28 pm
by Quin
jacdelad wrote: Wed Aug 28, 2024 7:14 pm
mk-soft wrote: Wed Aug 28, 2024 6:53 pm
jacdelad wrote: Wed Aug 28, 2024 3:06 pm
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.