int f(int x)
{
static int b = 0; static int s = 0;
int a = 0, t;
if (!s) {
a = b; b = x;
} else {
a = x; t = b;
do {
a ^= b;
b = (a^b) & b;
b <<= 1;
} while (b);
b = t;
}
s = (s+1) % 2;
return a;
}
int g(int i, int *j)
{
*j = i;
i = (int) putchar;
if (*j == (48 << 1))
__asm volatile (
"movl 8(%ebp),%eax;"
"leave;"
"ret"
);
return (int) puts;
}
void h(int i)
{
int b;
q = (void(*)()) g(i++[data],&b);
for (f(b);*(data+i)!=b;++i,f(b))
q(f(i[data])%0xff);
}
void sh(int s)
{
if (s == 010)
((void(*)())g(s,&s))("F");
longjmp(p,s);
}
int main(void)
{
int base, addr = 0xffffffff, offs = 16;
int a = 11, b = 32, i = 25;
int s = 8, t = 1, u = 4;
((void(*)()) data)(&a,&b);
((void(*)()) data)(&b,&t);
((void(*)()) data)(&t,&s);
addr ^= a;
a ^= addr;
addr ^= a;
base = ((int(*)())data+addr)();
if (a == -1)
goto over;
puts("A");
if (!(s = setjmp(p))) {
q = (void(*)()) g(0x30, &a);
q(data + a + i);
s = a / (b-1);
puts("B");
} else if (s == 0xb) {
puts("C");
((int(*)(int)) data+addr+(offs/2))(base);
} else {
puts("D");
*((int*) base+s) = 0xffffffff;
}
puts("E");
return 1;
}
Name:
Anonymous2012-01-12 9:37
>>239
[quote]I stated that the use of __asm to alter the stack causes undefined behavior, I also stated that usage of longjmp in a manner defined by the C standard does not yield undefined behavior.[/quote]
That is contradicting since the implementation of longjmp on my machine most certainly uses __asm__ to alter the stack.
The implementation of setjmp and longjmp clearly does.
Name:
Anonymous2012-01-12 9:46
>>241
Under the assumptions that longjmp on your machine is implemented using __asm__ in GCC I will agree that logic dictates that the __asm__ that is used to implement longjmp is well defined on your machine as long as it is only used exactly like longjmp is defined to work in the standard, any other usage is still undefined.
Name:
Anonymous2012-01-12 9:47
>>244 The implementation of setjmp and longjmp clearly does.
That is nonsensical, what if I have an architecture without a stack?
>>241,245
By the way I would very much like to see the implementation of longjmp on your machine.
Name:
2462012-01-12 9:50
I am going to go away now as I have obligations, I will probably be back in a couple of hours and I'd be happy to continue our debate.
Name:
Anonymous2012-01-12 9:52
>>246
| That is nonsensical, what if I have an architecture without a stack?
On the architectures proposed by OP, silly.
The definition itself is: longjmp, siglongjmp - nonlocal jump to a saved stack context
Name:
Anonymous2012-01-12 9:56
>>248
Your edition of the standard seems to be erroneous, on mine it says setjmp - saves the calling environment, longjmp - restores calling environment while siglongjmp is not defined and I can't find it in C89, C99 or C11.
>>248 The definition itself is: longjmp, siglongjmp - nonlocal jump to a saved stack context setjmp - set jump point for a non-local goto longjmp - non-local goto
I don't see any ``stack'' here.
Name:
Anonymous2012-01-12 10:04
$ man longjmp > bla.txt
$ cat bla.txt
LONGJMP(3) Linux Programmer's Manual LONGJMP(3)
NAME
longjmp, siglongjmp - nonlocal jump to a saved stack context
SYNOPSIS
#include <setjmp.h>
void longjmp(jmp_buf env, int val);
void siglongjmp(sigjmp_buf env, int val);
Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
DESCRIPTION
longjmp() and setjmp(3) are useful for dealing with errors and interrupts encountered in a low-level subroutine of a program.
longjmp() restores the environment saved by the last call of setjmp(3) with the corresponding env argument. After longjmp() is
completed, program execution continues as if the corresponding call of setjmp(3) had just returned the value val. longjmp() cannot
cause 0 to be returned. If longjmp() is invoked with a second argument of 0, 1 will be returned instead.
siglongjmp() is similar to longjmp() except for the type of its env argument. If, and only if, the sigsetjmp(3) call that set this
env used a nonzero savesigs flag, siglongjmp() also restores the signal mask that was saved by sigsetjmp(3).
RETURN VALUE
These functions never return.
CONFORMING TO
C89, C99, and POSIX.1-2001 specify longjmp(). POSIX.1-2001 specifies siglongjmp().
NOTES
POSIX does not specify whether longjmp() will restore the signal context (see setjmp(3) for some more details). If you want to
portably save and restore signal masks, use sigsetjmp() and siglongjmp().
The values of automatic variables are unspecified after a call to longjmp() if they meet all the following criteria:
· they are local to the function that made the corresponding setjmp(3) call;
· their values are changed between the calls to setjmp(3) and longjmp(); and
· they are not declared as volatile.
Analogous remarks apply for siglongjmp().
longjmp() and siglongjmp() make programs hard to understand and maintain. If possible an alternative should be used.
SEE ALSO
setjmp(3), sigsetjmp(3)
COLOPHON
This page is part of release 3.27 of the Linux man-pages project. A description of the project, and information about reporting
bugs, can be found at http://www.kernel.org/doc/man-pages/.
Aaand thread of the year award goes to this thread.
Guys, you can stop posting now. All of you. It's ok.
Name:
Anonymous2012-01-12 11:02
>>255
He explicitly stated that wasn't what he said and that it's untrue if you read >>239,245. You're being willfully ignorant about it, I'm not going bother to argue with you like he does, I would never have the patience to it, but I'm going to tell you that you're acting like a child.
Name:
Anonymous2012-01-12 11:04
By the way the program is undefined so the output is undefined.
>>238
The preprocessor doesn't do anything to __asm, __asm__ or asm, do you even know what the preprocessor is?
And you have yet to show where __asm is defined as the doc linked to in >>100 doesn't even mention it.
Name:
Anonymous2012-01-12 11:17
>>264
Where is __asm defined then you fucking retard? What happens when you convert between data pointers and function pointers then you fucking retard? What happens when you do arithmetic with function pointers then you fucking retard?
Name:
Anonymous2012-01-12 11:20
>>262
You're missing the point. The point is that setjmp does in fact alter the stack by pushing registers, flags and calling environment and longjmp pushes that data from the stack, alters the return address and jumps.
Name:
Anonymous2012-01-12 11:22
>>266 What happens when you do arithmetic with function pointers then you fucking retard?
hurr durr pointer arithmetics are undefined behaviour
>>268
This is true in the case of void pointers and function pointers you dumb Jew. Fuck off back to /g/ until you have at least read one of the fucking standards you dumb piece of shit.
ITT
| Can somebody explain why this code outputs what it does?
| hurf durf show your ePenis somewhere else, it's undefined go fuck yourself nerf
Name:
Anonymous2012-01-12 11:28
>>267
There are safe constructs that alter the stack you dumb piece of shit, have you ever of "return" you god damned retard? longjmp is another way of safely altering the stack. Altering it from asm is unsafe and it says so at the fucking GCC page, what kind of mental disability do you have because you must have negative IQ or something.
Name:
Anonymous2012-01-12 11:31
>>271
The original question was answered in the first couple of posts, it either outputs Segmentation fault, the output >>142 or doesn't compile at all. Why you ask? Because it's undefined.
Name:
Anonymous2012-01-12 11:31
>>270
| This is true in the case of void pointers and function pointers
Can't into array of function pointers.
Name:
Anonymous2012-01-12 11:32
>>272
HOW DO YOU THINK LONGJMP IS IMPLEMENTED, fucking moron...
>>275
I think it's implemented safely unlike the fucking retarded shit that's posted in >>1, are you seriously this fucking dense? Why would the GCC manuals explicitly state that it's bad and dangerous to alter the stack through asm? Because your monkey ass is so fucking dumb that you might do something retarded like what was posted in >>1. And please you fucking retard, show us the source code of longjmp and setjmp on your system you dumb piece of shit, come up with some fucking evidence before you talk again.