View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000653 | LDMud 3.5 | LPC Compiler/Preprocessor | public | 2009-06-03 15:11 | 2017-09-30 18:49 |
| Reporter | Gnomi | Assigned To | Gnomi | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | i686 | OS | Debian GNU/Linux | OS Version | 4.0 |
| Fixed in Version | 3.5.0 | ||||
| Summary | 0000653: lvalue 5: Make explicit lvalues fragile | ||||
| Description | Explicitly created lvalues behave somewhat inconsistent. Sometimes they are automatically derefenced, sometimes not. int var = 10; mixed lv; lv = &var; /* typeof(lv) returns T_NUMBER. */ lv = ({ &var }); /* typeof(lv[0]) returns T_LVALUE. */ I think when pushing an element which is a protected lvalue onto the stack it has to be dereferenced. The only exception is pushing it as an lvalue on the stack (in the above example typeof(lv) and typeof(lv[0]) should return T_NUMBER, but typeof(&lv) and typeof(&(lv[0])) should return T_LVALUE). So conceptually lvalues are fragile, to keep them you have to use & everywhere you want to copy them.) This is also for security reasons: It shouldn't be possible to give an object an lvalue and observe the values it gets during its processing, unless the object preserves the lvalues by using &. That's why also x=fun() and x=&(fun()) have to be distinguished (if the former returns an lvalue it has to be changed to an rvalue). | ||||
| Tags | No tags attached. | ||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2009-06-03 15:11 | Gnomi | New Issue | |
| 2009-06-03 15:11 | Gnomi | Status | new => assigned |
| 2009-06-03 15:11 | Gnomi | Assigned To | => Gnomi |
| 2009-06-03 15:12 | Gnomi | Relationship added | child of 0000546 |
| 2017-09-30 18:49 | Gnomi | Status | assigned => resolved |
| 2017-09-30 18:49 | Gnomi | Resolution | open => fixed |
| 2017-09-30 18:49 | Gnomi | Fixed in Version | => 3.5.0 |
