View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000861 | LDMud | LPC Compiler/Preprocessor | public | 2018-02-04 00:04 | 2019-11-24 13:45 |
| Reporter | Gnomi | Assigned To | Gnomi | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Summary | 0000861: Variable initializer uses to-be-initialized variable | ||||
| Description | Given the following file:
int x = 42;
int fun() { int x = x - 1; return x; }
The function will return -1. Another case is where you want to catch variables by reference for a closure:
closure fun()
{
int a = 1;
return function int() : int a = &a { return a; }
}
Here funcall(fun()) will return 0 instead of 1. The reason is, that the expression at the right hand side of the assignment will already use the declaration left of the assignment operator. I think this behavior is not intuitive and should be changed. | ||||
| Tags | No tags attached. | ||||
| External Data (URL) | |||||
|
|
C has the same behavior (initializer uses the initialized variable). But most of the time it will result in undefined behavior. It's there, so you can take the address of the to-be-initialized variable and use that in the initializer. In LPC it would be the same with the reference operator, but I see even fewer use cases here than in C. |
|
|
I agree... I would prefer to use the existing variable until the initialization is complete... I assume, in case there is no existing variable in an outer scope, such an initializer will then cause an error? The other way, that it falls back to the to-be-initialized var would be not consistent I think. |
|
|
BTW: One of our wizards commented, he would expect that there would be warning that the inner/new variable shadows the outer one. |
|
|
The warning comes only if a local variable shadows another local variable. In the examples above (local variable shadowing a global variable, closure context variable shadowing outer local variable) the compiler currently doesn't give any warnings. |
|
|
Fixed in current master. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2018-02-04 00:04 | Gnomi | New Issue | |
| 2018-02-04 00:04 | Gnomi | Status | new => assigned |
| 2018-02-04 00:04 | Gnomi | Assigned To | => Gnomi |
| 2018-02-07 19:39 | Gnomi | Note Added: 0002454 | |
| 2018-02-07 23:37 | zesstra | Note Added: 0002455 | |
| 2018-02-26 20:26 | zesstra | Note Added: 0002457 | |
| 2018-02-26 20:50 | Gnomi | Note Added: 0002458 | |
| 2019-11-24 13:45 | Gnomi | Status | assigned => resolved |
| 2019-11-24 13:45 | Gnomi | Resolution | open => fixed |
| 2019-11-24 13:45 | Gnomi | Note Added: 0002494 |
