(#7)

If (#4) would be difficult to add a new switch allowing key and IV/Salt be as hex, something that would gain the vast majority of the benefit would be a switch allowing the 'l' literal key parameter to have the key parameter use the existing string handler used by the Salt/IV parameter beginning v7.56 - where codepoint 128-255 are each the single byte values 128-255 but codepoint 256+ is invalid. Maybe an "L" switch being mutually exclusive with 'l'.

This would allow all literal keys to be set, except for the 20% of 56-byte strings containing the 0x00 byte - the same way that handling Salt/IV as ANSI is allowing the 97% of 8-byte Salt/IV strings which don't containing an embedded 0x00.

As a way of showing the usefulness of this switch, this is the only way I know to check whether a binvar is a utf8 string, without making a long alias parsing it byte-by-byte:

Code
alias is_binvar_utf8 {
  noop $regsubex(foo,$bvar($1,1-).text,,,&maroon.tmp)
  if (($bvar($1,0) != $bvar(&maroon.tmp,0)) || ($sha1($1,1) != $sha1(&maroon.tmp,1))) { return $false } | return $true
}


The percentage of length 8 random binvar's, without 0x00, which are valid UTF8 is only 1% or so, so the ANSI handling of the Salt/IV parm greatly increases the number of valid combos. By the time the &binvar length is increased to 16, it becomes difficult to find any valid UTF8 strings, and becomes exponentially harder with each +1 length. But with this new switch, 100% of these strings not containing 0x00 would be valid literal keys.

Code
//var %i 9999 , %tot %0 , %yes 0 | while (%i) { bset &v 1 $regsubex(foo,$str(x,8),/x/g,$r(1,255) $+ $chr(32) ) | if ($is_binvar_utf8(&v)) inc %yes | inc %tot | dec %i } | echo -a yes %yes of %tot