View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000719 | LDMud 3.5 | LPC Compiler/Preprocessor | public | 2010-01-26 08:10 | 2014-02-23 23:03 |
| Reporter | zesstra | Assigned To | Gnomi | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Target Version | 3.5.0 | Fixed in Version | 3.5.0 | ||
| Summary | 0000719: Disallow returning values from void functions | ||||
| Description | Currently it is possible to return values != void from void functions: void voidfun() {return (void)get_eval_cost();} This should either be disallowed or the (void) cast should convert any value into 'void' (numerical: 0). Gnomi and me tend to the second possibility (convert to 0). | ||||
| Tags | No tags attached. | ||||
|
|
For the sake of consistency the second possibility will be the better one. On the other hand: is there any need for allowing a cast to void at all (just as a thought - though I still support the suggested solution 2)? |
|
|
The only reason I can think of is backward compatibility. But a real application for casts to void... No, I don't know one. mixed a = (void)nonvoidfun() currently works and I see no point in it. Some people use return (void)nonvoidfun(); in void functions. But I don't see any reason for doing this instead of nonvoidfun(); return; |
|
|
I also tend to cast any value to a numerical null instead of prohibiting the void cast. |
|
|
Mhmm... Implementing the (void) cast as basically F_POP_VALUE+F_CONST0 is clearly better for backward compatibility. On the other hand, it is somewhat inconsistent to the other (type) casts, which change the value only when it is known at compile-time. Additionally, the (void) cast serves no serious purpose and 'void' is no real type. I think, the lazy mudlib maintainer in me wins in this case. But maybe introduce the conversion and issue a warning at compile-time? Or probably better: make it an error in case of #pragma pedantic? |
|
|
I vote for the pedantic pragma :-) |
|
|
In my previous note the lazy mudlib maintainer spoke, too. From the programmers sight, I'd disallow casts to void. But part of pedantic? It looks like I should begin to use that for the corelib. :) |
|
|
Ok, there was no disagreement so far. Then my suggestion is: usually convert to numerical 0 but raise an error if pendantic is set. If I am not mistaken, we should be able to do that solely at compile-time, if we dis-allow the assignment of void to variables (void as type is already forbidden), because than any non-empty return can be forbidden/changed to returning F_CONST0. We discuss the assignment issue in bug 0000718. |
|
|
I just found out, the TYPE_VOID is incompatible to anything in check_rtt_compatibility() in the interpreter. Therefore returning anything from a void function will raise an error if the RTTC are active. When we add the implicit conversion to zero without pedantic, this should be kept in mind. |
|
|
Should be fixed with 0000721. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-01-26 08:10 | zesstra | New Issue | |
| 2010-01-26 08:46 | Sorcerer | Note Added: 0001704 | |
| 2010-01-26 10:32 | zesstra | Note Added: 0001707 | |
| 2010-03-03 16:52 | Coogan | Note Added: 0001748 | |
| 2010-03-04 14:32 | zesstra | Note Added: 0001759 | |
| 2010-03-05 13:11 | Bardioc | Note Added: 0001765 | |
| 2010-03-08 16:31 | Coogan | Note Added: 0001770 | |
| 2010-11-21 00:07 | zesstra | Note Added: 0001930 | |
| 2010-11-21 00:07 | zesstra | Status | new => confirmed |
| 2010-11-21 00:07 | zesstra | Relationship added | parent of 0000718 |
| 2010-11-21 00:43 | zesstra | Note Added: 0001932 | |
| 2014-02-23 22:57 | zesstra | Relationship added | related to 0000829 |
| 2014-02-23 23:02 | zesstra | Status | confirmed => assigned |
| 2014-02-23 23:02 | zesstra | Assigned To | => Gnomi |
| 2014-02-23 23:03 | zesstra | Note Added: 0002236 | |
| 2014-02-23 23:03 | zesstra | Status | assigned => resolved |
| 2014-02-23 23:03 | zesstra | Fixed in Version | => 3.5.0 |
| 2014-02-23 23:03 | zesstra | Resolution | open => fixed |
