#10 should fail if variable defined later then used

v1.2
open
nobody
compiler (6)
2
2006-09-13
2006-09-13
No

Currently it is possible to use an unitialized variable
in felix, which leads to SIGSEGV if that variable is a
C++ class.

The error is triggered like that:
if (instance.someMethod()) do
instance := SomeClass();
done;

Of course, it's an obvioud error, but when writing a
large programm, it is easy to move some code above the
definition by mistake.

Basically, the following code should not compile:

if (len s > 3) do
print s;
s := "12345\n";
done;

Discussion

  • Artem Grinblat

    Artem Grinblat - 2006-09-13
    • priority: 5 --> 2
     
  • Erick Tryzelaar

    Erick Tryzelaar - 2006-09-13

    Logged In: YES
    user_id=41692

    Well that certainly doesn't look correct. I'll add that as a "code that should error
    out" regression.

    Also, Artem, are you on the felix-impl mailing list? I'd like to move this
    discussion over there as it's easier for the other devs to comment on.

    -e

     
  • Artem Grinblat

    Artem Grinblat - 2006-09-13

    Logged In: YES
    user_id=289741

    > Also, Artem, are you on the felix-impl mailing list?
    > I'd like to move this discussion over there
    > as it's easier for the other devs to comment on.

    From now on, i am subscribed to felix-impl.

     
  • John Skaller

    John Skaller - 2006-09-13

    Logged In: YES
    user_id=5394

    Yes, Felix allows uninitialised variables: this is not an
    implementation bug, but a design problem.

    The only way I know to fix it is data flow analysis, which
    is on the todo list, but not implemented.

    It may be possible to catch some cases with heuristics.

    Note that the code:

    if (len s > 3) do
    print s;
    s := "12345\n";
    done;

    will not segfault, because s is a string which is a mapped
    to a C++ string which is constructable type, and will be
    initialised with its default constructor.

    OTOH pointers are to NULL, so a deref of an uninitialised
    pointer will always cause a segfault (which is better than
    NOT segfaulting .. :)

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks