Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Warn on use of unsafe decodeUtf8 #1280

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

michaelpj
Copy link

decodeUtf8 throws an exception, this is quite unexpected. There has been various discussion about this over time:

However, I think many people are unaware that this is partial - it doesn't look partial. So a hint is helpful.

I'd like some feedback, though: it's not clear to me what the RHS of such a rule should be. In particular, I don't know whether it's expected to typecheck. The "simplest" rule is what I've written here: replace decodeUtf8 with decodeUtf8', but the latter has a different type. I could instead make the RHS something like \bss -> case decodeUtf8' bs of { Left e -> error "fixme"; Right t -> t }?

@ndmitchell
Copy link
Owner

Thanks for the patch. As a general rule, the RHS should be equivalent to the RHS - in this case fromRight undefined . decodeUtf8' might be a reasonable RHS, since it's equivalent and more obviously partial.

However, if decodeUtf8 is manifestly wrong and people shouldn't use it, why not have the upstream text library deprecate it? It seems that the authors of the text library should really be making the call about which functions shouldn't be used, and if they make that call, there are better ways for them to enforce it. Given the ownership of the text library has changed several times since the linked ticket, perhaps reraise it there first?

@michaelpj
Copy link
Author

michaelpj commented Aug 15, 2021

That's fair, a deprecation would be better. I'll raise it again, but I'm not hugely hopeful.

I guess I am effectively asking for a back-door deprecation via hlint. It's fair enough if you'd rather leave that to upstream, but I do think it would be a service to the ecosystem to start nudging people to avoid it.

(This was prompted by me discovering a use of this in an upstream library that rendered a nominally-pure parsing function impure - and thus vulnerable to malicious input. It's quite a nasty problem!)

@michaelpj
Copy link
Author

Another thing worth mentioning is that even if it gets deprecated in text, that won't reach users until they upgrade to the newest version of text, whereas hlint lets us "backport" the recommendation.

@ndmitchell
Copy link
Owner

If you get upstream agreement, even to mark it with a documentation comment saying "don't use this", that's enough to make it clear that HLint should warn against it. Happy to use HLint to backport these suggestions.

@ndmitchell
Copy link
Owner

The text maintainers seem to be active once more, with new releases, so you might have more chance of getting a response from them now.

georgefst added a commit to georgefst/lifx-lan that referenced this pull request Apr 4, 2022
I hadn't actually considered that `decodeUtf8` must be partial until stumbling across ndmitchell/hlint#1280.

It would actually be very odd for us to hit this in practice, so there's no need to do more sophisticated error handling. The string passed to `fail` will end up in a thrown `LifxError.DecodeFailure`.

The impossible case covers a deprecated constructor. When it is finally removed, we'll get a warning prompting us to remove the redundant wildcard.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants