View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000754 | LDMud 3.5 | Runtime | public | 2010-07-20 13:28 | 2011-02-13 21:38 |
Reporter | Sorcerer | Assigned To | zesstra | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Target Version | 3.5.0 | Fixed in Version | 3.5.0 | ||
Summary | 0000754: RTTC: error message during function argument checks does not handle lvalue correctly | ||||
Description | [Original title: RTTC does not recognize mixed when initialized with some specific type] Once a mixed variable is initialized with a specific type, an RTTC-error is thrown if I try to pass it by reference as another type. To reproduce: mixed data; data=1; funcall(function int (string test) { test="a"; },&data); This will yield: Bad arg 1 to __inline_w_sorcerer_LPC_zst_c_17_#0000(): got 'lvalue', expected 'mapping'. If I leave data uninitialized prior to the funcall or initialize it with a string (so the types match), no error will be thrown. One might argue whether this is a bug (mixed not recognized as mixed) or a feature (initialized mixed treated like the type it was initialized with). I rather consider it a bug since if I really decide to make a variable mixed (which I do only rarely) I want it to be a true wildcard with respect to its type. | ||||
Tags | No tags attached. | ||||
|
The error message is somewhat misleading, it should be "got 'number', expected 'string'." and this is imho entirely correct. The error message has nothing to do with the type the variable was declared with. The error message is about the call of a function that expects a string as its first parameter and gets a number (or a reference to a number, which is treated the same). |
|
I agree with Gnomi and think this error is essentially correct besides the wrong error message. The other way around would be an error of course (data being a string and test being mixed has to work). If you leave data uninitialized, it has the value 0 which is an element of any type and can therefore be assigned to any type, including strings. |
|
Ok, reading your views I agree, too. In the specific (historic) piece of code I came across this construct, the mixed was always only used to store an additional value set in the called function. But, of course, the function might also read from the variable and in that case it does matter what the current type is. So, please disregard my original request and only keep Gnomi's suggestion to replace lvalue by the actual type. |
|
BTW: Are you sure you get 'mapping' as being expected? If I try this at home 'string' is expected - as it should be. I know the cause for the 'lvalue' in the error message but I really don't know why it should expect a mapping. |
|
I believe this is fixed by r2929 - if your driver does not expect a mapping. |
|
'string' is correct - I copy&pasted the error message from another testcase by accident. So you can close this bug as fixed. Thanks! |
|
'string' is correct - I copy&pasted the error message from another testcase by accident. So you can close this bug as fixed. Thanks! |
|
Thank you :-) |
Date Modified | Username | Field | Change |
---|---|---|---|
2010-07-20 13:28 | Sorcerer | New Issue | |
2010-07-20 14:05 | Gnomi | Note Added: 0001881 | |
2010-07-20 14:20 | zesstra | Note Added: 0001882 | |
2010-07-20 15:08 | Sorcerer | Note Added: 0001883 | |
2010-07-21 15:03 | zesstra | Note Added: 0001884 | |
2010-07-21 15:53 | zesstra | Summary | RTTC does not recognize mixed when initialized with some specific type => RTTC: error message during function argument checks does not handle lvalue correctly |
2010-07-21 15:53 | zesstra | Description Updated | |
2010-07-21 15:55 | zesstra | Note Added: 0001885 | |
2010-07-21 15:55 | zesstra | Assigned To | => zesstra |
2010-07-21 15:55 | zesstra | Status | new => assigned |
2010-07-22 00:38 | Sorcerer | Note Added: 0001886 | |
2010-07-22 00:39 | Sorcerer | Note Added: 0001887 | |
2010-07-22 01:54 | zesstra | Note Added: 0001889 | |
2010-07-22 01:54 | zesstra | Status | assigned => resolved |
2010-07-22 01:54 | zesstra | Fixed in Version | => 3.5.0 |
2010-07-22 01:54 | zesstra | Resolution | open => fixed |
2011-02-13 21:38 | zesstra | Target Version | => 3.5.0 |