FFI problem - possibility of CStringLen overflow?
While rewriting cautious-file to use ByteStrings and FFI just now, I came across this potential problem: Why does the FFI specification define CStringLen as (Ptr CChar, Int)? As the FFI specification itself notes, Haskell 98 implementors are allowed to have a quite small range for Int (only up to 2^29-1) - so you could in principle have a very large String which cannot be represented as a CStringLen, or a very large CString which cannot be represented as a CStringLen. They would take up wads of memory, so this has probably never happened yet, but it's in principle possible, no? If so, what are the implications of this for code correctness? -- Robin
Hello Robin, Monday, July 20, 2009, 6:24:49 AM, you wrote:
Why does the FFI specification define CStringLen as (Ptr CChar, Int)?
1. i think it was done to simplify using the api 2. hugs usually don't used for data-massive apps, it's niche is learning and quick development -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On Sun, Jul 19, 2009 at 7:24 PM, Robin Green
While rewriting cautious-file to use ByteStrings and FFI just now, I came across this potential problem:
Why does the FFI specification define CStringLen as (Ptr CChar, Int)?
Do you think it was a typo and the author(s) meant (Ptr CChar, CInt) ? Jason
participants (3)
-
Bulat Ziganshin -
Jason Dagit -
Robin Green