int main(void) { return main(); }

[JimS]

The program that you gave:

int main(void) { return main(); }

is an infinite recursive loop. It will run until the stack blows up.
Which is what happened in my case. As to why you got a return value,
that's implementation specific: aka undefined behavior.

What's a stack? Where's that in the C standard?

Jim

 

[Chris Dollin]

The program that you gave:

int main(void) { return main(); }

is an infinite recursive loop. It will run until the stack blows up.

Or until your patience runs out: it's tail-recursive and a compiler
can optimise it into a spin loop.

 

[Keith Thompson]

At about the time of 3/29/2007 4:20 PM, Keith Thompson stated the following: [...]

Perhaps there should be a separate set of required limits for run-time
capacity.

Um...no.

How are you going to account for a program that runs on a super
computer? One that uses 25GB Ram, 50 CPUs, and other resources? You
can't. A program cannot use more resources than the system has
available, period. Eventually, you will run out of something...disk
space, memory, CPU utilization, Network bandwidth, etc. Even swap is
only so big. IMO, system imposed resource limits are good way to go.

That's not what I meant. I'm not suggesting that an implementation
must impose a specific limit. I'm suggesting that an implementation
must support *at least* a specified depth of function calls.

Take a look at C99 5.2.4.1. One of the listed requirements is that an
implementation must be able to translate and execute at least one
program with 127 nesting levels of blocks. The actual limit imposed
by an implementation can be much higher than that.

Similarly, I'm suggesting that a requirement *could* be added saying
that an implementation must support at least, say, 127 nested function
calls at run time; the actual limit, if any, could be much higher.

I'm not necessarily saying that such a change to the standard would be
a good idea; I was just saying that it *could* be done.

 

[santosh]

"'dd' is not recognized as an internal or external command,
operable program or batch file."

That's an Unix command. For Windows, just launch iexplore.exe. A blue
screen future is inevitable.

 

[Army1987]

At about the time of 3/29/2007 12:52 PM, Army1987 stated the following:

LOL

What was the fallout from that? Considering that you weren't even root,
did they know it was you who did it?

Nothing, fortunately nobody was working on anything serious on that server,
they were mostly just surfing on the Web or writing simple homework
programs.
Anyway, as soon as I realized what I did, I apoligized. (Again, I didn't
expect *that* to actually happen...)

 

[Manuel T]

That's an Unix command. For Windows, just launch iexplore.exe. A blue
screen future is inevitable.

LOL!

To the OP. The program in the subject line gives "Segmentation Fault".
Running it with "strace" on Kubuntu 6.10 shows how it faults at first
loop(imho). The second program eat each byte of available memory, both ram
and swap, and is killed by the system:

emanuele@engine:~$ ./strange
Killed

What happens on Windows?

Bye, Emanuele

 

[Army1987]

I didn't see any way for the code to avoid that statement, so it

Woops. My second mistake this year. Things are getting bad.

Don't worry. Pay back your sleep debt and you'll be fine.

That leaves something foolish in lcc-win32.

The program which gives an absurd return value on lcc-win32 (as shown by
rundos.exe, which executes a program and then prints the return value of
main() and the time elapsed) is the one in the *object line*:
int main(void)
{
return main();
}

If I understand correctly, as soon as the stack (or whatever you call it) is
full the program exits with an implementation defined return value.
(With gcc, it just dumps core).

Sorry if the <newline><newline>--<newline> sequence wasn't enough to show
the second program was a signature. It does 'work' if dim is large enough
(and, with lcc-win32, it gives a return value of 0). The unrealistic result
I was refering to was that printed by printf, which is larger than the
memory available on my PC. Probably malloc is implemented as described in
http://c-faq.com/malloc/lazyalloc.html only if dim is very large, but that's
another story.

 

[Army1987]

What's a stack? Where's that in the C standard?

The fact that the C standard doesn't define a name for "the area of memory
where automatic variables are stored" doesn't mean that we are forbidden to
use an already existing English word to refer to that, right?

 

[Chris Dollin]

The fact that the C standard doesn't define a name for "the area of memory
where automatic variables are stored" doesn't mean that we are forbidden
to use an already existing English word to refer to that, right?

So long as you remember that not all automatic variables are
stored on the stack [1], and that the usual implication of
"the stack" is a single contiguous area of memory that grows
and shrinks from one end -- and the C area-for-automatics isn't
required to do that, and at least one implementation I know
of doesn't either; IIRC chunks of stack are allocated from
the heap as needed, and deallocated when un-needed, and those
chunks can be discontiguous and in essentially random order.

