>>1
Even if you fix the fib and add a return value to main you're invoking undefined behavior so there's no telling what it will produce.
Name:
Anonymous2012-01-16 16:57
Assuming x86, you're doing it wrong.
The code seemingly intents to overwrite the return address of anus() with 0, causing a segmentation fault.
However, sizeof(void*) is 4 bytes on a 32-bit machine. This makes p point 16 bytes ahead in the stack, landing just after the saved frame pointer. Therefore, the function is writing on stack area ahead of any function frame, causing no harm.
If you intended to overwrite the return address of anus(), you should just decrement p. You didn't do that possibly because you thought pointers in C did not respect the pointee's size type, but they do.
This is also a reason why one cannot do pointer arithmetic with pointers to incomplete types.
Name:
Anonymous2012-01-16 16:58
However, sizeof(void*) is 4 bytes on a 32-bit machine.
That's not necessarily true.
Again, I'm assuming current call conventions on a x86 machine. It can be 48-bit only if the pointer is a far pointer, which is not the case in a flat memory model, otherwise it will be 32-bit.
Subtraction of a size_t from an int pointer is undefined, the code thus produces UB.
Name:
Anonymous2012-01-16 17:12
>>9
Even though you're using an x86 machine the implementation might be a 16 bit environment. So you're assuming more than just x86 and a 32 bit machine, you're assuming a 32 bit implementation.
./faggot.c: In function 'anus':
./faggot.c:4: error: 'NULL' undeclared (first use in this function)
./faggot.c:4: error: (Each undeclared identifier is reported only once
./faggot.c:4: error: for each function it appears in.)