View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000332 | LDMud 3.6 | General | public | 2005-01-03 13:02 | 2022-01-09 21:33 |
| Reporter | randalar | Assigned To | Gnomi | ||
| Priority | normal | Severity | trivial | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.3 | ||||
| Fixed in Version | 3.6.5 | ||||
| Summary | 0000332: Warning: Missing 'return <value>' statement. | ||||
| Description | While I find the warnings regarding no return statements quite useful, it seems to not always grasp what the function is doing, and gives warnings when I would rather it not :) Here is an example: int my_func(string s) { if (!s) return 0; switch(s) { case "this": return 1; case "is" : return 2; case "a" : return 3; case "test": return 4; default : return -1; } } this causes a warning to be generated. However, I can add one line and the warning goes away: int my_func(string s) { if (!s) return 0; switch(s) { case "this": return 1; case "is" : return 2; case "a" : return 3; case "test": return 4; default : return -1; } return -1; } Should I always put in redundant return statements? (Of course, I may be missing something obvious that doesn't make this redundant :)) | ||||
| Tags | No tags attached. | ||||
| related to | 0000084 | closed | LDMud 3.3 | Make pragma warn_missing_return default off |
|
|
This is a limitation caused by the single-pass nature of the LPC compiler: this particular check doesn't do proper control flow tracing, but instead checks the last generated bytecode. I'm afraid the only resolution at the moment is to enter additional returns. At least I can say that the LPC compiler is not alone in this kind of limitation: one of the compilers I use at work tends to complain about uninitialized variables even if the control guarantees that the initializer will be executed. |
|
|
Ah, thanks for the explanation. I appreciate it. :) |
|
|
We have the same problem for many files using switch(). Maybe this issue will be 'fixed' some day, here is another suggestion: If the switch() has a default: case with return, the code below the switch() is unreachable and should generate a warning too. Knowing, that all changes now to avoid this warning would lead to 'unreachable code warnings' in future, but this is the right behaviour in my eyes. But I understand, that the LPC compiler is not able to handle this at the moment. It depends on the order of 'case' and 'default' too and maybe other issues. We just found the pragma to switch it off. This should be OK. Thanks. |
|
|
re: hkremms it's not that simple because you can break out of a switch with break; also the default: branch is not necessarily the last one in the switch. you'd really have to build a control flow graph to handle this properly. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-01-03 13:02 | randalar | New Issue | |
| 2005-01-03 22:57 |
|
Note Added: 0000283 | |
| 2005-01-03 22:57 |
|
Status | new => acknowledged |
| 2005-01-04 07:55 | randalar | Note Added: 0000284 | |
| 2005-12-06 10:07 | hkremss | Note Added: 0000447 | |
| 2005-12-06 10:10 | hkremss | Note Edited: 0000447 | |
| 2005-12-06 10:23 | hkremss | Note Edited: 0000447 | |
| 2006-01-01 04:11 | fufu | Note Added: 0000463 | |
| 2008-12-29 18:59 | zesstra | Project | LDMud 3.3 => LDMud 3.5 |
| 2009-01-08 05:13 | zesstra | Relationship added | related to 0000084 |
| 2021-04-09 14:01 | Gnomi | Assigned To | => Gnomi |
| 2021-04-09 14:01 | Gnomi | Status | acknowledged => assigned |
| 2022-01-09 21:33 | Gnomi | Project | LDMud 3.5 => LDMud 3.6 |
| 2022-01-09 21:33 | Gnomi | Category | Implementation => General |
| 2022-01-09 21:33 | Gnomi | Status | assigned => resolved |
| 2022-01-09 21:33 | Gnomi | Resolution | open => fixed |
| 2022-01-09 21:33 | Gnomi | Fixed in Version | => 3.6.5 |
