runtime should kill when assigning to an unallocated pointer (was: returning pointer to a local variable) about voc HOT 21 OPEN

I don't understand the issue, except that s^ := a; tries to assign a value to an unallocated pointer and this is a runtime error.
Without that statement, str() would return NIL.

Am I missing something?

from voc.

no, runtime error doesn't happen there.
it happens when main is called and Out.String is called with the s^ which points to the unexisting location in the stack segment. therefore - segmentation fault, it tried to access memory it should not.

from voc.

what i thought is - I would like to make a warning at the line

RETURN s;

because s is a pointer to variable allocated on stack.
when we get out of that function stack pointer changes back. and the memory, pointer points to, is inaccessible.

from voc.

omg, you are right.

from voc.

diegosardina's comment is correct. s doesn't point to anything, so assigning to s^ should give an error.

from voc.

so Oberon pointer should only point to the area allocated on heap with NEW, and that kind of error I wanted to illustrate is not possible in Oberon.

on the other hand, should we make a warning when there is an assignment to an unallocated pointer?

from voc.

The real issue is that the runtime doesn't halt the program in this statement:

s^ := a;

In Oberon (or any other strong typing language) segmentation faults must never exist.

Type safety implies memory safety.

from voc.

you mean the runtime should've been killed the program at that point.

from voc.

Of course.

from voc.

aside from that, what do you think about compile time warning?
this can be prevented at compile time too.

from voc.

For what I remember (I don't use an Oberon or Modula-2 compiler since long) the compiler would raise a warning that pointer variable s may not be initialised. However because nested procedures may access intermediate globals, this warning is likely to be false sometimes.

from voc.

I don't think it's feasible to reliably generate a compile time warning. Consider:

PROCEDURE foo( i: INTEGER ): string;
VAR
    s: string;
BEGIN
    IF i < 0 THEN
        NEW(s,10)
    ENDIF;
    RETURN s
END foo;

from voc.

thank you all, I will try several compilers, and will think of solutions.

from voc.

@svorkoetter I mean warning when parsing such an assignment. Now when I realized the problem is different.

from voc.

Unfortunately, the only 100% reliable solution is a run-time check.

At least in Oberon that is possible, since s is guaranteed to initialize to a null pointer.

The big problem with unsafe languages is not that they give a seg fault when assigning through an uninitialized pointer, but that they might not give a seg fault, but just quietly clobber some other data structure in your program.

from voc.

Same problem if parsing an assignment:

PROCEDURE foo( i: INTEGER; VAR a: arr );
VAR
    s: string;
BEGIN
    IF i < 0 THEN
        NEW(s,10)
    ENDIF;
    s^ := a;
END foo;

from voc.

voc already has some runtime checks and kills the program in some cases.
i think it is possible to implement the same for this case as well.

from voc.

yes, thank you for illustrations.

from voc.

This is even more troublesome for a parser:

PROCEDURE Test;
   PROCEDURE Allocate(); BEGIN NEW(s) END Allocate;
VAR
  s: String;
BEGIN  
  Allocate();
  s^ := "aaa";
END Test;

In general this kind of warning to be useful requires global analysis.

from voc.

I tested the above code with Oxford Oberon-2, indeed it raises a warning that is false in this case (it behaves like some old Modula-2 compilers).

It's my opinion that a warning that may be false sometimes is better than nothing (but fortunately this is the only case, allocating pointers globally via nested procedures is a bad practice. In Oberon-07 that code wouldn't compile).

Like some old Modula-2 compilers, the compiler should raise a warning if a pointer is not passed to NEW(), not assigned by a function procedure or not passed via a VAR parameter.

This doesn't guarantee that the pointer will be valid after, but... with that warning you wouldn't have opened this issue ;-)

from voc.

A warning that is sometimes false is useless, as the programmer becomes conditioned to ignoring it, and in this case, there's no way to get rid of the nuisance warning (compared to a warning that a variable is used before it is assigned a value in C; one can always just assign 0 to it, which is a cheap operation compared to allocating memory).

from voc.