Reputation: 11218
The foreign function interface allows haskell to work with C world. Now Haskell side allows working with the pointers using Storable
instances. So for example If I have an array of integers in the C world, a plausible representation of that in the haskell world would be Ptr Int
. Now suppose I want to translate the C expression a[0] = a[0] + 1
. The only way to do that on the haskell side is to peek int out and then poke back the result of the addition. The problem with this approach is a temporary value is created as a result of that. (I am not sure an optimizing compiler can always avoid doing that)
Now most people might think this effect to be harmless, but think of a situation where the Pointer object contains some sensitive data. I have created this pointer on the c side in such a way that it always guaranteed that its content will never be swapped out of the memory (using mlock system call). Now peeking the result on the haskell side no more guarantees the security of the sensitive data.
So what should be the best way to avoid that in the haskell world? Has anybody else ran into similar problems with low level pointer manipulations in haskell.
Upvotes: 2
Views: 672
Reputation: 64750
I just built a test case with the code:
foo :: Ptr CInt -> IO ()
foo p = peek p >>= poke p ∘ (+1)
And using GHC 7.6.3 -fllvm -O2 -ddump-asm
I see the relevant instructions:
0x0000000000000061 <+33>: mov 0x7(%r14),%rax
0x0000000000000065 <+37>: incl (%rax)
So it loads an address into rax
and increments the memory at that address. Seems to be what you'd get in other languages, but let's see.
With C, I think the fair comparison is:
void foo(int *p)
{
p[0]++;
}
Which results in:
0x0000000000000000 <+0>: addl $0x1,(%rdi)
All this said, I freely admit that it is not clear to me what you are concerned about so I might have missed your point and in doing so addressed the wrong thing.
Upvotes: 3