Ticket #17 (closed defect: fixed)
c2hs assumes ccall when it should automagically support stdcall for ffi imports
|Reported by:||guest||Owned by:|
15:20 mae_work dcoutts: any plans to support stdcall in c2hs ? 15:20 mae_work it assumes ccall right now 15:20 mae_work trying to build some windows libs.. 15:20 mae_work for work 15:20 dcoutts mae_work: oh, I wasn't really aware of that issue 15:21 dcoutts mae_work: please file a ticket 15:21 dcoutts http://hackage.haskell.org/trac/c2hs/ 15:22 dcoutts mae_work: it'd have to be an extension to the call/fun syntax 15:22 dcoutts hmm 15:22 dcoutts unless it's visible in the header declaration 15:22 dcoutts in which case it could be automatic 15:23 dcoutts how are stdcall functions defined in Windows header files? 15:23 dcoutts I presume these are mingw's headers, not MS headers 15:23 mae_work yah 15:23 mae_work 1 sec 15:23 mae_work i think they are identifiable because of @ 15:23 dcoutts since c2hs can only parse GNU C not MS C 15:24 dcoutts mae_work: we don't know about the link level stuff, only the header declarations 15:24 dcoutts is it not a declaration attribute? 15:25 *** seafood quit () 15:25 mae_work BOOL WINAPI EnumProcesses(DWORD *,DWORD,DWORD *); 15:25 mae_work perhaps WINAPI means stdcall? 15:25 mae_work also, another request I have is to make the parms optional for #fun 15:26 mae_work right now i am putting #call in a module export 15:26 *** seafood joined #happs 15:26 mae_work example: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=3196#a3196 15:26 mae_work althought i actually think this syntax isn't half bad :) 15:27 mae_work if you want to purely let c2hs handle the type safety 15:27 mae_work and then do the rest in haskell 15:27 dcoutts hrm, that means c2hs has to parse Haskell 15:28 dcoutts to see if it's used in an export context 15:28 mae_work ok forget it then :) 15:28 dcoutts but not having to specify function args would be handy 15:28 mae_work dcoutts: um, i don't know quite what you mean, but if c2hs parsed for WINAPI, isn't this just parsing C? 15:29 mae_work and then it changes ccall to stdcall 15:29 dcoutts mae_work: WINAPI gets expanded by cpp 15:29 dcoutts the question is what it expands into at the level of raw C syntax 15:29 mae_work ic 15:29 *** dancor quit (Read error: 113 (No route to host)) 15:30 dcoutts http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Function-Attributes.html#Function-Attributes 15:30 dcoutts there's a stdcall attribute 15:31 mae_work expanded 15:31 mae_work BOOL __attribute__((__stdcall__)) EnumProcesses(DWORD *,DWORD,DWORD *); 15:31 dcoutts right 15:31 dcoutts ok, so that's doable 15:31 mae_work great :) 15:31 dcoutts the C parser already parses attributes, but ignores them 15:31 dcoutts they're not added into the AST 15:31 dcoutts so that'd need work 15:31 mae_work so all u have to do is change ccall to stdcall 15:32 dcoutts then c2hs would have to look for that attribute in the AST 15:32 mae_work dcoutts: great, well for the time being i was almost going to use hsc, but figured that this is worth spending the time to communicate :) 15:32 dcoutts mae_work: so when you file the ticket in the c2hs trac, ping the maintainer of the Language.C library 15:32 mae_work manual FFI types is something id on't wanna deal with 15:32 dcoutts mae_work: hsc2hs doesn't help here 15:32 dcoutts hsc2hs doesn't really help at all with function imports 15:33 mae_work i know it doesnt 15:33 mae_work the point is that this lib i am making doesn't work without stdcall 15:33 dcoutts yep 15:33 mae_work and short of doing sed s/ccall/stdcall i didn't know what to do 15:33 mae_work and that felt too hacky 15:33 mae_work : )
Note: See TracTickets for help on using tickets.