Hashing using script provides incorrect result (SHA-512)

[neil9090]

The hep file mentions
flags (bit field)
0: [default] String is data to hash.
1: String is a file spec whose contents to hash.
2: Show progress and allow break out by ESC. Only applied if "1" is also set.

But if I do

Code: Select all

::text "method 2: " . hash("sha512", ,2) 
for a file instead of;
::text "method 2: " . hash("sha512", ,3)  

I get different results
Also the ,2 result does not match another SHA-512 app hash result but the correct result for ,3 version of the code (believe ,3 is correct for file based hash)

The example in the help

Code: Select all

text hash(,,3); //md5 of current list file, with progress

Which changing it to SHA512 works I believe correctly,
It appears that ,2 is related to the string (parameter 2) i.e. change the string and the hash changes even when on the same file i.e. its string based hash
Looks like the help that is misleading, and missing parameter 3 value 3

[highend]

::text "method 2: " . hash("sha512", ,2)
for a file instead of;
::text "method 2: " . hash("sha512", ,3)

You're calculating a hash for a string (which is empty) in the first line and for the current file in the third line.

The parameter 3 isn't missing, it's a calculated value (flag 1 + 2 = 3).
You want to hash a file: flags = 1
You want to hash a string: flags = 0
You want to hash a file with progress: flags = 1 + 2 = 3

[PeterH]

...but documentation says to flag 2: Only applied if "1" is also set.

So flags=2 doesn't seem to make sense at all.

[highend]

It's a bit field. If he states that it's only used when 1 is set as well -> flags must be 3. Bad wording?

I didn't try if flags = 2 is working on such a large string that you'd see a progress display in the status bar...
<edit>: No, a single flag of 2 (at least) doesn't make much sense, a progress status is only displayed for files, not for strings.

[neil9090]

It's a bit field. If he states that it's only used when 1 is set as well -> flags must be 3. Bad wording?

I didn't try if flags = 2 is working on such a large string that you'd see a progress display in the status bar...
<edit>: No, a single flag of 2 (at least) doesn't make much sense, a progress status is only displayed for files, not for strings.

Thanks highend, I thought it was 1+2 = 3 but the help just made it unclear.

Do we need to log it to be cleared up?

[ksarnelli]

It's a bit field. If he states that it's only used when 1 is set as well -> flags must be 3. Bad wording?

I didn't try if flags = 2 is working on such a large string that you'd see a progress display in the status bar...
<edit>: No, a single flag of 2 (at least) doesn't make much sense, a progress status is only displayed for files, not for strings.

If it's a bit field shouldn't the option values be 1,2,4? 0,1,2 aren't distinct bit positions (0 and 1 use the same bit) and can produce ambiguous results.

example: A passed value of "3" could be interpreted as: 0+1+2 or 1+2

[PeterH]

No: either a bit is set, i.e. 1, or it's 0. (Docu says it's a bit field!)
The bit field, in decimal, is the sum of all the bit values, taking into account their positional value.

So:
0 (000) means all bits are 0 = false No file, no Progress
1 (001) means lowest bit is true file, no Progress
2 (010) means 2nd lowest is true No file, Progress - Don's comment says: no sense
3 (011) means both lowest and 2nd lowest set File, Progress
4 (100) no meaning here...

[ksarnelli]

No: either a bit is set, i.e. 1, or it's 0. (Docu says it's a bit field!)
The bit field, in decimal, is the sum of all the bit values, taking into account their positional value.

So:
0 (000) means all bits are 0 = false No file, no Progress
1 (001) means lowest bit is true file, no Progress
2 (010) means 2nd lowest is true No file, Progress - Don's comment says: no sense
3 (011) means both lowest and 2nd lowest set File, Progress
4 (100) no meaning here...

Ha, except that isn't actually how bit values are meant to work when dealing with combination values

Your example is too basic. Let's expand on your method:

