Re: [polyml] Null pointer and comparing CInterface.vol values

2011-11-13 Thread Phil Clayton 

On 11/11/11 20:18, Phil Clayton wrote:

I am currently implementing
type t
val null : t
val isNull : t -> bool
where type t = CInterface.vol. There is no problem doing this but I
wondered whether I could improve the CInterface structure to avoid
annoying little C library functions.


I have realized that C functions are not necessary to implement these - 
just to toClong and fromClong:


  val null = toClong 0
  fun isNull v = fromClong v = 0



Would it be at all controversial to include
null : vol
in CInterface?


For a different reason, this could still be useful.  I had forgotten 
that volatiles do not persist in saved states or executables (it should 
have been obvious from the name) so I can't see how to create such a 
null value to implement


  val null : t

where type t = CInterface.vol.  (There is nothing volatile about null 
really.)


Perhaps the best approach here is to implement with type t = 
CInterface.vol option, with NONE representing null.


Phil


___
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml

[polyml] CInterface.setFinal pointer mismatch

2011-11-13 Thread Phil Clayton 
I am using setFinal to free a string (char *) whose pointer is returned 
via a parameter (char **) with address/deref to construct/destruct the 
char ** parameter.  Unfortunately, I cannot get this to work.


It seems that a function registered with setFinal is not always passed 
the C pointer (of the vol) that it was registered with, in particular, 
when the vol supplied to setFinal is derived from address/deref.  E.g.


   setFinal mycfun (deref (address v))

does not call mycfun with the same C pointer as for

   setFinal mycfun v

This seems like an issue to me but perhaps I have misunderstood something.

The attached example in eg1.tar.gz demonstrates this.  After unpacking,

   cd eg1/
   make bin  # build eg1.so
   LD_LIBRARY_PATH=.: poly < eg1.sml  # change glibc name if req.

See eg1.sml for details.

I have tried Poly/ML versions as follows:

  5.4   x86_64
  5.4.1 x86_64
  5.4   i386
  r1352 i386

and all have this pointer mismatch.  (With i386, the pointer passed to 
the C function is null whereas it is some nearby pointer with x86_64.)


Phil



eg1.tar.gz
Description: GNU Zip compressed data
___
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml