[MLton] Re: Type of _address?

[Matthew Fluet]

> On Thu, Jul 21, 2005 at 07:53:27AM -0400, Matthew Fluet wrote:
> > Is there really a problem with just having
> >   extern symbol;
> > if the address-of operation is always cast?
> 
> Well, I just get really scared when I see something like that.
> 
> There are platforms where pointers to different types are different, and
> casts don't always seem to work. I don't really understand the magic behind
> the scenes for alignment, bounce functions, etc. What I know is that if I
> keep the right type where it should be, then it 'just works'. If I start
> trying to cast pointers, invariably people have filed bug reports against
> my package on platforms I don't have.
> 
> Since we intend to make _address part of the documented API, I think it
> makes sense to cover the eventuality of having to deal with those systems.
> Even if we make no use of the type field yet, we have the option to later.

Makes sense.

> > > I am considering changing the _address syntax from:
> > >       _address "x": MLton.Pointer.t;
> > > to:   _address "x": MLton.Pointer.t, int;
> > >
> > > My reason for this is that I recall doing an 'extern foo;' caused trouble on
> > > hppa for profiling. I wonder if it will cause trouble in this case too...
> > > (ie: a char* pointer differs from an int* pointer)
> > 
> > That seems to make sense.  OTOH, the point of importing an address without 
> > the pointed-to type information is that one could then use arbitrary 
> > MLton.Pointer.{get,set}* functions on it.  The disconcerting bit is that 
> > the pointed-to type will now have absolutely no influence on the 
> > elaborated type.
> 
> Sure, and here I invoke your rule of: you are using the FFI, you had better
> have a good idea what you're doing! If you are using the FFI to unsafely
> cast between two different C types, well---you asked for what you get. =)

Excellent argument. ;-)

> I've managed to get 'define' working for the c-codegen, but I have no idea
> what to do about the x86-codegen. 

Actually, the way to get it working for all the codegens would be to 
incorporate exported symbols into  mlton/atoms/ffi.{sig,fun}.  That is the 
module that takes care of accumulating exported functions in order to 
declare them in headers and the C-code.  

Then you could drop the cty and export fields from Prim.FFI_symbol.  
(Sorry, my bad for suggesting that in the first place.  I forgot how we 
tracked exported functions.)

> It now includes 'allowFFI' to enable allow{Export,Import,Address,Symbol}.
> The _address now takes two types just like _symbol *. _symbol * and "x"
> both appear to work and are now using opaque types (thanks Stephen). I
> also changed the entire basis to use _symbol.

Great.

> From what I can do, I think it's good enough for a first commit, except that
> the FFI_Symbol { export=true } case is silently ignored by the x86-codegen.

Thanks a lot.  It looks really good.  I believe Stephen is travelling for 
the rest of this week, so I'll try to shepherd the patch in over the next 
couple of days.  If you want to take a whack at using the Ffi module to 
get exported symbols working, feel free, as I probably won't get to this 
until Friday evening.