[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