sha1 builtin

Oct 18, 2008
Hello --- I seems to come across and issue generating the sha1 hash for stings --- I did a simple test using

echo %@sha1[s,h] -> 0CD979583B209CE71603EFC4A398E6A9EFA8D872

but when using other tools to compute the same digest i get


I found an online tool "sha1-online,com" that also generated this value

Did I miss something with @sha1 or is this a bug?
Here's one that will work on one-line strings. No doubt it has limitations.

v:\> function sha1a `%@exec[@set file=%@unique[%tmp]]%@exec[@echos %$ > %file]%@sha1[f,%file]%@exec[@del /q %file]%@exec[@unset file]`

v:\> echo %@sha1a[h]
yes --- I was thinking of use a file in that way, but the one line function is very clever ---thanks for the info
It's very slow however! In a test like this

timer & do i=1 to 1000 ( echo %@sha1a[h] > NUL ) & timer

its times are ~100x those of @SHA1. If you use a fixed file name

function sha1a `%@exec[@echos %$ > sha1a.tmp]%@sha1[f,sha1a.tmp]%@exec[@del /q sha1a.tmp]`

you can get that down to ~10x.
More specifically, strings in TCC are UTF-16LE.

$ printf h | iconv -t UTF-16LE | sha1sum
0cd979583b209ce71603efc4a398e6a9efa8d872 *-
Spaces at the start of the string are ignored, but spaces at the end are checksummed. The help file claims that leading spaces are included, but that's incorrect.

And AFAIK, all the behaviors noted in this thread apply to all of the checksum functions: @CRC32, @CKSUM, @MD5, and all of the @SHA* family.