View Issue Details

IDProjectCategoryView StatusLast Update
0000719LDMud 3.5LPC Compiler/Preprocessorpublic2014-02-23 23:03
Reporterzesstra Assigned ToGnomi  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Target Version3.5.0Fixed in Version3.5.0 
Summary0000719: Disallow returning values from void functions
DescriptionCurrently 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).
TagsNo tags attached.

Relationships

related to 0000829 resolvedGnomi LDMud void * 
parent of 0000718 resolvedGnomi LDMud 3.5 Disallow assignments of 'void' values to variables 

Activities

Sorcerer

2010-01-26 08:46

updater   ~0001704

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)?

zesstra

2010-01-26 10:32

administrator   ~0001707

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;

Coogan

2010-03-03 16:52

reporter   ~0001748

I also tend to cast any value to a numerical null instead of prohibiting the void cast.

zesstra

2010-03-04 14:32

administrator   ~0001759

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?

Bardioc

2010-03-05 13:11

reporter   ~0001765

I vote for the pedantic pragma :-)

Coogan

2010-03-08 16:31

reporter   ~0001770

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. :)

zesstra

2010-11-21 00:07

administrator   ~0001930

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.

zesstra

2010-11-21 00:43

administrator   ~0001932

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.

zesstra

2014-02-23 23:03

administrator   ~0002236

Should be fixed with 0000721.

Issue History

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