caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
Cc: Thomas.Fischbacher@Physik.Uni-Muenchen.DE, caml-list@inria.fr
Subject: Re: [Caml-list] C interface style question
Date: Thu, 19 Jan 2006 14:17:36 +1100	[thread overview]
Message-ID: <1137640656.8943.183.camel@rosella> (raw)
In-Reply-To: <20060119.093955.97297811.garrigue@math.nagoya-u.ac.jp>

On Thu, 2006-01-19 at 09:39 +0900, Jacques Garrigue wrote:
> From: Thomas Fischbacher <Thomas.Fischbacher@Physik.Uni-Muenchen.DE>
> 
> > value-type parameters to C functions exported to OCaml should be 
> > registered with CAMLparamX(...). Does this hold in general, or is it 
> > considered acceptable/appropriate to just ignore this for "immediate" 
> > values that do not hold pointers, but, say, int, bool etc. values?
> 
> Registration is required to have the GC properly update the values.
> The GC may be called by any allocation.
> So it is only safe not to register a parameter (or a variable) in any
> of the following 4 cases.
> 1) you know that it can only hold a non-pointer value (int, bool, ...)
>    (i.e. the GC has nothing to update)
> 2) there are no allocations in your function
> 3) the parameter is not accessed after the first allocation
> 4) for a new variable whose contents is returned, there is no
>    allocation between the setting of the variable and return.
> 
> (1) and (2) are relatively easy to see, but (3) and (4) are a bit
> trickier (particularly with side-effecting expressions), so
> it is not a bad idea to register more parameters than strictly
> necessary.

Unless I'm mistaken, 'registration' with these macros 
is never required: these macros are simply a high level 
abstraction layer providing convenience and relative safety. 

The Ocaml manual explains all this fairly well IMHO,
the low level interface is well documented, Hendrik Tews 
version is cool:

http://wwwtcs.inf.tu-dresden.de/~tews/htmlman-3.09/manual032.html

See 18.5.2 -- IMHO the low level interface, whilst requiring
more work to apply, is actually easier to understand.

Just one 'BTW': I have seen some code using Field() macro
with incorrect C. You must NOT do this:

	MyType *p = ...
	(MyType*)Field(v,n) = p;

it isn't valid ISO C for *any* type MyType (not even 'value').
You would have to do it like this:

	*(MyType**)(void*)&Field(v,n) = p; // **

However I strongly recommend instead

	StoreField(v,n,(value)(void*)p);

The incorrect usage was not detected by older versions of gcc.
Gcc 4.x does detect this error. The workaround (**) is
the ONLY correct way to cast an lvalue in ISO C. This problem
arises in some larger codes where a macro has been used
to do the type conversion .. and it appeared to work
but was in fact invalid C. For example:

	#define MyThing(v) (MyType*)Field(v,2)

is not a good idea, since

	MyThing(v) = ...

is invalid ISO C but may not even produce a warning. You would
have to instead say:

	#define MyThing(v) (*(MyType**)(void*)&Field(v,2))

but it seems better to rewrite your code so values and
lvalues are distinguished by usage (eg 'get' and 'set' macros).
[The intention of the macros is usually to abstract away the
field number]

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net


  reply	other threads:[~2006-01-19  3:17 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-18 18:28 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 [this message]
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       ` On Store_field() Thomas Fischbacher
2006-01-30 14:05         ` [Caml-list] " 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=1137640656.8943.183.camel@rosella \
    --to=skaller@users.sourceforge.net \
    --cc=Thomas.Fischbacher@Physik.Uni-Muenchen.DE \
    --cc=caml-list@inria.fr \
    --cc=garrigue@math.nagoya-u.ac.jp \
    /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;
as well as URLs for NNTP newsgroup(s).