View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000632 | LDMud 3.3 | Implementation | public | 2009-04-29 03:49 | 2011-02-22 23:00 |
| Reporter | Gnomi | Assigned To | Gnomi | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | won't fix | ||
| Product Version | 3.3.718 | ||||
| Target Version | 3.3.719 | Fixed in Version | 3.3.719 | ||
| Summary | 0000632: Initializers shouldn't reference the initialized variable | ||||
| Description | From 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. | ||||
| Tags | No tags attached. | ||||
| Attached Files | 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;
}
| ||||
|
|
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; }); |
|
|
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.) |
|
|
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. |
|
|
Okay, I changed my mind and agree with Sorcerer. So I'll close this bug. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2009-04-29 03:49 | Gnomi | New Issue | |
| 2009-04-29 03:49 | Gnomi | Status | new => assigned |
| 2009-04-29 03:49 | Gnomi | Assigned To | => Gnomi |
| 2009-04-29 03:49 | Gnomi | Issue generated from: 0000631 | |
| 2009-04-29 03:49 | Gnomi | Relationship added | related to 0000631 |
| 2009-04-29 03:50 | Gnomi | Target Version | => 3.3.719 |
| 2009-04-29 05:52 | Gnomi | File Added: bug632.diff | |
| 2009-04-29 05:58 | Gnomi | Note Added: 0001068 | |
| 2009-04-30 02:07 | Gnomi | Note Added: 0001069 | |
| 2009-04-30 02:09 | Gnomi | Note Edited: 0001069 | |
| 2009-05-04 04:12 | Sorcerer | Note Added: 0001072 | |
| 2009-05-05 13:56 | Gnomi | Note Added: 0001081 | |
| 2009-05-05 13:56 | Gnomi | Status | assigned => resolved |
| 2009-05-05 13:56 | Gnomi | Resolution | open => won't fix |
| 2011-02-22 23:00 | zesstra | Fixed in Version | => 3.3.719 |
