From: Thomas Fischbacher <Thomas.Fischbacher@Physik.Uni-Muenchen.DE>
To: Damien Doligez <damien.doligez@inria.fr>
Cc: caml users <caml-list@inria.fr>
Subject: On Store_field()
Date: Mon, 30 Jan 2006 14:12:39 +0100 (CET) [thread overview]
Message-ID: <Pine.LNX.4.63.0601301358220.6172@eiger.cip.physik.uni-muenchen.de> (raw)
In-Reply-To: <02FDC6F0-122C-42BA-A2F4-15E2B08248C8@inria.fr>
On Thu, 19 Jan 2006, Damien Doligez wrote:
> >However I strongly recommend instead
> >
> > StoreField(v,n,(value)(void*)p);
>
> This is the only way. Always use Store_field, Store_double_field,
> and Store_double_val.
What you *actually* forgot to tell people is that OCaml unfortunately
lacks a macro with which one can store C pointers to alloc_final
allocated blocks. If one writes to those using e.g.
ml_vector = alloc_final(2, finalize_vector, 1, 10);
Store_field(ml_vector, 1,(value)vector);
with vector being a C pointer to a structure, this may or may not lead to
random crashes at very unexpected places - because (as I think now) the
Store_field macro will be over-eager trying to tell the GC about the
value stored - which it should just ignore in this particular case!
Indeed, this has been discussed before, I think:
http://groups.google.de/group/fa.caml/msg/60ace9405fcf60c0?dmode=source&hl=de
So, I would strongly suggest introducing a macro that behaves like this:
#define Store_c_field(block,offset,x) (Field(block,offset)=(value)x)
so that one could then use
Store_c_field(ml_vector, 1,vector);
I actually just spent a full week tracking down precisely this issue in a
not particularly trivial C library interface I am building right now.
After looking in the weirdest places, ensuring it's not an issue with the
library wrapped, or the trickier pieces of my own code, I even started
patching debugging code into the OCaml bytecode's GC and rebuilding...
So, *please* do the world a great favour and tell people about that issue
in the C interface documentation!
--
Thomas Fischbacher
tf@cip.physik.uni-muenchen.de
(Yes, grumpy. Did not sleep over the weekend due to this issue...)
next prev parent reply other threads:[~2006-01-30 13:12 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-18 18:28 C interface style question Thomas Fischbacher
2006-01-18 19:18 ` [Caml-list] " Gerd Stolpmann
2006-01-18 20:32 ` Florent Monnier
2006-01-18 21:31 ` Gerd Stolpmann
2006-01-18 23:21 ` Florent Monnier
2006-01-18 23:43 ` Robert Roessler
2006-01-19 0:39 ` Jacques Garrigue
2006-01-19 3:17 ` skaller
2006-01-19 14:09 ` Damien Doligez
2006-01-19 14:17 ` Thomas Fischbacher
2006-01-19 14:24 ` Thomas Fischbacher
2006-01-19 14:52 ` Olivier Andrieu
2006-01-20 10:49 ` Damien Doligez
2006-02-12 20:40 ` Olivier Andrieu
2006-02-13 9:45 ` Damien Doligez
2006-01-19 15:15 ` Thomas Fischbacher
2006-01-30 13:12 ` Thomas Fischbacher [this message]
2006-01-30 14:05 ` [Caml-list] On Store_field() Olivier Andrieu
2006-01-19 12:13 ` [Caml-list] C interface style question Thomas Fischbacher
2006-01-19 13:49 ` Jacques Garrigue
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.63.0601301358220.6172@eiger.cip.physik.uni-muenchen.de \
--to=thomas.fischbacher@physik.uni-muenchen.de \
--cc=caml-list@inria.fr \
--cc=damien.doligez@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox