Re: GNU C extension: Function Error vs. Success

[Shahbaz Youssefi <shabbyx at gmail dot com>]

On Tue, Mar 11, 2014 at 1:26 PM, David Brown <david@westcontrol.com> wrote:
> On 10/03/14 18:26, Shahbaz Youssefi wrote:
> You can tell the compiler about the likely paths:
>
> struct option_float inverse(int x) {
>         if (__builtin_expect(x != 0, 1)) {
>                   return (struct option_float){ .value = 1.0f / x, .succeeded = true };
>         } else {
>                     return (struct option_float){ .succeeded = false, .error_code =
> EDOM };
> }

True, but I was actually referring to the fact that like this, you
have to write the status to stack, where the return value resides,
while with a built-in method you could do away with returning it in a
register. This is not just for performance, but also to be compatible
with the previous ABI.

> I am not sure that it would be possible to get the sort of effect you
> are looking for without disrupting the syntax too much for a gcc extension.
>
> Speaking as an embedded developer who often wants to get the smallest
> and fastest code on small processors, it would be very nice is to have
> the ability to return an extra flag along with the main return value of
> a function.  Typically that would be a flag to indicate success or
> failure, but it might have other purposes - and it could be the only
> return value of an otherwise void function.  Key to the implementation
> would be a calling convention to use a processor condition code flag
> here - that would let you generate optimal code for the "if (error)
> goto" part.

I too am an embedded developer (with some kernel module programming
too) and what you say is another reason why I'd personally like to see
this happen. Thanks for the feedback.