On 22 January 2005 23:53, John Meacham wrote:
The FFI spec says (in section 6.2) that CFile represents the C type
'FILE' and has Eq and Storable instances.
Is this a mistake? FILE is opaque and AFAIK, you can't copy or
compare its contents and expect it to work. I can think of two
possible
On 15 October 2004 10:25, Axel Simon wrote:
for Simon M: conceptually it would be nicer if GHC uses it's private
version of GMP.
Yes. This has been discussed on the GHC User's list (recently I
believe). Ideally we'd like to replace GMP with something else.
Alternatively, GHC could just use
On 04 July 2004 23:54, Sven Moritz Hallberg wrote:
Dear Foreign Function Interface,
why does a program like the following fail with a loop exception
(using GHC 6.2 on MacOS X)?
-snip-
import Foreign
main =
do
f - mkFinPtr finalizer
fp -
On 25 June 2004 15:09, Daan Leijen wrote:
Ok, I never thought of that. However, isn't it the case
that I normally just want to get the old value back?
In that case, the current interface is not so friendly.
Is anyone using this function to get something else than the
old/new value *and*
On 25 June 2004 11:30, Daan Leijen wrote:
Is there anyone who knows why atomicModifyIORef has type:
IORef a - (a - (a, b)) - IO b(1)
Instead of:
IORef a - (a - a) - IO a (2)
It seems to me that returning the old value is always good
enough right?
Something came up on the GHC list which made me realise that a slight
clarification is needed in the FFI spec. FinalizerPtr is defined as:
type FinalizerPtr a = FunPtr (Ptr a - IO ())
However, there is no way to specify what the calling convention for a
FunPtr is. The calling convention is
On 16 April 2004 11:33, Marcin 'Qrczak' Kowalczyk wrote:
Perhaps we should differentiate by a calling convention between
linking to a function directly and generating a source-level C call?
The calling conventions we know would correspond to linking to them
directly. They would perform the
On Thu, Apr 08, 2004 at 10:18:24AM +0100, Alastair Reid wrote:
Now that I understand the problem, my feeling is that the
problem is not with
curses but with GHC's compilation method. GHC is using a
shortcut by
pretending that the ffi is for interfacing to cpp+C whereas
the ffi is
Alastair Reid wrote:
[...] where the decision to insert parens is decided by a
command-line flag. [...]
I'm still not convinced that any change is really necessary,
but I'd really
prefer a command-line flag over a change in the FFI syntax.
The latter will
lead to much more
The suggestion wasn't to rename it, but to move it from base
to haskell98.
Then you could add these functions without changing the
interface of any
of the modules listed in the FFI Addendum.
That would amount to saying that 'Foreign' isn't a hierarchical library
any more, and anyone
I think adding new (hierarchical) modules is the way to go for now.
1) Hierarchical because it lets us use some nice clear
module naming style like:
Foreign.NonStd.*
or
Foreign.Extension.*
[I favour the former since the status of the lib is clearer.]
Not wanting
I think we need to decide how the further development of the FFI will
proceed. Given that Version 1.0 of the Addendum is frozen, I
am not in
favour of changing the Addendum anytime soon and certainly
not for small
matters, such as a convenience function.
We might want to accumulate
[ forwarded to [EMAIL PROTECTED] ]
In the current implementation there is no way to
force finalization of the foreign ptr if there are
still references to it. In this scenario
the finalization will be executed during the next
garbage collection. In some cases it is known that the
On Fri, Nov 14, 2003 at 01:57:41PM +1100, Manuel M T
Chakravarty wrote:
These marshalling routines convert Haskell's Unicode
representation for characters into the platform-specific
encoding used for \code{wchar\_t} and vice versa. In
particular, on platforms that represent
I have put RC 14 at
http://www.cse.unsw.edu.au/~chak/haskell/ffi/
including all the feedback on RC13. Please especially have
a look at Section 6.3 (Section CString), where some of the
wording changed.
The spec is silent on how exactly a Haskell Char is translated to a
CWchar, and
When linking a program with Haskell Code (also the main program),
and interfacing to C functions (a lib*.a C++ application
library is also combined),
the following error occurs:
c:/ghc/ghc-6.0/libHSrts.a(Main.o)(.text+0x86):Main.c:
undefined reference to
`__stginit_Main'
3) link against another library such as libunicode which provides its
own classification routines (this could be done optionally at compile
time...)
libunicode is no good, I tried it. It only recognises Unicode
characters up to '\x'.
The only right way to do this, it seems, is to
In our new implementation of Data.Char.isUpper and
friends, I made the
simplifying assumption that Char==wchar_t==Unicode. With
glibc, this
appears to be valid as long as (a) you set LANG to
something other than
C or POSIX, and (b) you call setlocale() first.
The glibc
hmm.. how odd. I would consider it a bug, I think. I don't have a copy
of the ISO spec handy but will be sure to look up whether that is
conforming... It is certainly a malfeature if it is not a bug...
I fired off a message to [EMAIL PROTECTED], we'll see what they have to
say.
Cheers,
On Saturday 19 July 2003 12:51 am, Ross Paterson wrote:
Could the meaning of stdcall be broadened to the standard calling
convention for libraries on the native system, i.e. pascal on Win32
(as now) and ccall on Unix? It would save a lot of fuss
for interfaces
to portable libraries.
g'day everyone,
I'm getting segv's from a program using the FFI (ghc5.0x) on
MacOS X only,
i.e. not on Linux, my primary development platform.
So... does anyone have any tips for showing up dodgy uses of
the FFI wrt
memory handling? What settings for GHC's garbage collector
will
data Point
foreign import getMousePos :: Ptr Point - IO ()
foreign import getX :: Ptr Point - IO Int
foreign import getY :: Ptr Point - IO Int
vs
data Point = Point (Ptr Point)
foreign import getMousePos :: Point - IO ()
I like the second idiom. You are
Alastair Reid writes:
I strongly agree that we should definitely add the ability to
declare types
whose definition is provided externally. (i.e., provide the
feature that empty datatype decls currently provide.)
Before adding them, we need to agree on the semantics and
syntax (in
On Monday 02 June 2003 2:32 pm, Simon Marlow wrote:
Ok. But I still don't understand why the whole discussion
isn't moot.
I can't see how to acquire a value of type T that isn't bottom.
Whether you can acquire values of this type or not, we need
to give it a semantics.
We know
We routinely use code like this:
data Point
foreign import getMousePos :: Ptr Point - IO ()
foreign import getX :: Ptr Point - IO Int
foreign import getY :: Ptr Point - IO Int
The idea being that:
1) there is a foreign type (which might be called Point,
MousePos, point_t,
I don't think we have much choice about whether undefined
values are part of
the type. If you can create a value of that type:
x - derefPtr (px :: Ptr T)
I'm not following this. what exactly is derefPtr? The only analogous
function I can think of is Foreign.peek:
peek :: Storable
Manuel M T Chakravarty [EMAIL PROTECTED] writes:
-=- Changes since RC 9
* 6.2: All the types in CTypes must be newtypes that are exported
abstractly.
This change makes things highly inconvenient in nhc98. A newtype
can only be passed across the FFI in nhc98 if we
Judging by the silence that greeted my last posts re this a
couple of weeks
ago I suspect this is of no interest to anyone but me :-(
An extra couple of weeks cogitation on this hasn't really
changed MHO much
(other than I'm no longer so pessimistic about the safety of
my +
This is all fine, except that implementing finalizer ordering slows
down ForeignPtrs quite a bit, in particular mallocForeignPtr takes a
20% hit just allocating the IORef needed to store the list of
finalizers. Ideas for a better implementation are welcome.
Having obviously optimized
I don't think it was ever the intention that 'safe' should have a
guaranteed serialisation property. I think the idea was that
'threadsafe' was the most desirable, with 'safe' and 'unsafe' only
available for use if you wanted more efficiency and had some separate
guarantees that the extra
For a summary of the discussion, see
http://cvs.haskell.org/cgi-bin/cvsweb.cgi/haskell-report/ffi/finalizers.
txt
However, only Hugs implements this part of the spec at the moment.
It will be implemented in GHC before the next major release. I'm not
intentionally dragging my heels on this
Simon Marlow [EMAIL PROTECTED] writes:
However, only Hugs implements this part of the spec at the moment.
It will be implemented in GHC before the next major
release. I'm not
intentionally dragging my heels on this one, just haven't
got around to
it yet :-)
And of course
Just out of curiosity, what would happen if hs_exit were a noop? if it
left haskell initialized? I imagine there would be a space leak if you
expected the rts's heap storage to be reclaimed, but is there any
user-observable state which would cause programs to behave oddly? Just
curious
I haven't read Hans Boehm's paper (but will try to get a
copy once I am off this plane and have a decent Internet
connection again). While I understand the problems of
running finalizers at program exit, I think the OS plus
explicitly-called-clean-up-routine argument doesn't always
work
Manuel wrote:
[...]
* I want to get v1.0 of the spec fixed. We are really only
in bug fix mode for quite a while and only the finalizer
problems held us back from finishing the spec.
That's OK and I understand your motivation. Let's finish v1.0 first.
I agree, but I don't have
1. part of this BDD library uses ints (not pointers) to identify
garbage-collectable objects. there's nothing in the FFI to
cope with this AFAICS. i could:
- hack the library (but would prefer not to).
- say the functions in question deal with Ptr CInt, and hope
sizeof(int)
==
The current `modifyMVar`, though exception safe, is not
atomic in the
same way that the proposed `atomicModifyMVar` would be. Unless I
misunderstand, during the execution of `modifyMVar`'s second
argument, the
mvar is empty and could be filled by some other thread. With
Just some small questions: Are we really going to change the
signatures of
newForeignPtr and addForeignPtrFinalizer from those which GHC
has for ages
to the new C finaliser only ones? Why don't we use other names and
deprecate the old ones? And what are the plans in this area for GHC
That's what I expected. Would it be possible to include the
new functions
in 5.04.2? OK, that's an API change, too, but simple
additions are rather
harmless. If we don't include this stuff now, there is no
useful common ForeignObj API for GHC/Hugs/NHC in the near future.
Ok, I suppose we
Simon Marlow wrote:
[...] There was this, from Dean Herrington:
http://haskell.cs.yale.edu/pipermail/ffi/2002-October/000940.html
I don't have any strong feelings (I rarely do, where names are
concerned).
I would be happy with his proposal. We can leave the IORef
stuff
Ah, got you.
How about making ForeignPtr slightly more polymorphic so that
instead of
working only on 'Ptr a' it works on 'a'.
e.g., We'd have:
newForeignPtr :: a - Finalizer a - IO ForeignThing a
Hmm, interesting. This allows the implementation to divorce the object
you're
That was Ashley's original proposal, but SimonM responded in
http://www.haskell.org/pipermail/glasgow-haskell-users/2001-September/00
2290.html
http://www.haskell.org/pipermail/glasgow-haskell-users/2001-September/00
2304.html
I think I had the wrong end of the stick; or at least I hadn't
I was wondering whether there was any standard way to find HsFFI.h? I
can hardcode it into my makefiles for my own projects, but when i
distribute code, I end up having to add -I lines for every possible
location of it, usually multiplied by every compiler version
it supports
since that is
On Wed, Oct 30, 2002 at 09:12:01AM -, Simon Marlow wrote:
If this isn't possible, then you can extract the
information from the
output of 'ghc -v'. The relevant directory is in the
include_dirs field
of the rts package.
michaelw@stargate:~$ ghc
Do we still have atomicModifyIORef?
I don't know that there's that much point now that Haskell finalizers
are gone. I don't have a strong objection (esp. since it seems every
implementation now has it) but it doesn't seem so necessary now.
It ought to be significantly faster than using
| In the meantime, I'm glad we have got a new function
|atomicModifyIORef
| which I for one will use, when it gets into GHC's regular release.
Just before this gets out of the door... any chance of calling it
modifyIORef
and documenting that it's atomic? Sometimes names can
It has a different type:
atomicModifyIORef :: IORef a - (a - (a,b)) - IO b
modifyIORef :: IORef a - (a - a) - IO ()
It would break backwards compatability, but
modifyIORef_ :: IORef a - (a - IO a) - IO ()
modifyIORef :: IORef a - (a - IO (a, b)) - IO b
(both
Ok, I'm sad to say that the problem we recently uncovered to do with
finalizers sharing values with the rest of the program essentially kills
off the possibility of doing Haskell finalizers in systems without
proper concurrency support. I'm rather embarassed that I didn't notice
this before;
There's another problem with Simon's patch I haven't been able to pin
down: if you run the example, interrupt it at the right point and type
another expression, the finalizers run, but the expression is lost.
I can get it to fail another way too:
main = do
p - mallocBytes 64
What's the best strategy for accessing fields in someone
else's C struct?
Should I write my own glue file with accessor functions? Or
should I make
a Storable instance for the struct?
I wrote some stuff on accessing C structs from Haskell recently which
might be useful:
- If not, then how should enum values be declared in the FFI?
What you need to do is run a little autoconf-like program which
constructs a program containing a suitable example, runs it
through a
C compiler and tells you what's going on.
hsc comes very close but I'm not
I'd hoped that blockFinalizers would be useful for defining other
primitives but since it won't even work for GHC, I agree that PVar
will meet most of our needs. (An even simpler design might be to
extend our IORef implementations with 'atomicallyModifyIORef'.)
So, is this a design that
No, that's only a partial (and indeed very incomplete) solution. It
relies on the Java GC knowing that that particular reference to the
Haskell StablePtr is the only one that matters, and vice-versa for
the Haskell GC.
So you want StablePtrs to contain a reference count, a new
I don't know how to achieve the same goal with
atomicModifyIORef.
I do. To modify ioRef1 and ioRef2 simultaneously, write
atomicModifyIORef ioRef1 (\ contents1 - unsafePerformIO
ioRef2 (\ contents2 - blah blah))
The actual modification will take place when the result or
contents
Simon Marlow wrote:
[snip]
Don't you run into a problem even if the two threads use the same
ordering? Suppose
- thread 1 does the atomicModifyIORef, and gets preempted before
doing the seq
- thread 2 does its own atomicModifyIORef, and the seq. Thread 2
gets
Indeed, I very nearly implemented such a thing as part of the patch
I sent out. However, it didn't look trivial enough to implement so
I backed off. The blocked state needs to be saved restored at
various points: when starting a finalizer, when invoking a
foreign-exported function,
Also, this is a nested call to eval(), in a primitive, which can
invoke an IO action and therefore re-enter Haskell without going
through unsafePerformIO. Is that safe?
Yes, I think so. Most calls to IO actions from primitives are safe
and I believe these ones are too. (In some ways,
However even if Haskell finalizers + MVars are impossible in NHC, I
don't think Haskell finalizers + mutable state have to be. For
example another mutable variable we could have would be a PVar which
is always full and has functions [snip]
updatePVar (PVar ioRef) updateFn =
do
I guess the Hugs documentation should say that using unsafePerformIO
to call C which calls Haskell should be avoided.
Yes it should, if such behaviour can lead to strange crashes! Better
still would be to work out exactly what constraints are required on the
use of eval() from primitive
What hasn't been required is for the various data structures to be
in a consistent state at that point, and Haskell finalizers might
trip over those if run after GC. SimonM's patch ran them at a
different point, though.
It calls them in eval doesn't it?
eval is called by nearly every
Then I'll reformulate my question as a patch. [...]
Is there anything fundamentally wrong with this approach?
I still maintain that getting this to work, testing it and,
especially, maintaining it is a lot of work.
Isn't it worth a little effort? Requiring finalizers to be foreign
Actually in the current implementation the finalizers are not
attached to the ForeignPtr at all: it's the other way around.
Ah, I see.
Fortunately, I don't think my sketched implementation depended on such
an attachment since it added an attachment of its own. The design is
intended
I tell you what, I'll implement finalizer ordering if you
guys implement
full Haskell finalizers :-)
How about providing newForeignPtr as specified? (Or are you
still hoping?)
Still hoping ;-) The discussion seemed to stop without reaching a
conclusion last time. At least, I still
The spec says there are no guarantees on the order in which
the finalizers
are run. Doesn't this make this function almost impossible to use?
Suppose one finalizer frees the storage and the other cleans
up something
it refers to. I'd suggest running the finalizers in the reverse order
From: Antony Courtney [mailto:[EMAIL PROTECTED]]
While the FFI spec. is excellent, I'd really like to see a companion
document with real examples of how to use the FFI for the
easy, obvious
kinds of library interfacing tasks that are likely to arise
in practice.
There are quite a
RC 7 of the FFI Addendum is now available from
In adding mallocForeignPtr and friends to Hugs, I found
that I needed
the address of free to pass as a parameter.
There's no suitable way to generate free from
MarshalAlloc.free (the
obvious use of a Haskell wrapper would break
I'm afraid George's questions have also rekindled my curiosity about
whether implementing Haskell finalizers is really as hard as it sounds.
Much has been written, but I still don't think we've got to the nub of
the issue.
On the face of it, if you can implement 'foreign import ccall safe',
then
The FFI Addendum actually doesn't commit to which operations
are in the class. It just says defines all these ops to
have a context `Bits a', which is definitely the case. In
other words, you proposed implementation is valid by the
spec and your argument for it makes sense to me.
The
[...] using a ForeignPtr here, with free() as its finalizer, adds so
much overhead that [...]
Where is the overhead coming from? Is it the cost of a C call or the
cost of the standard malloc library?
It's the combined cost of
- malloc()
- creating a weak pointer to register the
1) Add these functions:
makeForeignPtr
:: Ptr a - FunPtr (Ptr a - IO ()) - IO (ForeignPtr a)
attachForeignPtrFinalizer
:: ForeignPtr a - FunPtr (Ptr a - IO ()) - IO ()
It is implementation defined whether the free functions are allowed
to call
I vaguely remeber that in the context of the withForeignPtr
discussion we where once trying to achieve some similar
effect (but couldn't come up with something that would
work). Do you remember?
Uh, my memory's a bit vague too :-)
For a long time we were trying to get cheap
Can you achieve the same performance gain by adding some
rewrite rules?
Perhaps you could try to spot
(=) malloc (\p - newForeignPtr p free)
Hmmm. Actually I'd like to do both: add the functions, because they
encapsulate a common case and guarantee a speed improvement if you use
On 12-Aug-2002, Simon Marlow [EMAIL PROTECTED] wrote:
I'd be equally happy (perhaps happier) if the header file spec was
removed altogether. In a sense, this would leave the
Haskell part of a
foreign binding even more portable, because it doesn't have
to specify
the names
System.Mem.performGC does a major GC. When would a partial GC be
enough?
I've described the image-processing example a bunch of times.
We have an external resource (e.g., memory used to store images) which
is somewhat abundant and cheap but not completely free (e.g.,
eventually you
At the moment, there are two kinds of initialisation done for each
module:
Both ELF and DLLs on Windows provide a way of specifying initializers.
Or, easier yet, since the user is already using the hs_init function,
you could use that. The way you'd do that in ELF is to define a
(no, I'm not sure why they're in the C section of the FFI
spec either).
Because they are for implementing calls to C code in Haskell
that is compiled to .NET ILX.
This doesn't mean that I want to necessarily defend them,
but this was the reason for their inclusion. Essentially,
What do you expect to happen if the finaliser calls a foreign
exported function?
Good question.
I do not expect that to work on any platform that has difficulty
implementing newForeignPtr (because you could use it to implement
newForeignPtr).
I don't know if it would be likely to
If someone could post an example of a hs and a c file and
how to compile
it with ghc, i would be very apreciative. I have looked at
http://www.haskell.org/ghc/docs/latest/html/users_guide/sec-ff
i-ghc.html
for a long time, and I can't figure out how to reproduce the
example. I
At 2002-07-05 01:17, Simon Marlow wrote:
If specifying a header file with a function prototype is allowed to
affect the generated code (i.e., the calling convention),
then it is
clear that the Haskell type does not completely determine
the calling
convention.
I claim
Of course, this ignores the detail that while the C compilers are
generating correct code, they may also be generating warnings about
alleged type errors - which can be a bit disconcerting.
It is an error, not just a warning, if the prototypes don't match.
GCC will complain loudly if
I just reread that section and can't see anything that contradicts the
idea that the FFI implementation ignores any header files provided.
For example, the phrase:
implements calls to C functions ... as if a function prototype for
the called functions is in scope
can be interpreted
-Original Message-
From: Alastair Reid [mailto:[EMAIL PROTECTED]]
Sent: 02 July 2002 18:34
To: Ian Lynagh
Cc: [EMAIL PROTECTED]
Subject: Re: More C interfacing issues
Firstly, some ncurses calls return a *WINDOW and others take one as
an argument but you never actually
Of course, this ignores the detail that while the C compilers are
generating correct code, they may also be generating warnings about
alleged type errors - which can be a bit disconcerting.
It is an error, not just a warning, if the prototypes don't match. GCC
will complain loudly if there's
section 5.5:
It's going to be really hard to implement ForeignPtr as specified.
The problem is that invocation of the cleanup function is triggered
by the garbage collector. I don't want the garbage collector to be
recursively invoked so I don't want the garbage collector to
I can't remember whether this has come up before, but to my surprise
I've just discovered that FFI foreign import declarations don't
contain enough infomration to be able to determine the correct
calling convention for a given C function.
I'd say it has all the information you need -
A revised version of the FFI Addendum including all issues
of the last discussion is now available from
Look good...
New stuff to check
~~
* Section 5.10: Extended handling of IOError (slight variant
of SimonM's proposal)
This is fine for now. The slight lopsidedness
Further additions to the FFI
IMHO, the FFI should really be self-contained and not rely
on other non-standardised extensions/libraries. Therefore,
I propose some additions.
This makes me slightly uneasy because the FFI specification will
conflict with the new
I'm probably about to get my head bitten off for this, but here goes:
would it be possible to move H/Direct in the direction of using the FFI
libs? For a few reasons:
- deprecated features are going to be removed at some point.
In fact, I've removed them all in the new Core Libraries.
* Silly combinations like an unsafe label or
a dynamic import with a given C-name don't exist.
But now we have all new silly combinations, like
foreign export dynexp foo :: ...
and
foreign export dynimp foo ::
and
foreign export foo foo :: ...
the extent
I still don't understand the dynamic library stuff related to
fname. Is
it a hint for a compiler to link against a given library? Any compiler
surely has some kind of option/pragma for this already. What should it
mean when there is a corresponding static lib, but not a dynamic one?
Most
Why is Word a GHC extension? Someone remind me?
Hmmm, I thought that the Word type itself is a GHC extension, the
hslibs docs for module Word only talk about the explictly sized
variants. OTOH the implementation exports Word, but for legacy
reasons, IIRC. If this is really the case, we
-- allowed for import/export
callconv : 'ccall' -- default
| 'wincall'
| 'stdcall' -- deprecated, same as wincall
| 'cplusplus'
| 'jvm'
| 'dotnet'
A totally minor point, but 'wincall' doesn't feel right. This
Alastair Reid writes (on the FFI mailing list):
ps I wonder if it'd be possible to merge them by doing this
in the hslibs repository:
1) Move the STG Hugs ifdefs out of the way:
find . -name '*.[l]hs' | xargs perl -p -i
-e's/__HUGS__/__STG_HUGS__/'
The __HUGS__ label made
hsc2hs is in ghc-4.11.
Did I miss the last 3 releases? I'm still stuck with
something between 4.08.1
and 4.08.2 waiting for a debian package and freebsd port to
appear for 4.08.2.
:-)
4.11 is the current devel version, which will be released as 5.00.
I submitted the 4.08.2 port to
On Fri, 23 Feb 2001, Fergus Henderson wrote:
OK, now how about things where you need to #define symbols before
including the header file?
Choose one:
1. Write a forwarding header which #defines and #includes.
2. Use compiler-specific switches to get #defines (-D and
-optc-D in
If we want to rule cpp as out of bounds (a very worthwhile
but difficult goal),
then we need to think about how to avoid conditional compilation too.
I think the goal is not to avoid the use of cpp, but rather to avoid
mentioning it in the spec. In practice, many people will be using cpp
foreign import ccall "gtk/gtk.h:gtk_window_new"
windowNew :: CInt - IO (Ptr Window)
If the . are omitted in the include specification, it
corresponds to an #include"...".
Don't forget you might need multiple includes, eg. sys/types.h
sys/socket.h for socket(), and ordering is
I've kept pretty quiet on this issue before, because I didn't have a
strong view. Now I'm concerned that some of the suggestions people are
making would take the design in the wrong direction.
* specifying libraries in the source isn't the right way to
go. Library names change
As usual the FFI "looks through" newtypes. But now that we have
FunPtr, the following typing makes much more sense:
'foreign' 'export' [callconv] 'dynamic' varid :: prim_type
- IO (FunPtr prim_type)
where both prim_types have to be the *same*. We should probably allow
the old
On Mon, 15 Jan 2001, Simon Marlow wrote:
data UnsafeCString
withUnsafeCString :: String - (UnsafeCString - IO a) - IO a
where an UnsafeCString is valid only in an argument position of an
unsafe foreign import.
Much of the conversion stuff would have to be done
1 - 100 of 107 matches
Mail list logo
