[m-rev.] [reuse] diff: no aliases between primitive types

Fergus Henderson fjh at cs.mu.OZ.AU
Fri Mar 30 19:17:28 AEST 2001


On 30-Mar-2001, Nancy Mazur <Nancy.Mazur at cs.kuleuven.ac.be> wrote:
> > On 30-Mar-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> > > I have been thinking about this, I think that for the MLDS backend we
> > > are safe.  However for the LLDS backend, we aren't.
> > 
> > Even for the MLDS back-end, where float arguments are passed unboxed,
> > there might be problems because floats in structures are boxed:
> > 
> > 	:- type foo ---> f(float, float).
> > 	:- pred nasty(foo::di, foo::uo) is det.
> > 	:- pragma c_code(nasty(X::di, Y::uo), "...").
> > 
> > where the "..." is some code relying on the representation of `foo',
> > which destructively updates the memory used for `X'...
> 
> Isn't that dangerous anyway? Defining a type declaratively, and
> then `relying' on the representation it will have internally? 
> Seems yuk to me.  Does this happen often? 

Relying on the representation?
Quite a few parts of the standard library implementation do it,
e.g. for `univ', and so do some of the modules in the extras,
e.g. extras/trailed_update/var.m and extras/lazy_evaluation/lazy.m.

Destructively modifying values of boxed floats?
No code that I know of does that. 
But there's no documented rule against it,
and I can imagine cases where it might be useful
(e.g. when using arrays of floats).

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------



More information about the reviews mailing list