PureBasic Forums - English

thanks, works fine.

is there a way to calculate the result step by step and not all at once? so for example instead of using 100% buffer, calculate the first 50% and then the last 50% after that to reduce memory usage (similar to what AddFingerprintBuffer is doing)?

are there any news? will this issue be solved? is it a bug or wanted to be like that? not being able to use all possible ascii characters as key is not good if someone like me wants to decode data generated with a key that purebasic can not handle.

I did try to explain it in the other thread 1988reload is referring to.

PureBasic nowadays is Unicode internally.

I understood that. But if the result is wrong because of that then it is a bug, isn't it? I think #PB_Ascii should work like ASCII even if it is calculated as Unicode internally ...

I tried different ways to calculate a correct HMAC SHA1 hash and had no success. I shortened the code more and more to find out where the issue might be. The result was that some ASCII characters generated a bad result when used as key.

I have also asked here for help, but got no solution: https ...

Yes, this works when the key is only one byte long. But the key I want to use has much more than one byte. I made the above example to find out why it is not working correctly and found out that some of the bytes are calculated wrongly.

Here is a longer key example with the above problem ...

I have tested the new HMAC functions in PureBasic 6.10 and am wondering why I am getting the same result for some of the different ASCII characters. The issue only appears between ASCII codes 127 and 160, but I cannot see why these should be special in any way. Can someone explain to me why this ...