Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C Programming (http://www.velocityreviews.com/forums/f42-c-programming.html)
-   -   Re: Any exit status without explicitely using return /exit (http://www.velocityreviews.com/forums/t715929-re-any-exit-status-without-explicitely-using-return-exit.html)

Keith Thompson 02-24-2010 09:02 AM

Re: Any exit status without explicitely using return /exit
 
Debanjan <debanjan4you@gmail.com> writes:
> This actually bugging me from quite sometime now.The question is like
> this : How to set the the exit status of a program to any value
> without explicitly using return/exit in gcc ?

[...]

Some equally interesting questions:

How can you add two numbers without using the "+" operator?

How can you call a function without using a function call?

How can you pound a nail without using a hammer?

A more relevant question: Why don't you want to use return or exit?
That's what they're for.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

santosh 02-24-2010 10:23 AM

Re: Any exit status without explicitely using return /exit
 
Debanjan <debanjan4you@gmail.com> writes:
[ ... ]

> For the question I asked,I modified it a bit
>
> int f(int n){
> return (n>0);
> }
>
> int main(){
> int n;
> while(scanf("%d",&n)&&f(n))
> printf("%d\n",n);
> }
>
> Now it returns 0 implicitly,but I am unable to draw any firm
> conclusion from this,could anybody help to generalize ?


If you're thinking the call to f() returns 0 from main() implicitly,
then you're not correct. As Jacob said, under C99 omitting an
explicit return from main() returns zero, but not your call to f().
The call to f() can be replaced with n > 0 in the loop condition. And
the problems Ike pointed out still remain.

Don't worry about exit statuses in obfuscated C contests. For
learning C, ignore obfuscated C contests, and just use return/exit.



Alan Curry 02-24-2010 11:31 AM

Re: Any exit status without explicitely using return /exit
 
In article <ddfa57a3-7ec1-4ce9-b595-2ad9e26ee910@b7g2000pro.googlegroups.com>,
Debanjan <debanjan4you@gmail.com> wrote:
|
|int f(int n){
| return (n>0);
| }
|
|int main(){
| int n;
| while(scanf("%d",&n)&&f(n))
| printf("%d\n",n);
| }
|
|Now it returns 0 implicitly,but I am unable to draw any firm
|conclusion from this,could anybody help to generalize ?

Generally the return value you'll get from that program will be whatever
value happened to be left over in the integer return register when the
function reached its end. So it might even vary randomly between runs of the
same compiler, even without changing anything. Don't do that.

If you compile in C99 mode (gcc -std=c99) it'll do the implicit return 0 from
the end of main, consistently.

One of the stupider C99 features, it's not provided unless you ask for it.

--
Alan Curry

Keith Thompson 02-24-2010 04:22 PM

Re: Any exit status without explicitely using return /exit
 
pacman@kosh.dhis.org (Alan Curry) writes:
[...]
> Generally the return value you'll get from that program will be whatever
> value happened to be left over in the integer return register when the
> function reached its end. So it might even vary randomly between runs of the
> same compiler, even without changing anything. Don't do that.


Generally the return value will be garbage (assuming a C90
implementation). On some specific implementations that garbage
might happen to be "whatever value happened to be left over in the
integer return register when the function reached its end".

> If you compile in C99 mode (gcc -std=c99) it'll do the implicit
> return 0 from the end of main, consistently.
>
> One of the stupider C99 features, it's not provided unless you ask for it.


gcc doesn't provide it unless you ask for it. Other implementations
behave differently.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Richard Bos 02-24-2010 05:16 PM

Re: Any exit status without explicitely using return /exit
 
Debanjan <debanjan4you@gmail.com> wrote:

> On Feb 24, 2:02=A0pm, Keith Thompson <ks...@mib.org> wrote:
> > Debanjan <debanjan4...@gmail.com> writes:
> > > This actually bugging me from quite sometime now.The question is like
> > > this : How to set the the exit status of a program to any value
> > > without explicitly using return/exit in gcc ?


> > A more relevant question: Why don't you want to use return or exit?
> > That's what they're for.

>
> There are few online coding challenge contest where less the number of
> character more the points you earned


That is an _extremely_ bad idea. Don't do it. Write for legibility
instead.

Richard

Keith Thompson 02-24-2010 05:49 PM

Re: Any exit status without explicitely using return /exit
 
raltbos@xs4all.nl (Richard Bos) writes:
> Debanjan <debanjan4you@gmail.com> wrote:
>> On Feb 24, 2:02=A0pm, Keith Thompson <ks...@mib.org> wrote:
>> > Debanjan <debanjan4...@gmail.com> writes:
>> > > This actually bugging me from quite sometime now.The question is like
>> > > this : How to set the the exit status of a program to any value
>> > > without explicitly using return/exit in gcc ?

>
>> > A more relevant question: Why don't you want to use return or exit?
>> > That's what they're for.

>>
>> There are few online coding challenge contest where less the number of
>> character more the points you earned

>
> That is an _extremely_ bad idea. Don't do it. Write for legibility
> instead.


Agreed. First, learn how to write *clear* code. Once you've done
that, contests where you try to minimize the number of source
characters can be entertaining (I've entered the IOCCC myself), but
you could be learning some very bad habits.

In this particular instance, there is *no* good reason to avoid the
use of exit and return. (You can get away with it if you have a C99
implementation and the status you want to return happens to be 0, but
even then I'd say that an explicit "return 0;" is a good idea.)

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Seebs 02-24-2010 07:02 PM

Re: Any exit status without explicitely using return /exit
 
On 2010-02-24, Debanjan <debanjan4you@gmail.com> wrote:
> Now it returns 0 implicitly,but I am unable to draw any firm
> conclusion from this,could anybody help to generalize ?


Yes:

Sometimes what happens when you invoke undefined behavior may be surprising,
unpredictable, or influenced by things which don't matter.

Seriously, anything you try to draw from this will be wrong on other systems,
or on the same system in a different phase of the moon. You're thinking about
this in a totally wrong way. The correct generalization is that, assuming
a C89 environment, the return value is undefined, and it could be anything.
It may appear to exhibit patterns. It may even exhibit patterns on some
systems, some of the time, at some optimization levels.

But since the code is wrong, who cares what it does?

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Keith Thompson 02-24-2010 07:53 PM

Re: Any exit status without explicitely using return /exit
 
Seebs <usenet-nospam@seebs.net> writes:
> On 2010-02-24, Debanjan <debanjan4you@gmail.com> wrote:
>> Now it returns 0 implicitly,but I am unable to draw any firm
>> conclusion from this,could anybody help to generalize ?

>
> Yes:
>
> Sometimes what happens when you invoke undefined behavior may be surprising,
> unpredictable, or influenced by things which don't matter.
>
> Seriously, anything you try to draw from this will be wrong on other
> systems, or on the same system in a different phase of the moon.
> You're thinking about this in a totally wrong way. The correct
> generalization is that, assuming a C89 environment, the return value
> is undefined, and it could be anything. It may appear to exhibit
> patterns. It may even exhibit patterns on some systems, some of the
> time, at some optimization levels.


And those patterns can be interesting, or even useful,
in understanding how a specific implementation does things.
In particular, understanding something about the inner workings of
a specific implementation can be useful for tracking down bugs.

For example, if I print the value of an integer object and it
appears to be garbage, that tells me there's a bug somewhere.
If I happen to recognize that the garbage value looks like a heap
address or a floating-point representation, it tells me something
about what the bug is and how to fix it.

But the goal should (almost) always be to use this information
to fix the bug, so the program's behavior no longer depends on
implementation-specific features.

> But since the code is wrong, who cares what it does?


In this particular case, the bug is that the program fails to return
a value to the environment. That's easy to spot and easy to fix:
add a "return 0;" statement (or use a C99 implementation, but even
then the "return 0;" statement isn't a bad idea).

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Alan Curry 02-25-2010 12:13 AM

Re: Any exit status without explicitely using return /exit
 
In article <lntyt61u4p.fsf@nuthaus.mib.org>,
Keith Thompson <kst-u@mib.org> wrote:
|pacman@kosh.dhis.org (Alan Curry) writes:
|[...]
|> Generally the return value you'll get from that program will be whatever
|> value happened to be left over in the integer return register when the
|> function reached its end. So it might even vary randomly between runs of the
|> same compiler, even without changing anything. Don't do that.
|
|Generally the return value will be garbage (assuming a C90
|implementation). On some specific implementations that garbage
|might happen to be "whatever value happened to be left over in the
|integer return register when the function reached its end".
|
|> If you compile in C99 mode (gcc -std=c99) it'll do the implicit
|> return 0 from the end of main, consistently.
|>
|> One of the stupider C99 features, it's not provided unless you ask for it.
|
|gcc doesn't provide it unless you ask for it. Other implementations
|behave differently.

Gee I though since the thread was started with explicit mention of gcc, I
might provide an answer based on what gcc is actually doing, and how its
behavior can be controlled.

But direct answers to questions actually asked never go unpunished on
comp.lang.c

--
Alan Curry

Keith Thompson 02-25-2010 12:13 AM

Re: Any exit status without explicitely using return /exit
 
pacman@kosh.dhis.org (Alan Curry) writes:
> In article <lntyt61u4p.fsf@nuthaus.mib.org>,
> Keith Thompson <kst-u@mib.org> wrote:
> |pacman@kosh.dhis.org (Alan Curry) writes:

[...]
> |> If you compile in C99 mode (gcc -std=c99) it'll do the implicit
> |> return 0 from the end of main, consistently.
> |>
> |> One of the stupider C99 features, it's not provided unless you ask for it.
> |
> |gcc doesn't provide it unless you ask for it. Other implementations
> |behave differently.
>
> Gee I though since the thread was started with explicit mention of gcc, I
> might provide an answer based on what gcc is actually doing, and how its
> behavior can be controlled.
>
> But direct answers to questions actually asked never go unpunished on
> comp.lang.c


You feel punished? You must have a thin skin.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"


All times are GMT. The time now is 11:05 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.