Fixed Problems with SHA256/384/512

[Niwotian60]

There seems to be a problem with the builtin functions for SHA256, SHA384 and SHA512 running against filenames with embedded spaces. While the MD5 and SHA1 functions seem to work fine, SHA256 and SHA512 always return -1 and SHA384 doesn't even seem to exist as a function regardless of input. I tested using an explicit first parameter (not "s") to make sure that it is being treated as a filename and I also tested using both quoted and unquoted filenames. I created the following simple .btm file named "test file.btm" to demonstrate the problem:

[d:\dev]cat "test sha.btm"

ver
echo Testing ^%@md5["test sha.btm"]
echo %@md5["test sha.btm"]
echo Testing ^%@sha1["test sha.btm"]
echo %@sha1["test sha.btm"]
echo Testing ^%@sha256["test sha.btm"]
echo %@sha256["test sha.btm"]
echo Testing ^%@sha512["test sha.btm"]
echo %@sha512["test sha.btm"]
echo Testing ^%@sha384["test sha.btm"]
echo %@sha384["test sha.btm"]
​

and running the file I get the following output:

TCC 19.00.30 x64 Windows 10 [Version 6.3.10586]
Testing %@md5["test sha.btm"]
5743589F6AD60686194EAED077CE64E6
Testing %@sha1["test sha.btm"]
AE5323A88E967B21256B53DF8CF8CA52EDFD5F7F
Testing %@sha256["test sha.btm"]
-1
Testing %@sha512["test sha.btm"]
-1
Testing %@sha384["test sha.btm"]
TCC: (Sys) D:\dev\test sha.btm [11] Incorrect function.
"%@sha384["test sha.btm"]"​

 

[RogerB]

It seems to be quoted filenames that the @SHA functions don't like:

TCC  19.00.30 x64   Windows 10 [Version 6.3.10586]
TCC Build 30   Windows 10 Build 10586 

d:\temp>type foobar.txt
foobar
barfoo
foo foo foo
bar bar bar

d:\temp>echo %@sha512[foobar.txt]
C6F88EFB41CE06A4C1B02CB351A001B4ADD9DA8F13A20000CD4DF51B3AAF7155072BDA443EA1D9BDA9087A471146E2B5F18B854BFF2BDF0E2B
1CC517670DCD5D

d:\temp>echo %@sha512["foobar.txt"]
-1

The same thing happens with @SHA256.

I get the same failure for @SHA384 though, quotes or no quotes:

d:\temp>echo %@sha384[foobar.txt]
TCC: (Sys) Incorrect function.
"%@sha384[foobar.txt]"

 

[rconn]

Fixed in build 31.

 

[Niwotian60]

Thanks, Rex! Everything is working fine now.

 

[RogerB]

Rex - can I just check with you if this is intended behaviour?

If the filename supplied to @CRC32 or @MD5 doesn't exist then the function returns -1. If the file name supplied to any of the @SHA functions doesn't exist then the filename is returned:

TCC  19.01.31 x64   Windows 10 [Version 6.3.10586]
TCC Build 31   Windows 10 Build 10586

d:\>dir foobar.txt

Volume in drive D is unlabeled      Serial number is 6882:65c2
TCC: (Sys) The system cannot find the file specified.
"D:\foobar.txt"
                   0 bytes in 0 files and 0 dirs
   1,195,820,294,144 bytes free

d:\>echo %@crc32["foobar.txt"]
-1

d:\>echo %@md5[foobar.txt]
-1

d:\>echo %@sha1[foobar.txt]
foobar.txt

d:\>echo %@sha256[foobar.txt]
foobar.txt

d:\>echo %@sha384[foobar.txt]
foobar.txt

d:\>echo %@sha512[foobar.txt]
foobar.txt

The help file specifies that @CRC32 and @MD5 return -1 in these circumstances, but doesn't specify the return value of the @SHA functions. I guess you might say as it's undefined then I can't complain!

I'm not actually complaining though, just want to check if returning the filename is intended of if the @SHA functions should be returning -1 in these circumstances.

 

[rconn]

Rex - can I just check with you if this is intended behaviour?

If the filename supplied to @CRC32 or @MD5 doesn't exist then the function returns -1. If the file name supplied to any of the @SHA functions doesn't exist then the filename is returned:

It should be returning a -1 -- however, the failure is occurring before the SHA* functions are called. I will add a fix for that in the next build.