0 = no options
1 = option 1
2 = option 2
3 = option 3
4 = option 4
5 = option 5
6 = option 6
7 = option 7
8 = option 8
etc

Now tell me what value 11 would mean? Is it 5+6, or 1+2+8, or 3+8, etc?

The proper way to use bit fields would be:

0 = no options [00000000]
1 = option 1 [00000001]
2 = option 2 [00000010]
4 = option 3 [00000100]
8 = option 4 [00001000]
16 = option 5 [00010000]
32 = option 6 [00100000]
64 = option 7 [01000000]
128 = option 8 [10000000]
etc

In this case a value of 11 could only be one possible combination: 1+2+8 (options 1, 2 and 4)
In fact every value consists of only one possible combination of options.



The way the hash() method is currently implemented (or maybe just documented) is a little confusing to the end user since not all bit field combinations are valid. In any case, easy fix

[PeterH]

Now tell me what value 11 would mean?

Seems this is the point?

11 is binary 1011 (8+2+1), so it means options 1, 2 and 4 (right to left) are set.

You number the right-most bit "1". As it's the 1st from right.
You might also number it "0". As it's value is 2**0.

[ksarnelli]

Now tell me what value 11 would mean?

Seems this is the point?

11 is binary 1011 (8+2+1), so it means options 1, 2 and 4 (right to left) are set.

You number the right-most bit "1". As it's the 1st from right.
You might also number it "0". As it's value is 2**0.

11 in my example is decimal as that is what gets passed as an argument to the method (sorry, I chose a poor example that looked binary). You can't expect a person to pass binary to a method - especially when you start getting into methods with a bitfield that contains hundreds of options - the proper way to do this is to add up the decimal values of all options and have them deconstructed at runtime. Just see any method in the Windows API if you want to see what I am talking about.

Anyway, I think the best way to resolve this is to not use combo bitfields for any argument that requires a default value. Those should be separate arguments. Maybe the hash() method should look like this (making use of some new constants):

hash ( enum algo, string str, enum mode, bitfield options )
enum algo:
HASH_MD5 = 0 (default)
HASH_SHA1 = 1
HASH_SHA256 = 2
HASH_SHA512 = 3
HASH_CRC32 = 4
enum mode:
HASH_STRING = 0 (default)
HASH_FILE = 1
bitfield options:
HASH_SHOWPROGRESS = 1 (Only valid when mode = HASH_FILE)
HASH_FUTUREOPTION1 = 2
HASH_FUTUREOPTION2 = 4
HASH_FUTUREOPTION3 = 8
etc

And then a future call could look something like this:
hash(HASH_SHA256, "c:\test.txt", HASH_FILE, HASH_SHOWPROGRESS + HASH_FUTUREOPTION2)
which would be equivalent to:
hash(2, "c:\test.txt", 1, 5)
and could easily by parsed at runtime back to derive what exactly the user selected.

[PeterH]

Sometimes it seems we're saying the same, sometimes the opposite

Looking at Don's (or XY's) bit-fields you see that one option has value=1, the next value=2, if more than value=4, =8, ...
And you have to add the values of the options you want to set - that's all.

There are other metods to achieve the same - but this is how Don has decided to make it. Maybe other method's are more intuitive - but at least this is clean. At least for me

Edit to add: in this case Don documented a dependency: set option 2 only if option 1 is also set.

[ksarnelli]

Sometimes it seems we're saying the same, sometimes the opposite

Looking at Don's (or XY's) bit-fields you see that one option has value=1, the next value=2, if more than value=4, =8, ...
And you have to add the values of the options you want to set - that's all.

There are other metods to achieve the same - but this is how Don has decided to make it. Maybe other method's are more intuitive - but at least this is clean. At least for me

Agreed - I think the problem stems from the value 0 having an explicit meaning which interferes with the whole combo methodology and the fact that 2 is not a valid option by itself. Separate args would probably work better.

Anyway, nice discussion, have a great weekend! (Hopefully Don is too on whatever vacation he is on!)