Thread overview
exit() to end a function
Feb 12, 2011
bearophile
Feb 12, 2011
Jonathan M Davis
Feb 14, 2011
spir
Feb 14, 2011
Jonathan M Davis
Feb 14, 2011
spir
February 12, 2011
A small D2 function:

import std.c.stdlib: exit;
int foo(int x) {
    if (x > 0)
        return x;
    exit(0);
    //assert(0);
}
void main() {}


DMD 2.051 gives this compile-time error:
test.d(2): Error: function test4.foo no return exp; or assert(0); at end of function

If I comment out the the final exit(0) and uncomment the assert(0), the code compiles correctly.
Is it meaningful and good to give std.c.stdlib.exit the same function-end semantics of assert(0)?

GCC has a "noreturn" function attribute that allows to tell the compiler what functions (beside few default ones like exit) don't return:
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#index-g_t_0040code_007bnoreturn_007d-function-attribute-2464

Bye,
bearophile
February 12, 2011
On Saturday 12 February 2011 14:03:09 bearophile wrote:
> A small D2 function:
> 
> import std.c.stdlib: exit;
> int foo(int x) {
>     if (x > 0)
>         return x;
>     exit(0);
>     //assert(0);
> }
> void main() {}
> 
> 
> DMD 2.051 gives this compile-time error:
> test.d(2): Error: function test4.foo no return exp; or assert(0); at end of
> function
> 
> If I comment out the the final exit(0) and uncomment the assert(0), the
> code compiles correctly. Is it meaningful and good to give
> std.c.stdlib.exit the same function-end semantics of assert(0)?
> 
> GCC has a "noreturn" function attribute that allows to tell the compiler what functions (beside few default ones like exit) don't return: http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#index-g_t_0040c ode_007bnoreturn_007d-function-attribute-2464

The problem is that we have no way to indicate that a function will never return. So, even if it's a function like exit which kills the program or a function which always throws, the compiler doesn't know that the next statement will never be executed. As such, it requires the assert(0).

Considering that exit really isn't something that you should be calling normally, I don't think that there's much value in complicating dmd just for it. There would be some value to having an attribute which indicated that a function never returns under any circumstances (likely since it always throws), but that wouldn't help exit any, since it's a C function and wouldn't have the attribute.

Regardless, I see little value in complicating dmd even a little bit more just so that you don't have to insert an extra assert(0) after exit - particularly when very few programs call exit, and very few should. Generally, something is horrendously wrong if exit is being called, and there's probably a better way to handle it.

- Jonathan M Davis
February 14, 2011
On Sat, 12 Feb 2011 17:48:56 -0500, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> There would be some value to having an attribute which indicated that a function
> never returns under any circumstances (likely since it always throws), but that
> wouldn't help exit any, since it's a C function and wouldn't have the attribute.

The bindings to C can be attributed as we see fit.  A C symbol is not mangled, and so you can attach any attributes you want (you can even change the number and types of parameters).

> Regardless, I see little value in complicating dmd even a little bit more just
> so that you don't have to insert an extra assert(0) after exit - particularly
> when very few programs call exit, and very few should.

I agree with this.

> Generally, something is
> horrendously wrong if exit is being called, and there's probably a better way to
> handle it.

I don't agree with this, exit has its valid uses.

-Steve
February 14, 2011
On 02/14/2011 03:12 PM, Steven Schveighoffer wrote:
> On Sat, 12 Feb 2011 17:48:56 -0500, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
>
>> There would be some value to having an attribute which indicated that a function
>> never returns under any circumstances (likely since it always throws), but that
>> wouldn't help exit any, since it's a C function and wouldn't have the attribute.
>
> The bindings to C can be attributed as we see fit. A C symbol is not mangled,
> and so you can attach any attributes you want (you can even change the number
> and types of parameters).
>
>> Regardless, I see little value in complicating dmd even a little bit more just
>> so that you don't have to insert an extra assert(0) after exit - particularly
>> when very few programs call exit, and very few should.
>
> I agree with this.
>
>> Generally, something is
>> horrendously wrong if exit is being called, and there's probably a better way to
>> handle it.
>
> I don't agree with this, exit has its valid uses.

Agree with Steven. All my modules hold:

import core.stdc.stdlib : exit;
// debug tool func
void stop () { exit(0); }

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

