View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000654 | LDMud 3.6 | General | public | 2009-06-03 13:20 | 2021-04-06 21:27 |
| Reporter | Gnomi | Assigned To | Gnomi | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | i686 | OS | Debian GNU/Linux | OS Version | 4.0 |
| Fixed in Version | 3.6.4 | ||||
| Summary | 0000654: lvalue 6: call-by-reference on efuns | ||||
| Description | sscanf and parse_command aren't efuns because we need special compiler magic so that its arguments get passed by reference per default. Other efuns don't respond well to explicit lvalues (lfuns don't care, but efuns respond with something like "Bad arg 1 to sin(): got 'lvalue', expected 'number/float'.") I'd like to allow efun definitions to specify whether its arguments have to be rvalues (default), can be lvalues (keyword "lrvalue"), or should be lvalues ("lvalue"). In the rvalue case all lvalues are automatically converted to rvalues when calling the efun (test_efun_args() can do this). In the lvalue case the compiler automatically generates the bytecode for protected lvalues (as it does for sscanf now). With this sscanf and parse_command can be made real efuns. This can be extended to object-internal lfun-calls, when a parameter is declared as <type> &var. | ||||
| Tags | No tags attached. | ||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2009-06-03 13:20 | Gnomi | New Issue | |
| 2009-06-03 13:20 | Gnomi | Status | new => assigned |
| 2009-06-03 13:20 | Gnomi | Assigned To | => Gnomi |
| 2009-06-03 13:21 | Gnomi | Relationship added | parent of 0000546 |
| 2009-06-03 13:21 | Gnomi | Relationship replaced | child of 0000546 |
| 2009-06-03 13:22 | Gnomi | Summary | lvalue 6: call-by-reference => lvalue 6: call-by-reference on efuns |
| 2021-04-06 21:27 | Gnomi | Project | LDMud 3.5 => LDMud 3.6 |
| 2021-04-06 21:27 | Gnomi | Category | LPC Compiler/Preprocessor => General |
| 2021-04-06 21:27 | Gnomi | Status | assigned => resolved |
| 2021-04-06 21:27 | Gnomi | Resolution | open => fixed |
| 2021-04-06 21:27 | Gnomi | Fixed in Version | => 3.6.4 |
