View Issue Details

IDProjectCategoryView StatusLast Update
0000632LDMud 3.3Implementationpublic2011-02-23 00:00
ReporterGnomi Assigned ToGnomi  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionwon't fix 
Product Version3.3.718 
Target Version3.3.719Fixed in Version3.3.719 
Summary0000632: Initializers shouldn't reference the initialized variable
DescriptionFrom 0000631:

Sorcerer wrote:

  funcall(function int () {
            return funcall(function int () : int i=i {
              return i;
            });
          });

throws an error

Gnomi wrote:
The last one is a different problem, similar to the following:

  int x = 1; // global variable

  int fun()
  {
    int x = x;

    return x;
  }

fun() will return 0, because the initializer (= x) references the local variable not the global one. The same happens when initializing the context variable int i = i, the parser initializes the context variable i with itself but at that time the context doesn't exist yet, so an error is thrown.
TagsNo tags attached.

Relationships

related to 0000631 resolvedGnomi Inconsistent behaviour of nested inline closures 

Activities

2009-04-29 07:52

 

bug632.diff (2,276 bytes)   
Index: trunk/src/prolang.y
===================================================================
--- trunk/src/prolang.y	(Revision 2554)
+++ trunk/src/prolang.y	(Arbeitskopie)
@@ -6970,23 +7021,19 @@
           
           $$ = $1;
       }
-    | basic_type optional_star L_IDENTIFIER
+    | basic_type optional_star L_IDENTIFIER L_ASSIGN expr0
       {
-          define_local_variable($3, $1, $2, &$<lvalue>$, MY_FALSE, MY_TRUE);
-      }
-      L_ASSIGN expr0
-      {
-          init_local_variable($3, &$<lvalue>4, $5, $6.type);
+          struct lvalue_s lv;
+          define_local_variable($3, $1, $2, &lv, MY_FALSE, MY_TRUE);
+          init_local_variable($3, &lv, $4, $5.type);
           
           $$ = $1;
       }
-    | basic_type optional_star L_LOCAL
+    | basic_type optional_star L_LOCAL L_ASSIGN expr0
       {
-          define_local_variable($3, $1, $2, &$<lvalue>$, MY_TRUE, MY_TRUE);
-      }
-      L_ASSIGN expr0
-      {
-          init_local_variable($3, &$<lvalue>4, $5, $6.type);
+          struct lvalue_s lv;
+          define_local_variable($3, $1, $2, &lv, MY_TRUE, MY_TRUE);
+          init_local_variable($3, &lv, $4, $5.type);
           
           $$ = $1;
       }
@@ -7004,23 +7051,19 @@
           
           $$ = $1;
       }
-    | local_name_list ',' optional_star L_IDENTIFIER
+    | local_name_list ',' optional_star L_IDENTIFIER L_ASSIGN expr0
       {
-          define_local_variable($4, $1, $3, &$<lvalue>$, MY_FALSE, MY_TRUE);
-      }
-      L_ASSIGN expr0
-      {
-          init_local_variable($4, &$<lvalue>5, $6, $7.type);
+          struct lvalue_s lv;
+          define_local_variable($4, $1, $3, &lv, MY_FALSE, MY_TRUE);
+          init_local_variable($4, &lv, $5, $6.type);
           
           $$ = $1;
       }
-    | local_name_list ',' optional_star L_LOCAL
+    | local_name_list ',' optional_star L_LOCAL L_ASSIGN expr0
       {
-          define_local_variable($4, $1, $3, &$<lvalue>$, MY_TRUE, MY_TRUE);
-      }
-      L_ASSIGN expr0
-      {
-          init_local_variable($4, &$<lvalue>5, $6, $7.type);
+          struct lvalue_s lv;
+          define_local_variable($4, $1, $3, &lv, MY_TRUE, MY_TRUE);
+          init_local_variable($4, &lv, $5, $6.type);
           
           $$ = $1;
       }
bug632.diff (2,276 bytes)   

Gnomi

2009-04-29 07:58

manager   ~0001068

I attached a patch that postpones the declaration of a variable until the initializer was parsed. But the following situation needs special treatment:

  int a = 2;

  return funcall(
    function int() : int b = a; int c = b
    {
      return c;
    });

Gnomi

2009-04-30 04:07

manager   ~0001069

Last edited: 2009-04-30 04:09

In C and Java 'int x = x;' references the local variable. So in C you get an undefined result, Java shows a warning "The assignment to variable x has no effect" and an error "The local variable x may not have been initialized".

Do we want to keep that behavior? (The posted patch implements another behavior.)

Sorcerer

2009-05-04 06:12

updater   ~0001072

I strongly support keeping the C/Java-style behavior. In my above example, if you want to use i in the inline closure, you should simply use it from the implicit context.
Declaring somthing like 'int x = x;' can easily lead to confusions which variable is accessed at which point in the code.
Especially for unexperienced programmers (which is the main-clientele of LPC) this will make things more difficult than they have to be.
So I opt for at least issuing a warning if someone uses these constructs (an error with pragma pedantic) or even an error in either case.

Gnomi

2009-05-05 15:56

manager   ~0001081

Okay, I changed my mind and agree with Sorcerer.
So I'll close this bug.

Issue History

Date Modified Username Field Change
2009-04-29 05:49 Gnomi New Issue
2009-04-29 05:49 Gnomi Status new => assigned
2009-04-29 05:49 Gnomi Assigned To => Gnomi
2009-04-29 05:49 Gnomi Issue generated from: 0000631
2009-04-29 05:49 Gnomi Relationship added related to 0000631
2009-04-29 05:50 Gnomi Target Version => 3.3.719
2009-04-29 07:52 Gnomi File Added: bug632.diff
2009-04-29 07:58 Gnomi Note Added: 0001068
2009-04-30 04:07 Gnomi Note Added: 0001069
2009-04-30 04:09 Gnomi Note Edited: 0001069
2009-05-04 06:12 Sorcerer Note Added: 0001072
2009-05-05 15:56 Gnomi Note Added: 0001081
2009-05-05 15:56 Gnomi Status assigned => resolved
2009-05-05 15:56 Gnomi Resolution open => won't fix
2011-02-23 00:00 zesstra Fixed in Version => 3.3.719