string input for hash function

[cy...]

Hi community

"propose to extend hashing function to include string for hashing sensitive information (1-way)"

currently hash function is polymorphic and accepts only path as input, perhaps:

- input terminal can accept both string and path, determining type internally and change accordingly, and

- instead of polymorphic, enum terminal instead?

[rtollert]

---

@cy... wrote:

currently hash function is polymorphic and accepts only path as input

---

Have you checked the Numeric→Data Manipulation palette?

---

- input terminal can accept both string and path, determining type internally and change accordingly, and

---

This seems problematic from an API usage perspective. If a user wires in a string representation of a path by accident, they'll be hashing the path, instead of the contents of the file at that path. Better to keep them separate.

---

@cy... wrote:

- instead of polymorphic, enum terminal instead?

---

This runs the risk of doubling the overhead of using the hash functions when deploying RT VIs through the IDE. The top-level VI can't resolve which hash function is actually in use, so you'll be downloading both the SHA-2 and SHA-3 implementations every time. You could work around this by making the top-level VI inline, but I'm not sure that is the right approach.

[cy...]

thanks @rtollert

data manipulation - was unaware of the byte array function, can definitely add some codes ourselves to convert the message to byte array

API perspective - perhaps check if path exist or maintain as separate functions

doubling overhead - can be done on our end for cases that require functions to be changed programmatically

really should have spent some time reading the what's new. thanks for the new functions and explanation on the rationale provided

[crossrulz]

I just have to note that the Byte Array Checksum.vi is new in LabVIEW 2020.