[M3devel] reference to globals in globals?
Rodney M. Bates
rodney_bates at lcwb.coop
Fri Aug 17 20:51:12 CEST 2012
On 08/15/2012 07:55 PM, Hendrik Boom wrote:
> On Wed, Aug 15, 2012 at 09:51:41AM -0500, Rodney M. Bates wrote:
>> On 08/14/2012 10:04 PM, Jay K wrote:
>>> Heck, even if these weren't global, is it that unreasonble,
>> >from the programmer's point of view, for the language/compiler
>>> to do some pointer escape analysis and let me take the address
>>> of a local, as long as I don't store it somewhere that outlives
>>> the local?
>> This is ultimately an undecidable problem and even conservative
>> approximations of reasonable sophistication are far too involved
>> for a language to require of every compiler.
> Not to mention the obscurityof the language definition.
> But isn't there something like that with the addresses of top-level
> proocedures? the ones whose environments are completely static?
> Or am I thinking of another type-safe language? Or am I thinking of
> assigning the procedures themselves?
> -- hendrik
>> Of course, safe languages occasionally make you unnecessarily write a bit more
>> code to do it the safe way. E.g., the famous fake pointer to the root of a
>> linked list example.
> You mean something like (in C with probable errors)
> list **p, *q;
> make q point to some linked list
> for ( p = &q; *p != NIL; p = &((*p)->next))
> And here you can easily delete elements by *p = (*p) -> next
Hmm, this is not quite what I had in mind, but it's close.
I like to code things like this with a pointer to the interesting
node _and_ one that lags one node behind, in case list surgery is
needed. Also, a more complete example would refer to one or more
data fields of a node too. But I think I can illustrate my intentions
with your example.
> This can be done prefectly type-safe in languages that allow
> REF REF list
Plus, an ADR/& operation. In the case of C's &, it's type at
least remembers the type of the object whose address is taken.
Modula-3's ADR does not, so would require a LOOPHOLE as well.
But no matter, because an operator that can take the address of anything
other than a heap object (or maybe a component of one?) is unsafe.
> Or is there some other fake pointer trick you're talking about?
> -- hendrik
More information about the M3devel