February 14, 2011
On Monday 14 February 2011 06:12:56 Steven Schveighoffer wrote:
> On Sat, 12 Feb 2011 17:48:56 -0500, Jonathan M Davis <jmdavisProg@gmx.com>
> 
> wrote:
> > There would be some value to having an attribute which indicated that a
> > function
> > never returns under any circumstances (likely since it always throws),
> > but that
> > wouldn't help exit any, since it's a C function and wouldn't have the
> > attribute.
> 
> The bindings to C can be attributed as we see fit.  A C symbol is not mangled, and so you can attach any attributes you want (you can even change the number and types of parameters).
> 
> > Regardless, I see little value in complicating dmd even a little bit
> > more just
> > so that you don't have to insert an extra assert(0) after exit -
> > particularly
> > when very few programs call exit, and very few should.
> 
> I agree with this.
> 
> > Generally, something is
> > horrendously wrong if exit is being called, and there's probably a
> > better way to
> > handle it.
> 
> I don't agree with this, exit has its valid uses.

Well, I agree that it has its valid uses, but I think that such uses are quite rare. You shouldn't normally be writing programs that choose to essentially just die in the middle of their execution.

- Jonathan M Davis
February 14, 2011
On Mon, 14 Feb 2011 11:19:24 -0500, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Monday 14 February 2011 06:12:56 Steven Schveighoffer wrote:
>> On Sat, 12 Feb 2011 17:48:56 -0500, Jonathan M Davis <jmdavisProg@gmx.com>
>>
>> wrote:
>> > There would be some value to having an attribute which indicated that  
>> a
>> > function
>> > never returns under any circumstances (likely since it always throws),
>> > but that
>> > wouldn't help exit any, since it's a C function and wouldn't have the
>> > attribute.
>>
>> The bindings to C can be attributed as we see fit.  A C symbol is not
>> mangled, and so you can attach any attributes you want (you can even
>> change the number and types of parameters).
>>
>> > Regardless, I see little value in complicating dmd even a little bit
>> > more just
>> > so that you don't have to insert an extra assert(0) after exit -
>> > particularly
>> > when very few programs call exit, and very few should.
>>
>> I agree with this.
>>
>> > Generally, something is
>> > horrendously wrong if exit is being called, and there's probably a
>> > better way to
>> > handle it.
>>
>> I don't agree with this, exit has its valid uses.
>
> Well, I agree that it has its valid uses, but I think that such uses are quite
> rare. You shouldn't normally be writing programs that choose to essentially just
> die in the middle of their execution.

The most common case I can think of is usage errors.  Typically, a usage function prints the usage and then exits the program.  This can be done differently, but it's not "wrong" to do it that way.

-Steve
February 14, 2011
On 02/14/2011 05:39 PM, Steven Schveighoffer wrote:
> On Mon, 14 Feb 2011 11:19:24 -0500, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
>
>> On Monday 14 February 2011 06:12:56 Steven Schveighoffer wrote:
>>> On Sat, 12 Feb 2011 17:48:56 -0500, Jonathan M Davis <jmdavisProg@gmx.com>
>>>
>>> wrote:
>>> > There would be some value to having an attribute which indicated that a
>>> > function
>>> > never returns under any circumstances (likely since it always throws),
>>> > but that
>>> > wouldn't help exit any, since it's a C function and wouldn't have the
>>> > attribute.
>>>
>>> The bindings to C can be attributed as we see fit. A C symbol is not
>>> mangled, and so you can attach any attributes you want (you can even
>>> change the number and types of parameters).
>>>
>>> > Regardless, I see little value in complicating dmd even a little bit
>>> > more just
>>> > so that you don't have to insert an extra assert(0) after exit -
>>> > particularly
>>> > when very few programs call exit, and very few should.
>>>
>>> I agree with this.
>>>
>>> > Generally, something is
>>> > horrendously wrong if exit is being called, and there's probably a
>>> > better way to
>>> > handle it.
>>>
>>> I don't agree with this, exit has its valid uses.
>>
>> Well, I agree that it has its valid uses, but I think that such uses are quite
>> rare. You shouldn't normally be writing programs that choose to essentially just
>> die in the middle of their execution.
>
> The most common case I can think of is usage errors. Typically, a usage
> function prints the usage and then exits the program. This can be done
> differently, but it's not "wrong" to do it that way.


Exactly the way I use it :-)
Sometimes test suite are not enough, esp when the flow control is complicated and/or cascading. Instead of heavy use of a debugger, I "plant' 1-2-3 writelines on the way, one exit, & run! Then i move back or forth.
There are a few precious features which, imo, have nothing to do with app logics, and make the whole difference between an usable and an unusable language. (write*, exit, literals...)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com