This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GNU C extension: Function Error vs. Success

Hi Julian,

Thanks for the feedback.

Regarding C++ exceptions: exceptions are not really nice. They can
just make your function return without you even knowing it (forgetting
a `try/catch` or not knowing it may be needed, which is C++'s fault
and probably could have been done better). Also, they require
complicated operations. You can read a small complaint about it here: and I'm sure there are many
others on the internet.

Regarding OCaml option types: in fact I did think of this separation
after learning about monads (through Haskell though). However,
personally I don't see how monads could be introduced in C without
majorly affecting syntax and ABI.

Regarding the syntax: You are absolutely right. I don't claim that
this particular syntax is ideal. I'm sure the many minds in this
mailing list are able to find a more beautiful syntax, if they are
interested in the idea. Nevertheless, the following code:

    x = foo() + bar();

doesn't do any error checking. I.e. it assumes `foo` and `bar` are
unfailable. If that is the case, there is no need for a `!! goto
fail_label` at all. I personally have never seen such an expression
followed by e.g.

    if (x ....)
        goto foo_or_bar_failed;

On the other hand, something like this is common:

    while (func(...) == 0)

which, if turned to e.g.:

    while (func(...) !! break)


    while (func(...) !!= fail_code, fail_code == 0)

could seem awkward at best.

My hope is that through this discussion, we would be able to figure
out a way to separate success and failure of functions with minimal
change to the language. My syntax is based on having the return value
intact while returning the success-failure and error-code in registers
both for speed and compatibility and let the compiler generate the
repetitive/ugly error-checking code. Other than that, I personally
don't have any attachments to the particular way it's embedded in the
grammar of GNU C.

On Mon, Mar 10, 2014 at 3:50 PM, Julian Brown <> wrote:
> On Mon, 10 Mar 2014 15:27:06 +0100
> Shahbaz Youssefi <> wrote:
>> Feedback
>> ========
>> Please let me know what you think. In particular, what would be the
>> limitations of such a syntax? Would you be interested in seeing this
>> extension to the GNU C language? What alternative symbols do you think
>> would better show the intention/simplify parsing/look more beautiful?
> I suggest you think about how this is better than C++ exceptions, and
> also consider alternatives like OCaml's option types that can be used
> to achieve similar ends.
> For your suggested syntax at function call sites, consider that
> functions can be called in more complicated ways than simply as "bar =
> foo();" statements, and the part following the "!!" in your examples
> appears to be a statement itself: in more complicated expressions, that
> interleaving of expressions and statements going to get very ugly very
> quickly. E.g.:
> x = foo() + bar();
> would need to become something like:
> x = (foo() !! goto label1) + (bar () !! goto label2);
> And there are all sorts of issues with that.
> Anyway, I quite like the idea of rationalising error-code returns in C
> code, but I don't think this is the right way of going about it.
> HTH,
> Julian

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]