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

Nancy Mazur Nancy.Mazur at cs.kuleuven.ac.be
Fri Mar 30 19:28:21 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).

So, in any cases, it's safer to assume the general rule that
while aliases between real atomic types such as int, enum, etc cannot
occur, aliases between floats can. 

ok, 

Nancy
--------------------------------------------------------------------------
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