I would like to share my experience of writing bad C bindings. The
following code is wrong, although no living in harmony with the
garbage collector rule seems to be violated:
value wrp_ml_cons (value v, value l)
{
CAMLparam2(v, l);
CAMLlocal1(cell);
cell = caml_alloc_small(2, Tag_cons);
On 08/16/2011 10:37 AM, Dmitry Bely wrote:
I would like to share my experience of writing bad C bindings. The
following code is wrong, although no living in harmony with the
garbage collector rule seems to be violated:
value wrp_ml_cons (value v, value l)
{
CAMLparam2(v, l);
2011/8/16 Török Edwin edwinto...@gmail.com:
On 08/16/2011 10:37 AM, Dmitry Bely wrote:
I would like to share my experience of writing bad C bindings. The
following code is wrong, although no living in harmony with the
garbage collector rule seems to be violated:
value wrp_ml_cons (value v,
On 08/16/2011 11:25 AM, Dmitry Bely wrote:
2011/8/16 Török Edwin edwinto...@gmail.com:
On 08/16/2011 10:37 AM, Dmitry Bely wrote:
I would like to share my experience of writing bad C bindings. The
following code is wrong, although no living in harmony with the
garbage collector rule seems to
-[ Tue, Aug 16, 2011 at 11:43:24AM +0300, Török Edwin ]
'list' should be reachable via caml_local_roots, so if it really gets an
invalid value
it sounds like a bug to me.
list may not be garbage collected (since it is indeed registered as the
root), but it may be moved arround (ie
On Tue, Aug 16, 2011 at 1:46 PM, ri...@happyleptic.org wrote:
-[ Tue, Aug 16, 2011 at 11:43:24AM +0300, Török Edwin ]
'list' should be reachable via caml_local_roots, so if it really gets an
invalid value
it sounds like a bug to me.
list may not be garbage collected (since it is indeed
On 08/16/2011 12:53 PM, Dmitry Bely wrote:
On Tue, Aug 16, 2011 at 1:46 PM, ri...@happyleptic.org wrote:
-[ Tue, Aug 16, 2011 at 11:43:24AM +0300, Török Edwin ]
'list' should be reachable via caml_local_roots, so if it really gets an
invalid value
it sounds like a bug to me.
list may
On Tue, Aug 16, 2011 at 01:21:02PM +0400, Dmitry Bely wrote:
On Tue, Aug 16, 2011 at 12:57 PM, Christophe TROESTLER
christophe.troest...@umons.ac.be wrote:
On Tue, 16 Aug 2011 11:37:03 +0400, Dmitry Bely wrote:
In the line
list = wrp_ml_cons(caml_copy_string(*s), list); /* bug!
-[ Tue, Aug 16, 2011 at 01:17:28PM +0300, Török Edwin ]
So a best practice would be to always use a temporary variable
registered with CAMLlocal* when you call a function that can potentially
invoke the GC?
I would say the best practive would be to not call an allocating
function from a
Mauricio Fernandez m...@acm.org wrote:
This has been in my mind for a while: why don't CAMLparamX declare the local
variables as volatile?
That would not help.
Passing the address of a local variable to an external function
warns the compiler that the variable may change when another
On Tue, Aug 16, 2011 at 05:51:38PM +0200, ri...@happyleptic.org wrote:
-[ Tue, Aug 16, 2011 at 04:25:50PM +0100, Richard W.M. Jones ]
I think this must be a bug in your C compiler. The address of list is
stashed in the roots struct, so the C compiler should know that list
can be
On Tue, Aug 16, 2011 at 5:06 PM, John Carr j...@mit.edu wrote:
Richard W.M. Jones r...@annexia.org wrote:
On Tue, Aug 16, 2011 at 11:37:03AM +0400, Dmitry Bely wrote:
C compiler first puts list pointer on stack and then calls
caml_copy_string(*s), potentially invalidating list. Of
On Tue, Aug 16, 2011 at 05:10:42PM +0100, Richard W.M. Jones wrote:
Well it would certainly help if we had a piece of runnable code to
look at. The code supplied in the original email contains an infinite
loop.
I missed there was another email later that contains the
fixed code (s++).
I'm
On Tue, Aug 16, 2011 at 08:18:48PM +0400, Dmitry Bely wrote:
On Tue, Aug 16, 2011 at 8:10 PM, Richard W.M. Jones r...@annexia.org wrote:
Well it would certainly help if we had a piece of runnable code to
look at. The code supplied in the original email contains an infinite
loop.
Yes,
Grrr now _my_ program has a bug.
--
#include stdio.h
#include stdlib.h
void f (int a, int b);
int g (void);
int *global = NULL;
int
main (void)
{
int x = 1;
global = x;
f (g (), x);
exit (0);
}
void
f (int a, int b)
{
On Tue, 16 Aug 2011, Richard W.M. Jones wrote:
Grrr now _my_ program has a bug.
FWIW i have asked Richard Henderson to share his opinion and he found
nothing wrong with memory.h and/or the OP's code, and believes it's a
compiler bug.
[..snip..]
--
mailto:av1...@comtv.ru
--
Caml-list
On 08/16/2011 07:27 PM, Richard W.M. Jones wrote:
Grrr now _my_ program has a bug.
--
#include stdio.h
#include stdlib.h
void f (int a, int b);
int g (void);
int *global = NULL;
int
main (void)
{
int x = 1;
On Tue, Aug 16, 2011 at 07:34:31PM +0300, Török Edwin wrote:
Undefined behaviour doesn't mean it must show different results with -O2,
it *might* if the compiler decides to do some optimization.
But isn't this 'f(g(), x)' issue the same as the classic example of undefined
behaviour with
-[ Tue, Aug 16, 2011 at 05:10:42PM +0100, Richard W.M. Jones ]
Nevertheless, the C compiler isn't allowed to just push 'list' blindly
onto the stack and assume it doesn't change across the call to
'caml_copy_string'.
For me,
wrp_ml_cons(caml_copy_string(*s), list);
with
19 matches
Mail list logo
