....-6.36165918672933E+84?
Probably not. All languages are assembly when it comes down to the final product. There is no assembly data type nor CPU data type that can completely handle that value without using approximation. The double data type would be the only one that could even come close. Perhaps a 128-bit floating point value could handle that but since no higher level languages support it, you would still be losing precision and/or employing techniques to split the number up into smaller segments and then use those segments to compose the final value.
Quite simply that value will not fit in any CPU register and I'm not even sure it would fit in any MMX register. It would probably fit in floating point registers (ST0 - ST7) but again it would be an approximation.
You would need a class that handles large numeric values to handle that value correctly.
And I think you are misusing the code:
Code:
int gs_chresp_num(char *challenge) {
int num = 0;
while(*challenge) {
num = *challenge - (num * 0x63306CE7);
challenge++;
}
return(num);
}
This won't code an entire string. You are re-assigning a value to num each time. This will only encode the last character of challenge.
This will encode the entire string, albeit will completely overflow the int data type.
Code:
int gs_chresp_num(char *challenge) {
int num = 0;
while(*challenge) {
num += *challenge - (num * 0x63306CE7);
challenge++;
}
return(num);
}
The operation done on num in this loop is essential to whether or not the data type overflows. Are you sure they are not doing some type of bitwise operations on num like:
Code:
num |= *challenge - (num * 0x63306CE7);
or
Code:
num ^= *challenge - (num * 0x63306CE7);
or
Code:
num &= *challenge - (num * 0x63306CE7);
This code looks something like a simple XOR encryption method that you are misusing.
Also remember that any language can be powerful, but all languages are only as powerful as the one using it.