Need suggestions for dealing with 128-bit hash values as unsigned

[Mbee]

I'm still a relative newbie, but every time I try something new with this system, I'm freshly reminded of the astonishing power and flexibility that springs from the awesomeness that is AutoIt!

Even so, I've run into an issue dealing with the 128-bit return values from the _Crypt_HashFile() function (using MD5) that I need help with.  Although AutoIt arrays store these 128-bit values with aplomb (even on my 32-bit systems), I can't seem to sort them properly because apparently the built-in comparison operators (i.e., > & <) treat them as signed values, whereas the hashes are actually unsigned values (it's not uncommon for the most significant bit to be set, which makes them appear as negative numbers).

Since the built-in comparison operators don't treat them as unsigned integers, I tried some using array functions, but it also seems that _ArrayBinarySearch(), _ArrayInsert(), and _ArraySort()  treat them as signed values, which messes up the algorithms I'd coded up.

So what I'm looking for is guidance on how to write AutoIt code that treats those values as unsigned 128-bit integers, allowing unsigned compare operations for sorting and the like, on both 32-bit and 64-bit processors. 

Any suggestions, wiser friends?

 

[jchd]

Store your hashes in string format (using consistent casing). Thay will sort lexicographically, which is what you want. x86 vs x64 is irrelevant here.

[Mbee]

Store your hashes in string format (using consistent casing). Thay will sort lexicographically, which is what you want. x86 vs x64 is irrelevant here.

 

Dear jchd,

Thank you for your reply!  I apologize for the delay in my response, but I've had some personal matters to attend to, and also I wanted to do as much as my own research as possible before returning to ask for more help.

WIth respect, your suggestion occurred to me well before I posted my OP, and I apologize for not stating that.  However, doing what you suggest within AutoIt is harder than it sounds.  Since the basic way of converting an integer into a decimal string is to use division and modulo, because AutoIt treats these values as signed integers, if the most-significant bit is set, the resulting string will be wrong.  (And AutoIt's StringFormat() function cannot deal with 128-bit unsigned integers either).

In trying to come up with a solution, my research led me to the AutoIt BigNum port by eukalyptus (/'?do=embed' frameborder='0' data-embedContent>>), but that didn't pan out.  I then looked at funkey's GMP library wrappers ('?do=embed' frameborder='0' data-embedContent>>), but that didn't pan out either (like the BigNum port, it doesn't seem to support unsigned 128-bit integers, or one would have to supply a string equivalent to the unsigned decimal value of the 128-bit integer, which I don't know how to produce).  Then I looked at LibTom (http://libtom.org/), which looked quite promising at first, but the functions require an already-constructed decimal string representing the value, which as I explained above, I cannot produce.

So I'm right back where I started, with the question in my OP: How do I write AutoIt code that treats those values as unsigned 128-bit integers, allowing unsigned compare operations for sorting and the like, on both 32-bit and 64-bit processors?

Or, How do I convert an unsigned 128-bit integer into an ASCII string that somehow bypasses or works-around the always-signed arithmetic of AutoIt?

 

I'm still stumped!

[JohnOne]

I know nothing about this so forgive me if it's stupid, but could a byte array struct be useful?

[jchd]

I didn't advise to convert values to decimal. Just store the hashes as hex strings.