Let us consider this piece of code : (Takes input from stdin and print
it to the stdout until a zero input 0 is encountered)
#include <stdio.h>
int main(){
int n;
while(scanf("%d",&n) && n>0 )
printf("%d\n",n);
}
In my system (which is windows + mingw) it is returning 1,How to make
it to return 0 or anything else implicitly without explicitly using
exit/return ?
And later in tonight's program, how to drive nails using a wrench...
Standard C guarantees a return of zero for a main() function that
doesn't explicitly assign a return value.
Yes that I know but in some gcc version it is not the actual case,like
the one I showed above.
_Exit(ANY_VALUE);
should do the trick, and it answers what you asked.
Seriously though, even if there is some hackery to get this done, it
isn't likely to be portable or consistent between compilers or
systems. And the even bigger question is why you want to do this in
the first place. Is it simple curiosity? If it's for any practical
purposes, there's very likely to be better way to do what you want.
By "Standard C", of course, jacob means C99. In C90, which jacob
insists on ignoring, the exit status of such a program is undefined.
(Yes, C99 superseded C90. Yes, C99 is the one and only official
C standard. We know, jacob, we know.)
--
Keith Thompson (The_Other_Keith) ks...@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"
That program will not do the required job; it will not only terminate
if input 0 is encountered, but also if an input error occurs or if a
negative input is encountered.
If you compile it with a C89 compiler, it may return anything, and, in
fact, on my implementation (gcc compiler running on NetBSD) the program
returns 1 when it terminates because of an input <=0, and it returns 0
if it terminates because of an input error (when the input is not a
valid integer). Of course the return values may be different on another
implementation, this is only to illustrate that the return value can be
anything at all.
If you compile the program with a C99 compiler, it will implicitly return 0
if you don't specify a return value.
If you're using C89, or if you're using C99 and want a return value other
than 0, just use an explicit return or exit.
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.
> In my system (which is windows + mingw) it is returning 1,How to make
> it to return 0 or anything else implicitly without explicitly using
> exit/return ?
You don't. That's why the C standard has return / exit. I can't seem to
understand why you don't want to use a return value.
Igmar
There are few online coding challenge contest where less the number of
character more the points you earned for example consider this one :
http://www.spoj.pl/SHORTEN/ there are many others actually,you may
argue about using C in such places but why not C ? :)
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 ?
> 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.
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
This last paragraph is very illustrative of the CLC attitude.
Which is "When you say something lacking in precision in any way, we are
only too eager to point it out, repeatedly, and to pile on to our hearts
content. But when we say something a little sloppy, it's OK because we
run this place. And, further, it is you who are, again, at fault, for
pointing out our lack of precision."
Too easy - use Visual Studio, or Borland, or Watcom, or Digital Mars...
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
> >> Standard C guarantees a return of zero for a main() function that
> >> doesn't explicitly assign a return value.
>
> >By "Standard C", of course, jacob means C99. In C90, which jacob
> >insists on ignoring, the exit status of such a program is undefined.
> >(Yes, C99 superseded C90. Yes, C99 is the one and only official
> >C standard. We know, jacob, we know.)
>
> This last paragraph is very illustrative of the CLC attitude.
no. there is no clc attitude
> Which is "When you say something lacking in precision in any way,
I don't think jacob was lacking in precision. I think he said exactly
what he meant to say. It's hard to imagine he missed mentioning C89 by
mistake as he is currently posting to two different threads arguing
there is some sort of conspiracy to premote C89 and denigrate C99.
> we are
> only too eager to point it out, repeatedly, and to pile on to our hearts
> content. But when we say something a little sloppy, it's OK because we
> run this place. And, further, it is you who are, again, at fault, for
> pointing out our lack of precision."
normally I ignore kenny but he needs refuting from time to time just
in case anyone was taking him seriously
> On 24 Feb, 12:38, gaze...@shell.xmission.com (Kenny McCormack) wrote:
>> In article <ln3a0r2eqd....@nuthaus.mib.org>,
>> Keith Thompson <ks...@mib.org> wrote:
>> >jacob navia <ja...@spamsink.net> writes:
>
>> >> Standard C guarantees a return of zero for a main() function that
>> >> doesn't explicitly assign a return value.
>>
>> >By "Standard C", of course, jacob means C99. In C90, which jacob
>> >insists on ignoring, the exit status of such a program is undefined.
>> >(Yes, C99 superseded C90. Yes, C99 is the one and only official
>> >C standard. We know, jacob, we know.)
>>
>> This last paragraph is very illustrative of the CLC attitude.
>
> no. there is no clc attitude
You're either blind or in denial. There is a very obvious c.l.c
attitude. I don't believe for one minute that you are unaware of it.
>
>> Which is "When you say something lacking in precision in any way,
>
> I don't think jacob was lacking in precision. I think he said exactly
> what he meant to say. It's hard to imagine he missed mentioning C89 by
> mistake as he is currently posting to two different threads arguing
> there is some sort of conspiracy to premote C89 and denigrate C99.
More reason.
>
>> we are
>> only too eager to point it out, repeatedly, and to pile on to our hearts
>> content. But when we say something a little sloppy, it's OK because we
>> run this place. And, further, it is you who are, again, at fault, for
>> pointing out our lack of precision."
>
> normally I ignore kenny but he needs refuting from time to time just
> in case anyone was taking him seriously
Which of his views do you find need refuting? He's pretty much on the ball
IMO.
--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
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.
> 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
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.)
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...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
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).
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
You feel punished? You must have a thin skin.
C99 guarantees that falling off the end of main() results in a return value
of zero. C90 does not guarantee anything.
That said, on all implementations I have seen, what happens is that main()
ends up returning whatever happens to be in the register/location/whatever
used to return values from functions. Since this value is unlikely to have
been touched since either scanf() or f() returned zero, it is likely that
main() will return that same zero.
However, there are no guarantees of such behavior in pre-C99.
--
Kenneth Brody
> Debanjan <debanj...@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.
I'm sure it wasn't meant to sound this way, but as I read it this
response seemed rather harsh. The question seems to me to be a
fair question, perhaps even somewhat interesting. So even though
I probably agree with the implicit advice in the Socratic last
question, I hope it's reasonable to suggest giving friendlier and
more helpful answers, even in cases where the questioner may be
motivated by concerns that are stylistically suboptimal.