Re: [Caml-list] NULL as a caml value

Re: [Caml-list] NULL as a caml value

[Damien Doligez]

>From: Christopher Quinn <cq@htec.demon.co.uk>
>> Does it even need to be word aligned?
>> If Is_long() tests positive the 'pointer' is also ignored.
>> I hope I have not erred!?

There are three cases to consider:

A. word-aligned
B. odd
C. equal to 2 modulo 4

>From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
>Otherwise, looking at the runtime's source, I see nothing that would
>prevent from using any (even non-aligned) pointer outside of the caml
>heaps to be cast to a value, but the manual does not allow it
>explicitly, so this may mean that such non-aligned even values could
>be used for something else. (Actually they are already used for
>compaction.)

Yes, compaction is the reason why non-aligned pointers are not allowed
by the documentation.  The compaction code will crash on case C.

So you can have it word-aligned, or odd, but not all arbitrary
pointers are allowed.  Be careful.  And compaction is now activated by
default (not in 3.04, but in the working version).

Don't ask me what happens on 64-bit machines, I'd have to look at the
source :-)

-- Damien
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] NULL as a caml value

[Lauri Alanko]

On Mon, May 13, 2002 at 04:20:35PM +0900, Jacques Garrigue wrote:
> Yes, NULL is valid, as are all word-aligned addresses outside of the
> Caml heap.

This probably ought to be mentioned in the manual... Unless there's a
perlish "the implementation is the specification" -attitude with ocaml.

> Of course it should be given an abstract type, since there is nothing
> you can do with it inside Caml.
>
> Note however that the statement about "memory allocated by malloc"
> being safe is to be taken carefully, since people have already
> reported strange bugs with the following scenario:
> 
> * allocate a data structure with malloc
> * get a direct pointer to it in caml
> * free the structure
> * expand the caml heap, unfortunately including the free-ed malloc block
> * your pointer is now seen as a pointer inside the caml-heap,
>   and followed by the GC, directly into a segmentation fault...
> 
> This is a rather improbable scenario, but better know it in advance.

The moment you free a structure without being absolutely certain that there
are no references to it anywhere in caml world, you are already asking for
trouble, so this isn't much of an additional setback.

> Better to limit direct pointers to structure that are not going to be
> free-ed, and use boxed ones otherwise.

Actually, I was going to use abstract-tagged blocks. I noticed, though, that
allocating them is a bother, since you have to calculate the size in fields
manually: (size + sizeof(value) - 1) / sizeof(value). An allocation function
for abstract blocks that takes a size in _chars_ would be a convenient
addition to alloc.h. Or even a macro that takes a type t and returns a
block of sizeof(t) casted to t*.

Also, there seems to be no direct way of getting the actual raw data pointer
for an abstract value v. Of course you can do (t*)v, but is that "portable"
in the sense of guaranteed by the FFI? I noted that in mlvalues.h there is a
macro Bp_val(v) that returns the pointer to data as char*, but this is not
mentioned in the manual, so I'm wondering whether this is a part of the FFI
or an implementation detail? The Correct way to do this at the moment seems
to be (t*)&Field(v, 0), which is not very clear and kind of lengthy.

I guess I'm just being a bit pedantic, coming from the Haskell world where
the FFI has (soon) a real implementation-independent specification...


Lauri Alanko
la@iki.fi
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] NULL as a caml value

[Jacques Garrigue]

From: Christopher Quinn <cq@htec.demon.co.uk>

> > Yes, NULL is valid, as are all word-aligned addresses outside of the
> > Caml heap.
> 
> Does it even need to be word aligned?
> If Is_long() tests positive the 'pointer' is also ignored.
> I hope I have not erred!?

Sure, then this is only an integer, and the GC does not follow integers.
Someone even suggested that you can avoid the strange scenario I
described in my previous mail by "marking" pointers, that is or-ing
them with 1. If they are word aligned, then you can easily recover the
original.

Otherwise, looking at the runtime's source, I see nothing that would
prevent from using any (even non-aligned) pointer outside of the caml
heaps to be cast to a value, but the manual does not allow it
explicitly, so this may mean that such non-aligned even values could
be used for something else. (Actually they are already used for
compaction.)

Jacques
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] NULL as a caml value

[Christopher Quinn]

Jacques Garrigue wrote:
> From: Lauri Alanko <la@iki.fi>
> 
>>The docs weren't very clear on this, so I just wanted to check: is
>>(value)NULL a legal caml value? Checking from the sources, it seems that the
>>GC does leave alone all pointers that don't point to within the caml-managed
>>heap. However, the docs state that only "memory allocated by malloc" can be
>>turned directly into an abstract caml value. So may I rely on NULL working?
>>It would ease dealing with many C interfaces.
> 
> 
> Yes, NULL is valid, as are all word-aligned addresses outside of the
> Caml heap.

Does it even need to be word aligned?
If Is_long() tests positive the 'pointer' is also ignored.
I hope I have not erred!?

- chris

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] NULL as a caml value

[Jacques Garrigue]

From: Lauri Alanko <la@iki.fi>

> The docs weren't very clear on this, so I just wanted to check: is
> (value)NULL a legal caml value? Checking from the sources, it seems that the
> GC does leave alone all pointers that don't point to within the caml-managed
> heap. However, the docs state that only "memory allocated by malloc" can be
> turned directly into an abstract caml value. So may I rely on NULL working?
> It would ease dealing with many C interfaces.

Yes, NULL is valid, as are all word-aligned addresses outside of the
Caml heap.
Of course it should be given an abstract type, since there is nothing
you can do with it inside Caml.

Note however that the statement about "memory allocated by malloc"
being safe is to be taken carefully, since people have already
reported strange bugs with the following scenario:

* allocate a data structure with malloc
* get a direct pointer to it in caml
* free the structure
* expand the caml heap, unfortunately including the free-ed malloc block
* your pointer is now seen as a pointer inside the caml-heap,
  and followed by the GC, directly into a segmentation fault...

This is a rather improbable scenario, but better know it in advance.
Better to limit direct pointers to structure that are not going to be
free-ed, and use boxed ones otherwise.

Cheers,

Jacques Garrigue
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] NULL as a caml value

[Lauri Alanko]

Hello.

The docs weren't very clear on this, so I just wanted to check: is
(value)NULL a legal caml value? Checking from the sources, it seems that the
GC does leave alone all pointers that don't point to within the caml-managed
heap. However, the docs state that only "memory allocated by malloc" can be
turned directly into an abstract caml value. So may I rely on NULL working?
It would ease dealing with many C interfaces.


Lauri Alanko
la@iki.fi
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners