[m-rev.] For review: pretty print c_pointers as addresses

Mark Brown mark at csse.unimelb.edu.au
Tue Aug 15 16:37:18 AEST 2006


On 15-Aug-2006, Ralph Becket <rafe at csse.unimelb.edu.au> wrote:
> Mark Brown, Monday, 14 August 2006:
> > On 14-Aug-2006, Ralph Becket <rafe at csse.unimelb.edu.au> wrote:
> > > +
> > > +% This really should be impure...
> > > +%
> > > +:- func c_pointer_addr(T) = int.
> > > +
> > > +:- pragma foreign_proc("C",
> > > +    c_pointer_addr(X::in) = (Addr::out),
> > > +    [promise_pure, will_not_call_mercury, will_not_modify_trail],
> > > +"
> > > +    Addr = (MR_Integer) X;
> > > +").
> > 
> > If something really should be impure, then don't promise that it is pure.
> > But why should this function be impure?
> 
> I believe that foreign types also appear as c_pointers in deconstruct.
> If a foreign type has user defined equality then c_pointer_addr provides
> a way of distinguishing between otherwise semantically equal values.

For what values of noncanon_handling (the second argument of deconstruct)
does this happen?  If it happens for anything other than `include_details_cc'
then this would be a bug in deconstruct.

Cheers,
Mark.

--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------



More information about the reviews mailing list