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

[Peter Ross]

On Fri, Mar 30, 2001 at 11:28:21AM +0200, Nancy Mazur wrote:
> > 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. 
> 
I think that the general rule is that foreign code may have aliases
between the float values.

Note the nasty example given by Fergus is actually safe because the
modes are di/uo so it doesn't matter that the floats are aliased.
However if the code was in/out instead and did some operation that just
copied the pointers to the boxed values then observation of Fergus is valid.

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