Skip to content

Type safety issue? #124

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

Open
treeowl opened this issue Jun 1, 2023 · 2 comments · May be fixed by #126
Open

Type safety issue? #124

treeowl opened this issue Jun 1, 2023 · 2 comments · May be fixed by #126

Comments

@treeowl
Copy link
Collaborator

treeowl commented Jun 1, 2023

The fake GADT we now use for maps and unordered traversals and folds is a little bit unsafe. I thought that we were well protected by the fact that the queue would have to reach O(2^WORDSIZE) elements to cause a problem, but it's actually possible to do this in a reasonable amount of time on systems with 32-bit Word but addressable memory considerably exceeding $2^32$ words, if there are any such around. In particular, an adversary could calculate something like stimes (2^(2^32)) (singleton () ()). This will take quite a long time, and something in excess of 64 gigabytes of memory, but I think it's possible in principle.

Suppose someone uses traverseU on this monstrosity, with a Backwards applicative. I suspect they will be able to actually reach the point where underflow occurs, leading to an unsafe coercion and memory fault.


The easiest solution is to use Word64 instead of Word. I don't think it's realistic to produce a queue whose size exceeds $2^{2^{64}}$ by any means whatsoever. The downside is that this will hurt performance on 32-bit systems. I don't know how much we care.

The other obvious solution is to make sure we never underflow. The best way to do that is probably to perform a size check on insert and on union. This has the side benefit of ensuring that size always produces a correct value. The downside of course is that insertion becomes ever so slightly slower.

treeowl added a commit to treeowl/pqueue that referenced this issue Jun 2, 2023
Use `WordPtr` instead of `Word` for `Nattish`. `Word` is actually fine,
but I think `WordPtr` makes it more *obviously* fine, and also adds a
bit of insurance against hypothetical future changes to GHC.

Closes lspitzner#124.
@treeowl treeowl linked a pull request Jun 2, 2023 that will close this issue
@konsumlamm
Copy link
Collaborator

I'm not sure this is actually a problem we need to solve. All the containers in containers have a warning that their behaviour is undefined if the size exceeds maxBound :: Int. How is $2^{2^{32}}$ elements any more realistic than $2^{2^{64}}$? It's not even possible to allocate that much memory on a 64 bit CPU.

@treeowl
Copy link
Collaborator Author

treeowl commented Jun 2, 2023

You can make an enormous queue using union, which can produce loads of internal sharing. stimes (2^(2^32) :: Integer) (singleton () ()) should actually work on a machine with enough memory, and I gather such machines are not so rare anymore. Exercise for the reader: calculate the exact amount of memory required.

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 a pull request may close this issue.

2 participants