This is the mail archive of the
mailing list for the GCC project.
Re: GNU C extension: Function Error vs. Success
- From: Shahbaz Youssefi <shabbyx at gmail dot com>
- To: Julian Brown <julian at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 10 Mar 2014 16:09:24 +0100
- Subject: Re: GNU C extension: Function Error vs. Success
- Authentication-results: sourceware.org; auth=none
- References: <CALeOzZ8kAOepbUsqRNWnGvHc=vAGC2M_NkHZ6+VZz3ybfs59HA at mail dot gmail dot com> <20140310145046 dot 2d5c4ca0 at octopus>
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:
http://stackoverflow.com/a/1746368/912144 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 ....)
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 <email@example.com> wrote:
> On Mon, 10 Mar 2014 15:27:06 +0100
> Shahbaz Youssefi <firstname.lastname@example.org> wrote:
>> 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.