Improve performance and safety a bit

[jacks0n9]

I would recommend closing this pull request. It brings potential undefined behavior to your code in the case of unexpected input, which, even considering a small performance benefit, is a net-loss in terms of safety and development experience.

[xuxiaocheng0201]

I would recommend closing this pull request. It brings potential undefined behavior to your code in the case of unexpected input, which, even considering a small performance benefit, is a net-loss in terms of safety and development experience.

@jacks0n9 This is safe at all. no UB was brought. See the Safety comments.

[jacks0n9]

where is your guarantee that all encrypted bytes will be valid utf-8 when decrypted?

[xuxiaocheng0201]

The parameters. Both non_obfuscated_text and plaintext are &str. These are valid UTF-8s. Or, can you construct a set of strings which bring UB?

[jacks0n9]

no, but i can think of a sequence of bytes that when passed to the decrypt function will result in invalid utf-8, and therefore undefined-behavior. this is just unnecessary mental overhead for people who may wish to use the decrypt function in the future. before, they just had to worry about a panic, now they have to worry about undefined behavior. i guarantee this pull request will not be accepted.

[xuxiaocheng0201]

First, muddy_internal is an "internal" module. Any call from user is not expected. Second, I commented the Safety condition, like other unsafe functions in other crates. Therefore, if the user calls, the conditions must be guaranteed by themselves.

Don't always deny others, a even if the PR is not accepted, it depends on the author of the crate.

[jacks0n9]

thanks for deleting and closing the pull request