> Am 01.03.19 um 10:17 schrieb Philipp Klaus Krause:
>> The C standard does not allow returning expressions in functions
>> returning void. E.g. this
>>
>> static void attr_rtx (char *, char *);
>> static char *attr_string (char *);
>>
>> static void
>> attr_eq (char *name, char *value)
>> {
>> return attr_rtx (attr_string (name), attr_string (value));
>> }
>>
>> is not allowed by the standard. However, GCC allows it as an extension.
>> SDCC also currently allows it as an extension (i.e. when --std-cXX is
>> not specified).
>>
>> Is anyone using that extension functionality?
>>
>> There seem to be some bugs in it, and it might be easier to just
>> disallow it, as in the standard (i.e. giving an error message even for
>> --std-sdccXX), rather than tracking down the details of the bugs.
>>
>> Philipp
>
> For reference: SDCC used to allow it even when --std-cXX was specified
> until Maarten implemented the error message for that case in 2013.
>
> The current question is if that error message should be emitted
> unconditionally.
>
> Philipp
I think this is a very useful extension. I don't understand why this would
be allowed:
char foo1(void);
char bar1(void) { return foo1(); }
And this is not and therefor should be written differently:
void foo2(void);
void bar2(void) { foo2(); return; }
So when I decide to change the return type from char to void or v.v., I
have to modify all such invocations.
Typical use cases are of course error checking cases like:
if (error)
return log_error(error);
Which then must be transformed into:
if (error)
{
log_error(error);
return;
}
It would almost make you decide to always return a dummy value so you can
use the more compactly written source code at the cost of more bloated
generated assembly (and code space/ram).
IMHO: when the return types match (or are castable) allow it.
Maarten
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
