void f(void) {
printf("hax my anus\n");
fflush(stdout);
f();
}
int main(void) {
f();
return 0;
}
Name:
Anonymous2012-01-12 14:56
>>1
Non-deterministic code, and also it will not produce the same output for all implementations of C, however "correct" or "incorrect" they are.
Name:
Anonymous2012-01-12 14:56
So proving or disproving this is like solving the halting problem for this program or something?
Name:
Anonymous2012-01-12 14:56
C99 6.5.2.2.11 Recursive function calls shall be permitted, both directly and indirectly through any chain of other functions.
Because C has no stack, it can theoretically run forever. In fact tail recursion optimizations are possible only because the C standard does not mention a stack.
Name:
Anonymous2012-01-12 14:56
>>41
That's wrong, if it crashes then your implementation of C is flawed and not really C.
Okay I get it, /g/ doesn't know the standard so they now think it's undefined after you spammed the shit out of them about the undefined program. Very clever, go away now.
Name:
Anonymous2012-01-12 14:59
ITT people using gnuc89 or gnuc99 and it seg faults
Name:
Anonymous2012-01-12 15:00
>>43
A side note: The stack isn't the limitation. Theoretically a stack could have infinitely space.
No. The standard assumes that the host environment has sufficient resources to store and execute the program code itself -- which means that things like stack overflows and static allocation failures cannot happen on the C abstract machine. The behavior of the program is thus well defined, it prints "hax my anus\n" ad infinitum.
You might argue that these assumptions aren't sound, but it would be absolutely silly in any other case. What if the environment has insufficient resources to load the program code, should we be able to catch and deal with a code allocation failure?
Name:
Anonymous2012-01-12 15:00
>>50
Okay, it doesn't call exit and it never returns, so it runs forever.
Name:
Anonymous2012-01-12 15:01
>>55
Nope, that is not proof. It is an indication, but not a formal proof.
Name:
Anonymous2012-01-12 15:02
>>56
Please cite from the C standard how it might exit then.
Name:
Anonymous2012-01-12 15:02
>>54
Defined, yes, but not deterministic. Also, unlimited resources is a false premise as you have just shown.
>>55
That is not a proof. What if the program is interrupted.
Name:
Anonymous2012-01-12 15:02
>>54
Damn what a neat fucking troll. I'm going to post this on /g/.
>>63
This has nothing to do with a Turing machine. Do you know what the C abstract machine is?
Name:
Anonymous2012-01-12 15:07
HEY PROG RUN MY PROGRAM AND TELL ME THE OUTPUT
#MIPS
main: li $v0,4
la $a0,hax
syscall
j main
.data
hax: .asciiz "hax my anus\n"
Name:
Anonymous2012-01-12 15:08
Where may I acquire one of these C abstract machines?
Name:
Anonymous2012-01-12 15:08
I run all my programs on the C abstract machine.
Name:
Anonymous2012-01-12 15:09
>>65
The point wasn't the turing machine, but that you may have different results for every run, there isn't a well-defined entry and exit point, which is a requirement for determinism, therefore the program is ultimately indeterministic.
I think this would be undefined behavior because you're flushing stdout twice. There could be crash because you're attempting to free() more memory that what you allocate.
Gentlemen, please, if you are from /g/ and have arrived to /prog/ this month, please leave, there is no sense in arguing about things like these. The answers to questions like these are defined by standards so there is an actual answer to the questions, there is little use arguing about them without a copy of the standard so if you don't have one, please leave this thread.
>>72
standard is li3k 550 pages
(least the copy I just downloaded from the interwebz)
Seriously you call yourself professional and you can't even memorize a measly 550 pages.
Toilet scrubbing boo-hoo.
Name:
Anonymous2012-01-12 15:14
>>71
Does flushing stdout twice cause undefined behavior? That I didn't know. About free I'm guessing that fflush somehow calls free?