[M3devel] -new_adr the default?

[Rodney M. Bates]

Jay K wrote:
> I'd like to make -new_adr the default.
> It is more typesafe than the current way and finds bugs.
>   Granted, so far I think only bugs that I introduced.
> 
> 
> First I will make the tree compile either way.
>  Such as by fixing the bugs and resolving somehow the char vs. CHAR breaks.
> 
> 
> Changing this does break code, albeit only unsafe code.
>   There isn't much of that? Right? :)
> Sometimes that code had bugs, sometimes not.
> 
> 
> I believe type safety and static checking (and sometimes runtime checking) do have a place in unsafe code.
>  Maybe not as much as in safe code, but definitely still something.
> 
> 
> The old way is that ADR return ADDRESS, similar to void*, and it is silently convertable to any pointer type. I think.
                                                                 ^
Yes, but only in UNSAFE code.  OtherPointerType <: ADDRESS.
> 
> 
> The new way is that ADR(T) returns UNTRACED REF T is is only silently convertable to ADDRESS? 
                                                        ^
Yes, even in safe code, because of the same subtype relation.

Or nothing at all?
>  Esp. not silently convertable to UNTRACED REF U.
Yes, this would require an explicit LOOPHOLE.  Or, you could convert in two steps,
to a variable of ADDRESS first, then to UNTRACED REF U.  Both require UNSAFE.

> 
> 
> So there are buggy places that do:
> PROCEDURE Foo(UNTRACED REF T);
> 
> PROCEDURE Bar()
> VAR u: U;

Not sure what this is doing, but it seems like just changing to VAR u: T; ought
to work too.  It would compile with either semantics of ADR.

> BEGIN
>  Foo(ADR(u));
> END Bar;
> 
> 
> That compile with old ADR but not with new ADR.
> As I changed socklent_t between int and INTEGER, such code silently kept compiling.
>   But possibly silently corrupting the stack or producing the wrong data.
> 
> 
> This -new_adr feature was already implemented in the compiler unknown long ago.
>   I didn't know but Tony pointed it out.
> We should probably look at its impementation make sure we aren't switching on some buggy unused code.
> So far switching it on I've only seen correct new errors.
> 
> 
>  - Jay
>