View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000649 | LDMud 3.5 | Runtime | public | 2009-06-03 11:58 | 2017-09-30 16:43 |
| Reporter | Gnomi | Assigned To | Gnomi | ||
| Priority | normal | Severity | tweak | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | i686 | OS | Debian GNU/Linux | OS Version | 4.0 |
| Fixed in Version | 3.5.0 | ||||
| Summary | 0000649: lvalue 1: Redesign T_LVALUE | ||||
| Description | As the first step I think, T_LVALUE should be redesigned. Now T_LVALUEs have a pointer to another svalue_t, which for unprotected plain lvalues is the lvalue itself, or for other lvalue types have a special type entry like T_POINTER_RANGE_LVALUE, which is only allowed to occur in an svalue_t where a T_LVALUE points to. This type then indicates how its pointer has to be interpreted to reveal more information about the lvalue. I'd propose that the lvalue type should be stored as a subtype of T_LVALUE (like the closure subtypes). And according to this subtype the .u entry in the lvalue is one of several special structures. I think, this is a more cleaner approach. T_CALLBACK and T_ERROR_HANDLER should also be moved as subtypes to a new T_META type. | ||||
| Tags | No tags attached. | ||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2009-06-03 11:58 | Gnomi | New Issue | |
| 2009-06-03 11:58 | Gnomi | Status | new => assigned |
| 2009-06-03 11:58 | Gnomi | Assigned To | => Gnomi |
| 2009-06-03 11:58 | Gnomi | Relationship added | child of 0000546 |
| 2017-09-30 16:43 | Gnomi | Status | assigned => resolved |
| 2017-09-30 16:43 | Gnomi | Resolution | open => fixed |
| 2017-09-30 16:43 | Gnomi | Fixed in Version | => 3.5.0 |
