[CalvinTjoaquinn]

Fixes #358

hex_encode(1234) returns an empty string with no error, while every other encoding helper accepts a number.

hex_encode("1234") -> "31323334"
hex_encode(1234)   -> ""
base64(1234)       -> "MTIzNA=="
md5(1234)          -> "81dc9bdb52d04dc20036dbd8313ed055"

Why

hexutil.Encode in projectdiscovery/utils takes any but reads only a string or a []byte:

switch v := any(data).(type) {
case string:
    dataStr = v
case []byte:
    dataStr = string(v)
default:
    dataStr = ""
}

hex_encode handed args[0] straight to it, and govaluate turns a numeric literal into a float64, so the default branch ran and the result was empty. The repo's own test asserts bin_to_dec(1010) returns float64(10), which is the same detail from the other side.

toString is what the rest of the helpers take their input with, hex_decode included one line below, so that is what this uses.

Verification

Against the current code:

--- PASS  hex_encode("1234")
--- FAIL  hex_encode(1234)
--- FAIL  hex_encode(1234, "x")
--- FAIL  hex_decode(hex_encode(1234))
--- PASS  base64(1234)

The two passing rows are there to hold the string path and the convention this follows in place. The hex_decode row matters most: the round trip was silently lossy, returning "" rather than the digits.

go test -race ./... passes and golangci-lint run ./... reports 0 issues.

The same argument applies to hexutil.Encode itself, which cannot tell an empty input from an unsupported type. Fixing it there would reach every caller, but it is a public function in another repo, so this PR keeps to the DSL side. Happy to open one against utils if you would rather have it there.

Independent of #340, #341, #342 and #343. None of them touch these lines.