> > > I refrained from proposing this in an earlier mail, but I've been
> > > thinking about it for a long time. I *really* *really* want to be
> > > able to insert small snippets of foreign code into the source of
> > > a Haskell module.
I *really* *really* don't want this.
The current Hugs im
> > I would let freeHaskellFunPtr accept and ignore nullFunPtr, since I
> > once had to write
> > when (ptr /= nullFunPtr) $ freeHaskellFunPtr ptr
> > and it can be seen as consistent with free.
This sort of behaviour is comon in C but I think this is mostly because C has
such a weak type sys
> Yes, Addr is dead. So, allowing Addr in f.e.d., or anywhere
> else for that matter, can only be for reasons of temporary
> backward compatibility.
Please note that this temporary backward compatability happens to be an
important part of most ffi code currently in existence (at least, all the c
use a
C++ programmer could use the exports from the Java library too), is simpler, is
more flexible, ...
Could someone summarise the minus side for me? I think I missed the motivation
for extending the ffi to support other languages.
--
Alastair Reid
ps Could I propose that any proposed new
re not keywords in any context except foreign language
> declaration. That's why I wrote "pseudokeywords".
I hope you don't mean anything like Haskell 98's "as", "qualified" and "hiding"
special identifiers? Those have to be one of the worst feature
> Alastair Reid wrote:
> > [...] ps I have a feeling of feeping creaturism as I watch this list -
> > a nice simple design seems to be getting more complex.
>
> Could you elaborate on this? The basic FFI *is* still nice and simple
> IMHO.
I'm thinking of:
1) Trying
> "Alastair Reid" <[EMAIL PROTECTED]> wrote,
>
> > Marcin wrote:
> > > This has the advantage that when the library name is #ifdefed, the
> > > conditional needs not to be repeated for each function. Similarly
> > > for #included header names
> So, as Marcin pointed out, the only use for a library object
> spec for ccall is so that interpreters know which handle to
> pass to dlsym().
This may be the only use but I think it's a very important use.
> I am not too fond of the idea that the interpreter has to try
> a dlsym() on all libra
>* specifying libraries in the source isn't the right way to
> go. Library names change independently of APIs, and can be
> platform-specific.
I like the high level goal this is heading towards and was in complete
agreement with implementing it in rules like this until I real
The first time I read this syntax, I misinterpreted it.
I think my misinterpretation might be interesting so I'll give it below in case
anyone else likes it.
> foreign library C"" "-lcurses"
> foreign library java "blah" "blah"
>
> foreign import C"curses_function" cf ::
> Marcin just pointed out that you can use dlopen() in a way
> that it finds symbols without a library name. That should
> do, I think.
Note that finding a marginally easier way to do the lookup doesn't address my
concern that this undirected search will cause maintenance and porting problems
by
While on the subject of preprocessors, I thought I'd mention a need I've found
in distributing tools like Knit where the intended audience isn't expected to:
1) Care either way about it being implemented in Haskell
2) Have any desire to spend half a day installing lots of Haskell-related tools
> 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.
:-)
[Serious content of which is that I'm absolutely _not_ interested in subjecting
users of my tools to the blee
join the knit-users or knit-announce mailing lists, send email to
[EMAIL PROTECTED] with, e.g, "subscribe knit-users" in the body.
Thanks go to DARPA for their support, and thanks go to the entire Knit
crew below, but especially Alastair Reid, for the fine research,
development, and hard work t
> Many C interfaces contain a significant number of macros. And C is
> one of the most widely used languages that we want to interface with.
> So it seems to me that any FFI which aims to provide *good* support for
> C ought to provide a way of accessing C macros.
Since an explicit goal of the o
> Many C interfaces contain a significant number of macros. And C is
> one of the most widely used languages that we want to interface with.
> So it seems to me that any FFI which aims to provide *good* support for
> C ought to provide a way of accessing C macros.
[Sorry for replying twice to th
> Should these functions be available through the standard FFI?
> IMHO they should.
I don't understand the question.
Are you asking which modules should export them?
Alastair
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listin
> Without a standard way to get
> at unsafePerformIO, such code would still rely on
> non-standard features, which goers against the aim of
> standardising the rest of the FFI.
The Hugs-GHC standard libs have them exported from IOExts.
Of course, the Hugs-GHC standard isn't an official Haskell l
> Sadly, due to lack of support on the Hugs side, the Hugs/GHC extension
> libraries have drifted apart.
Sadly true.
But any parts of the standard that haven't changed in the last 2.5 years (e.g.,
unsafe{Perform,Interleave}IO) still work - so in
this case it can be relied upon.
Alastair
ps I
> Alastair:
> > The Hugs-GHC standard libs have them exported from IOExts.
Manuel:
> There is only one flaw: It doesn't work with nhc98.
Huh?
I thought nhc provided a reasonable subset of the Hugs-GHC libraries and, since the IO
extensions are one of the first extensions
people ask for, I assu
I like this nice, simple design.
I'm a little uncertain about the multiple header-file aspect but have no strong
feelings either way.
If most libraries could be ffi'd without the need for additional C files, the
multiple header file notation would be an obvious win.
As it is, many libraries I
> Is anyone actually specifying
>
> stdcall
> ccall
>
> calling conventions in a foreign import?
hslibs/win32/Win32Dialogue.gc uses stdcall.
cvs annotate says that this was written by Sigbjorn in October 1999.
I'm not sure whether anyone depends on this.
(The HGL definitely does
> Why is Word a GHC extension? Someone remind me?
It's not part of the Hugs-GHC standard which is what
we were working to when the ffi first came out.
It's not part of that standard because it was felt at the
time that bounded types with ill-defined ranges were a portability
problem waiting to
> I don't agree that having a type of a fixed but unspecified size is evil.
> You can query the sise - you don't have to assume any particular size -
> and you have explicitly sized types as well.
I suspect we're never going to agree about this but perhaps we can
try to understand why the other f
But it is also used for exporting so the name doesn't seem that
inappropriate.
Unless you're arguing that, since it brings a name into scope it can
be thought of as a kind of import??? (But I don't think you are saying
that.)
--
Alastair Reid
ed. The H98 Committee in their infinite wisdom chose to
> have types with system-dependent sizes and I think, we should be as
> orthogonal as possible whether we like it or not.
But H98 doesn't have Word so I don't see a requirement to add it or to
provide ffi support for it.
By this, I mean, two logically
separate grammars (as in the current proposed syntax) instead of two
physically separated grammar (as, for example, if someone were to
provide a grammar for the C++ ffi binding as appendix G to the
report).
Is anyone else concerned
macros :-)
> Feature Request: Searchable archives at haskell.org/pipermail :)
That would be nice, wouldn't it.
(Hmmm, I think you can tell google to restrict its search to a
particular site - so maybe we could just use google.)
Hope this helps,
--
Alastair Reid
_
emented in
> haskell which an app wishes to link against.
You can implement the modified API (or your modified semantics) quite
readily as a little library which you link against your program. All
you have to do is tweak the names a little (e.g., s/hs/HS/) to avoid
name clash
was almost all done ages ago). That
leaves the question of whether we want to force Haskell implementations
to follow C conventions. I'm not sure.
Table 3 (section 6):
Proposed change:
Rename column 1 as 'Preprocessor symbol
might quickly use up a lot of memory - and in
all that time you don't go anywhere near the IO monad.
--
Alastair Reid[EMAIL PROTECTED]http://www.cs.utah.edu/~reid/
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
flag in the
foreign export wrapper code.
We could imagine getting the Haskell typesystem to check that
newForeignPtr' is only used with unsafe free functions. It'd be a bit
verbose but we could probably do it. There's not much point though since
C can't do a similar job on its
it is a greater burden it is not
a new burden unlike any they normally deal with.
3) If they're using GHC, they are free to specify that their imported
finalizer is 'safe' (or threadsafe) and that 'safe' finalizer can
happily call
t; right thing - you really want to do the allocation/deallocation
> explicitly in the IO monad.
Those kinds of applications exist - but there are many pure programs
for which ForeignPtrs work extremely well and for which it would be
painful to have to insert frequent calls to 'runFinali
se_Me Int
type DBP = Ptr DB
or
newtype DB = DB_Dont_Use_Me Int
foreign import ... :: blah -> IO (Ptr DB)
the idea being that no-one would ever use the data constructor or the Int.
I'm a bit puzzled by the double-layer of pointers though.
--
Alastair Reid[EMAIL PROTEC
o for a while (or, in less anthropomorphic language, it is an
opaque/abstract datatype).
--
Alastair Reid[EMAIL PROTECTED]http://www.cs.utah.edu/~reid/
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
there would be non-standard extensions which
let C programmers override the default alignment of a type.)
--
Alastair Reid[EMAIL PROTECTED]http://www.cs.utah.edu/~reid/
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
What exception does deRefStablePtr raise when handed an invalid
pointer such as 0?
--
Alastair Reid[EMAIL PROTECTED]http://www.cs.utah.edu/~reid/
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
er
> information.
Ok, if they're passed the same way and all we have to do is respect
the bottom bits, that's easy. Don't use the cast functions provided
by the Foreign libraries and all will be cool. (We might want to do
an audit of the libraries to determine which other func
inter.
Which brings me back to my question: _which_ exception should it raise?
--
Alastair Reid[EMAIL PROTECTED]http://www.cs.utah.edu/~reid/
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
ng to do seems to
be to return to the interpreters REPL.
--
Alastair Reid[EMAIL PROTECTED]http://www.cs.utah.edu/~reid/
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
if (next_depth == 0) {
minor_garbage_collect();
next_depth = 1;
return 1;
} else {
major_garbage_collect();
next_depth = 0;
return (pending_finalizers > 0);
}
}
--
Alastair Reid[EMAIL PROTECTED]http://www.cs.utah.edu/~reid/
ps
ts
rather than doing it a bit at a time and getting bits wrong because I
lack a complete enough picture.)
--
Alastair Reid[EMAIL PROTECTED]http://www.cs.utah.edu/~reid/
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
been freed then they should
return nullPtr? If so, is this required or just hinted/recommended?
> Either 'ErrorCall "Foreign.StablePtr.deRefStablePtr: invalid stable
> pointer"', or a new exception. I don't mind which.
I'll pick one and add my choice to t
f concurrency) it is hard to define
> what exactly is supposed to happen with such exceptions.
I'm not sure I see the difficulty - but I'll go ahead and make up my
own solution (which will probably be much like what GreenCard does...)
--
e I understand what would cause that
failure), it calls exit. A bit more error reporting seems to be
called for here...
--
Alastair Reid[EMAIL PROTECTED]http://www.cs.utah.edu/~reid/
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
is that anything legal on a link line is ok
(so all the above are kosher) but it may be sensible to limit it to
just the first 3 forms.
I'd like the spec to say what's legal and give at least one example.
--
Alastair Reid[EMAIL PROTECTED]http://www.cs.utah.edu/~reid/
__
and with Hugs comment on whether they'd be able to replace
the ffi's library spec and would make sense for typical Hugs usage.
And would that meet SimonPJ's need too?
--
Alastair Reid[EMAIL PROTECTED]http://www.cs.utah.edu/~reid/
ps The reason I'm wary
space and then
any dynamically loaded code or foreign imports would do lookups in
these files.
[Actually, Hugs probably would not use --lib= because Hugs
traditionally uses cryptic, confusing flag names...]
--
Alastair Reid[EMAIL PROTECTED]http://www.cs.utah.edu/~reid/
Sven:
> In a nutshell: I'm not very happy with the explicit allocation and
> deallocation of the 'foreign import wrapper' thunks. They are an
> artefact of the Haskell implementations and look strange in an
> otherwise GC-ed world...
I think they're explicitly deallocated (and, hence, explicitly
ing
dlopen).
2) It is useful for .net - though I didn't hear why this was supposed
to be relevant to people calling C.
I'd like answers to these questions that are clear enough that we can
agree on them and amend the spec to be clear.
--
Alastair Reid[EMAIL PROTECTED]
John Meacham <[EMAIL PROTECTED]>:
> however i would make one change, only the first
> calls to hs_set_hs_argv and hs_set_prog_argv are honored, after that
> they are ignored, that way if multiple libraries wish to set the
> arguments it wont run into undefined behavior. (since there is no
> way i
ble to implement the ffi by dlopening a bunch of .o, .a
and .so files and looking up symbols in them - with no C compiler
anywhere in the picture. IIRC, this is how ghci worked at one stage -
not sure if it still does.
--
Alastair Reid
[EMAIL PROTECTED]
deref r 1
free r
return (y,x)
or guess/check that getyx is really, really cheap to call and write two
wrappers gety and getx.
--
Alastair Reid
[EMAIL PROTECTED]
http://www.reid-consulting-uk.ltd.uk/alastair/
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
hey do. It's a shame C doesn't
support multiple return values and kinda surprising given that C is
like assembler in so many other ways.
--
Alastair Reid
[EMAIL PROTECTED]
http://www.reid-consulting-uk.ltd.uk/alastair/
___
FFI ma
> :: Ptr Window -> Ptr CInt -> Ptr CInt -> IO ()
> Have I missed something?
You need at least one wrapper because getyx is a macro. Note that the
arguments are ints _not_ int*s.
--
Alastair Reid
[EMAIL PROTECTED]
http://www.reid-consulting-uk.ltd.uk/alastair/
__
s)) if you
omit the %call line.
Roughly speaking, you use %call lines in the same places that you'd
introduce a wrapper in greencard.
So you don't tell it that it's a macro but you do write a %call line
and the code in the %call line will reflect the fact that you know it
is a macr
not they add prototypes. GHC: yes, NHC:
no, Hugs: depends which day you grabbed your copy from CVS.
(I'm not sure that the ffi should allow compilers to vary in this way
but it does.)
--
Alastair Reid[EMAIL PROTECTED]http://www.cs.utah.edu/~reid/
___
ties is found to change, I believe we
would change the ffi so that it is still feasible to generate correct
machine code without being given a function prototype by the user.)
Of course, this ignores the detail that while the C compilers are
generating correct code, they may also be generating warn
>> 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 i
Alastair:
>> (I'm not sure that the ffi should allow compilers to vary in this
>> way but it does.)
Manuel:
> The FFI doesn't really allow compilers to emit prototypes (at least
> not in general) as this leads to semantic differences eg in argument
> promotion, for which Section 4.1.5 precisely
Alastair:
>> Well, if you disable the warning by giving gcc a consistent story,
>> then the code is correct. (To give gcc a consistent story, don't
>> #include any user or system-supplied headers and make sure gcc
>> doesn't silently #include any of its own (as it likes to do).)
Simon:
> I don'
> Errm, shouldn't that be: [...]
> Or is there some other trick involved here?
Sorry, yes it should - just me getting confused in translating between
Haskell's
f :: A -> B
and C's
B f(A);
A
___
FFI mailing list
[EMAIL PROTECTED]
http://www.hask
combinations to worry about if the ffi is not portable but only n
combinations to worry about if the ffi is portable between
compilers.
--
Alastair Reid[EMAIL PROTECTED]http://www.cs.utah.edu/~reid/
___
FFI mail
Minor detail:
> typedef long long HsInt64;
Instead of writing your own definition, you can #include HsFFI.h
--
Alastair
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
> Sure, it's a problem, a bug in GHC, whatever. But I don't see a way
> around it!
Make the spec say that you have to have header files containing
prototypes to get correct results. It is not ideal but it is
something that can be readily implemented by all Haskell compilers so
we can get por
> [...] if we were somehow able to generate prototypes then there
> would be no type checking at all.
Here's 4 ways to get typechecking - all admittedly harder than relying
on the fact that your Haskell compiler invokes a C compiler as part of
its operation (as does Hugs - not trying to put GHC
;ll take a bit longer to add
that functionality and we can compile most (all?) of the hierarchial
libs without it.
--
Alastair Reid [EMAIL PROTECTED]
Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/
___
FFI ma
rom the standards point of view, I am
> actually *very* reluctant to introduce new names. On the other
> hand, reusing the old names will lead to a couple of unhappy emails
> from people using the old interface again.
But only a couple I conjecture.
--
Alastair Reid [EMAI
http://www.mail-archive.com/ffi@haskell.org/msg00539.html
--
Alastair Reid [EMAIL PROTECTED]
Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
write:
> foreign import "&" free :: FunPtr (Ptr CChar -> IO ())
>
> foo = do
> ...
> foreignPtr <- newForeignPtr cString free
> ...
All the rest of your code to manipulate ForeignPtrs remains the same.
(Well, there's a corresponding change in addForeignFinaliz
functions) and finding new names for the old functions (the ones with
closure arguments).
--
Alastair Reid [EMAIL PROTECTED]
Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
. Currently, there is a problem with the version
> that is in the spec and GHC in that GHC requires an extra argument
> to initialise modules. So, it all depends a bit on how far SimonM
> thinks its implementable.
Hugs doesn't have anything resembling hs_init at the moment so I can
> 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 start t
> Under .NET each DLL has its own namespace, so the [lib] spec is
> needed to disambiguate. Since it's a namespace issue, I'd feel
> better if on .NET the name of the C function took a different form
> (perhaps .) and [lib] is removed from the spec.
Isn't that just a different syntax for the sa
> Hmmm, the garbage collector is a black box and has its own
> complicated heuristics for managing memory usage, but you are
> describing a mechanism that depends rather heavily on certain
> assumed behaviours. At the least, that gives the garbage collector
> less flexibility to change its own b
> 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
special se
Can you achieve the same performance gain by adding some rewrite rules?
--
Alastair
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
wForeignPtr and addForeignPtrFinalizer
[GHC can go ahead and list them as non-standard extensions]
There's a minor issue about whether the old function names should be
reused (leaving GHC to come up with its own names) or not. I have
ceased to care either way.
--
Alastair Reid
ier (as the
withFoo functions do) or raised the level of abstraction.
I'm inclined to say: add it to GHC for now and prod us again once a
decent body of examples builds up.
--
Alastair Reid [EMAIL PROTECTED]
Reid Consulting (UK) Limited http
> Nevertheless, I think even without the tricks I'm using in GHC, the
> case where a ForeignPtr is used in conjunction with malloc()/free()
> is one which is likely to be optimisable in any system with its own
> memory management.
I wasn't meaning so much that only GHC could take advantage of it
> I thought we have settled this already. See my appended email from
> three weeks ago. The only reason I haven't changed it in the spec
> yet is that I wanted to give people time to object. Nobody has.
> So, I would deem this accepted (reusing the old function names btw).
Sorry, yes you had.
> The FFI spec says that the operations called 'shift' and 'rotate',
> shift and rotate their argument to the right. However, the GHC
> implementation in CVS shifts and rotates to the left, and is
> documented to do so.
> Who is right? FWIW, before I read any documentation I expected the
> und
> Alastair: it was your design originally I believe, any thoughts?
Actually, I think it was Lennart's - though he might disown our variant...
The change seems fine.
(Actually, it feels a bit like another instance of defining the
language to allow particular optimizations in particular tech
> So, my proposal is to:
> [...]
Another possibility is to say that we don't really understand the
issues well enough to put in the standard yet and just comment out
that section.
I think only GHC implements anything like this (correct me if wrong,
Malcolm) and they haven't used it in the way J
I think the thing to do is add the existing performGC to the standard
(perhaps giving it an hs_ prefix in the process) and leave development
of an extended version of the function for when the GHC folk (or
anyone else with a generational collector) decide they want a
forcefulness argument. Come
> I have changed this in the spec now. I attach the wording used in
> the spec.
Looks good.
A
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
> Errm, but in C there is no unified shift operator. You have << for
> left shift and and >> for right shift, and a negative shift is
> undefined.
[blush]
>> This makes the specification come out nice and clean - you're
>> multiplying the number by 2^n instead of 2^{-n}.
> Errm, but then righ
(i.e.,
the type the external library provides) instead of hs_stablePtr_t. In
particular, if I put a wrapper around an object so that I can attach a
reference counter, you somehow always find yourself faced with the
problem that a C library hands you a pointer to an unwrapped object
and you h
> Another conflict between the FFI spec and the current library
> implementation: the spec says
> "The function bitSize returns 0 for types that don't have a
> fixed bitsize (e.g. Integer)."
> whereas the current ghc implementation defines bitSize of Integer as
> a runtime error.
I think b
ptive
concurrency so it's no wonder that the ffi extension doesn't address
them. We could start working on a concurrency extension but that's a
different beast.
That said, we probably do need a few hooks to make Haskell talk to
other GCs better. See the paper I pointed at this aft
limited ways).
> If it's really impossible for NHC or Hugs to implement this, I think
> I would still rather it was left to the NHC and Hugs documentation
> to admit that exported Haskell functions basically don't work in
> some circumstances, rather than to the GHC doc
GCs to run simultaneously. Just thinking aloud, I wonder
if it would be any easier to implement? The communication would be
much the same ('I'm starting', 'I can reach X' and 'I'm done') but
there'd be no need to synchronize the GCs.
--
Alastair Reid
ecify that in a non-operational (i.e., implementation dependent)
way. We could insert the word 'full' and leave it to people's
imaginations?
--
Alastair Reid [EMAIL PROTECTED]
Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/
_
(using a finer-grained interface) if we didn't
provide it for them - only those who have real time programs
interfacing to Haskell would make use of the finer-grained interface.
--
Alastair Reid [EMAIL PROTECTED]
Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
Alastair:
>> (In the image processing example, images were megabytes and an
>> expression like (x + (y * mask)) would generate 2 intermediate
>> images (several megabytes) while doing just 2 reductions in
>> Haskell.)
Marcin:
> OCaml allows the programmer to specify an approximate amount of
> fo
> 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 the whole reason
ut more than just copying a small object over.
--
Alastair Reid [EMAIL PROTECTED]
Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
> ... maybe I'm being stupid, but I don't see what the problem is.
> Why can't mallocForeignPtr be implemented as:
> mallocForeignPtrBytes size = do
> r <- c_malloc (fromIntegral size)
> newForeignPtr r ptr_c_free
>
> foreign import ccall unsafe "malloc"
> c_malloc :: CInt -> Pt
> 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 seem to remember that Sigbjorn and Erik dealt with thi
1 - 100 of 216 matches
Mail list logo
