WAD @MD5 returns incorrect results for strings

[Steve Pitts]

Folks,

Up until today I've only ever used the single parameter version of @MD5 to return the hash of a file, but I've been messing around with the string version today and getting some unexpected results. To prove that the results are screwy I used the following batch file

@ECHO OFF
REM This batch file validates the output from the Take Command @MD5 function
REM with string arguments against RFC 1321, viz:
COMMENT
A.5 Test suite

The MD5 test suite (driver option "-x") should print the following
results:

MD5 test suite:
MD5 ("") = d41d8cd98f00b204e9800998ecf8427e
MD5 ("a") = 0cc175b9c0f1b6a831c399e269772661
MD5 ("abc") = 900150983cd24fb0d6963f7d28e17f72
MD5 ("message digest") = f96b697d7cb7938d525a2f31aaf161d0
MD5 ("abcdefghijklmnopqrstuvwxyz") = c3fcd3d76192e4007dfb496cca67e13b
MD5 ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789") =
d174ab98d277d9f5a5611c2c9f419d9f
MD5 ("123456789012345678901234567890123456789012345678901234567890123456
78901234567890") = 57edf4a22be3c955ac49da2e2107b67a
ENDCOMMENT
ECHO %@MD5[s,] (generated by TCC)
ECHO d41d8cd98f00b204e9800998ecf8427e (expected answer)
ECHO.
ECHO %@MD5[s,a] (generated by TCC)
ECHO 0cc175b9c0f1b6a831c399e269772661 (expected answer)
ECHO.
ECHO %@MD5[s,abc] (generated by TCC)
ECHO 900150983cd24fb0d6963f7d28e17f72 (expected answer)
ECHO.
ECHO %@MD5[s,message digest] (generated by TCC)
ECHO f96b697d7cb7938d525a2f31aaf161d0 (expected answer)
ECHO.
ECHO %@MD5[s,abcdefghijklmnopqrstuvwxyz] (generated by TCC)
ECHO c3fcd3d76192e4007dfb496cca67e13b (expected answer)
ECHO.
ECHO %@MD5[s,ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789] (generated by TCC)
ECHO d174ab98d277d9f5a5611c2c9f419d9f (expected answer)
ECHO.
ECHO %@MD5[s,12345678901234567890123456789012345678901234567890123456789012345678901234567890] (generated by TCC)
ECHO 57edf4a22be3c955ac49da2e2107b67a (expected answer)
ECHO.

which generated the following results:

>test_md5.btm
D41D8CD98F00B204E9800998ECF8427E (generated by TCC)
d41d8cd98f00b204e9800998ecf8427e (expected answer)

4144E195F46DE78A3623DA7364D04F11 (generated by TCC)
0cc175b9c0f1b6a831c399e269772661 (expected answer)

CE1473CF80C6B3FDA8E3DFC006ADC315 (generated by TCC)
900150983cd24fb0d6963f7d28e17f72 (expected answer)

6F9AB83227F65F9B86C380E2C9C33031 (generated by TCC)
f96b697d7cb7938d525a2f31aaf161d0 (expected answer)

35020D67A52D8E915330F0A77F676BBF (generated by TCC)
c3fcd3d76192e4007dfb496cca67e13b (expected answer)

86056D805455C8448F6C09404C3DB624 (generated by TCC)
d174ab98d277d9f5a5611c2c9f419d9f (expected answer)

903F43F5C1F384FC267110BF07CAEC04 (generated by TCC)
57edf4a22be3c955ac49da2e2107b67a (expected answer)

I've no idea whether or not this affects v19, as I'm not running that version here at home, but it certainly affects the 64 bit implementations of v17 (running on Windows 8.1) and v18 (running on Windows 7), specifically:

TCC 18.00.31 x64 Windows 7 [Version 6.1.7601]

TCC 17.00.77 x64 Windows 8.1 [Version 6.3.9600]

and I'd really like to see it fixed in v18 as well as v19.

 

[Alpengreis]

Maybe it's because the string is internally a Unicode String ... so the "a" is "\u0061" internally (or something like that).

 

[rconn]

WAD - as Alpengreis said, all internal strings are Unicode, and Unicode != ASCII. If you read a Unicode file, you'd get the same results as the strings.