So yes, if you're happy using `stack` to mean `that collection
of memory chunks in random order, allocated and decallocated
on demand, used for some automatic variables and maybe some
return addresses`, then fine, but it'll be such a palaver
stressing that each post you use it that it'd be easier to
go with the flow: C doesn't have "a stack", although some
(many) implementations use one, and some of those use the
stack-thingy that goes with the machine architecture too.

Remembering that C has no stack means it's easy to answer
some paying-excessive-attention-to-implementation-details,
like "does the C stack grow up or down?": C doesn't have a
stack, so the answer is "No". (As you know, Bob, stacks
always grow down, because you add new items to the top and
the remaining items are pushed -- hence the name -- further
down. Stacks can't "grow up": if you tried, all the plates
would fall out.)

[1] Not as such, although of course they may get /saved/ there.

 

[Barry]

LOL!

To the OP. The program in the subject line gives "Segmentation Fault".
Running it with "strace" on Kubuntu 6.10 shows how it faults at first
loop(imho). The second program eat each byte of available memory, both ram
and swap, and is killed by the system:

emanuele@engine:~$ ./strange
Killed

What happens on Windows?

On XP compiled with default options with either my version of
gcc or bcc 5.02 it runs tens of thousands of loops and exits.
The shell shows an error code of 5. Compiled with -O2 both
compilers produce and infinite loop.

 

[Barry]

On XP compiled with default options with either my version of
gcc or bcc 5.02 it runs tens of thousands of loops and exits.
The shell shows an error code of 5. Compiled with -O2 both
compilers produce and infinite loop.

Oops, scratch that, with O2 the Borland compiler just runs
a while longer.

 

[Daniel Rudy]

At about the time of 3/30/2007 1:37 AM, Keith Thompson stated the following:

At about the time of 3/29/2007 4:20 PM, Keith Thompson stated the following: [...]

Perhaps there should be a separate set of required limits for run-time
capacity.

Um...no.

How are you going to account for a program that runs on a super
computer? One that uses 25GB Ram, 50 CPUs, and other resources? You
can't. A program cannot use more resources than the system has
available, period. Eventually, you will run out of something...disk
space, memory, CPU utilization, Network bandwidth, etc. Even swap is
only so big. IMO, system imposed resource limits are good way to go.

That's not what I meant. I'm not suggesting that an implementation
must impose a specific limit. I'm suggesting that an implementation
must support *at least* a specified depth of function calls.

Ah, ok. Thanks for clearing that up.

Take a look at C99 5.2.4.1. One of the listed requirements is that an
implementation must be able to translate and execute at least one
program with 127 nesting levels of blocks. The actual limit imposed
by an implementation can be much higher than that.

Similarly, I'm suggesting that a requirement *could* be added saying
that an implementation must support at least, say, 127 nested function
calls at run time; the actual limit, if any, could be much higher.

I'm not necessarily saying that such a change to the standard would be
a good idea; I was just saying that it *could* be done.

I still personally think that system imposed limits are the best way to
go. I did take a look at n1124 (downloaded it off the net in fact) and
I see exactly what you are talking about. And my point was footnote 13
which says "13) Implementations should avoid imposing fixed translation
limits whenever possible." which I interpret to mean that the system
should impose the limits.

So I guess that we both agree then.

--
Daniel Rudy

Email address has been base64 encoded to reduce spam
Decode email address using b64decode or uudecode -m

Why geeks like computers: look chat date touch grep make unzip
strip view finger mount fcsk more fcsk yes spray umount sleep

 

[Daniel Rudy]

At about the time of 3/30/2007 1:48 AM, santosh stated the following:

That's an Unix command. For Windows, just launch iexplore.exe. A blue
screen future is inevitable.

That is so true.

Speaking of which...

http://www.rebelz.net/gallery/v/fun/computers/WinXP.jpg.html


--
Daniel Rudy

Email address has been base64 encoded to reduce spam
Decode email address using b64decode or uudecode -m

Why geeks like computers: look chat date touch grep make unzip
strip view finger mount fcsk more fcsk yes spray umount sleep

 

[Daniel Rudy]

At about the time of 3/30/2007 3:19 AM, Army1987 stated the following:

Nothing, fortunately nobody was working on anything serious on that server,
they were mostly just surfing on the Web or writing simple homework
programs.
Anyway, as soon as I realized what I did, I apoligized. (Again, I didn't
expect *that* to actually happen...)

Well, it's good to know that all's well that ends well.
--
Daniel Rudy

Email address has been base64 encoded to reduce spam
Decode email address using b64decode or uudecode -m

Why geeks like computers: look chat date touch grep make unzip
strip view finger mount fcsk more fcsk yes spray umount sleep

 

[Daniel Rudy]

At about the time of 3/29/2007 10:52 PM, JimS stated the following:

What's a stack? Where's that in the C standard?

Jim

It's not, but judging from the computers in use today, it's a reasonable
assumption. As for your first question, you are joking, right?


--
Daniel Rudy

Email address has been base64 encoded to reduce spam
Decode email address using b64decode or uudecode -m

Why geeks like computers: look chat date touch grep make unzip
strip view finger mount fcsk more fcsk yes spray umount sleep

 

[Richard Heathfield]

Daniel Rudy said:

At about the time of 3/29/2007 10:52 PM, JimS stated the following:

It's not, but judging from the computers in use today, it's a
reasonable
assumption. As for your first question, you are joking, right?

Here's a stack:

void push(unsigned char c); /* stick this in a header */
unsigned char pop(void); /* and this */

static unsigned char stack[6] = {0};
static unsigned int stackptr = 0;

void push(unsigned char c)
{
if(stackptr < 6)
{
char[stackptr++] = c;
}
}

unsigned char pop(void)
{
unsigned char c = 0;
if(stackptr > 0)
{
c = char[--stackptr];
}
return c;
}

I don't quite see what this has to do with recursive functions.

 

[army1987]

That is so true.

Speaking of which...

http://www.rebelz.net/gallery/v/fun/computers/WinXP.jpg.html

LOL... Is it real? (I fear it is.)

 

[Daniel Rudy]

At about the time of 4/1/2007 3:34 PM, (e-mail address removed) stated the
following:

LOL... Is it real? (I fear it is.)

Well, you see a busted CD in the floppy drive...


--
Daniel Rudy

Email address has been base64 encoded to reduce spam
Decode email address using b64decode or uudecode -m

Why geeks like computers: look chat date touch grep make unzip
strip view finger mount fcsk more fcsk yes spray umount sleep