global goto in c

[fir]

I want to ask if some global goto
could be done in c (specifically in c with
inline assembly extension) (in this
time I cannot even run compiler and test
it myself so sorry for that)

something like

inline goto(void* label)
{
asm
{
jmp label;
}
}

I understand that in c you could
get adress of any "label:" you could
then pass it to assembly as a jump
argument and then it should work (?)

(prof. fir)

 

[glen herrmannsfeldt]

I want to ask if some global goto
could be done in c

You mean like longjmp()?

-- glen

 

[fir]

W dniu czwartek, 6 czerwca 2013 10:47:28 UTC+2 użytkownik glen herrmannsfeldt napisał:

You mean like longjmp()?

no, like

e()
{
label:

}

main()
{
goto(label); //label is any label in any function

}

 

[Xavier Roche]

no, like

e()
{
label:

}

main()
{
goto(label); //label is any label in any function

}

Short answer: no. Entering in another function or inside a block require
to have some stack/heap initialization, and this is just not possible.
setjmp/longjmp tricks may be used, but only to rollback from a given
point (ie. going back in a context deeper in the stack has a totally
undefined behavior - correct me if I am wrong)

 

[fir]

W dniu czwartek, 6 czerwca 2013 11:37:39 UTC+2 użytkownik Xavier Rochenapisał:

Short answer: no. Entering in another function or inside a block require

to have some stack/heap initialization, and this is just not possible.

setjmp/longjmp tricks may be used, but only to rollback from a given

point (ie. going back in a context deeper in the stack has a totally

undefined behavior - correct me if I am wrong)

you do not need to use stack variables
just

f()
{

f1_label:

// some code

goto(main1_label);

}

main()
[
goto(f1_label);
//some code

main1_label:
}

should probably work, but i am not sure
as to casting labels on void* and then
passing this to assembly

 

[BartC]

I want to ask if some global goto
could be done in c (specifically in c with
inline assembly extension) (in this
time I cannot even run compiler and test
it myself so sorry for that)

something like

inline goto(void* label)
{
asm
{
jmp label;
}
}

I understand that in c you could
get adress of any "label:" you could
then pass it to assembly as a jump
argument and then it should work (?)

No. With gcc, you can obtain a label address using &&label, but the label
has to be within scope, which means in the local function.

It is possible to assign that label address to a file-scope variable, and
attempt to 'goto' that address from another function, but it will likely
crash because of other considerations. It will in any case need tricky setup
of those addresses.

 

[Johann Klammer]

W dniu czwartek, 6 czerwca 2013 11:37:39 UTC+2 użytkownik Xavier Roche napisał:

Short answer: no. Entering in another function or inside a block require

to have some stack/heap initialization, and this is just not possible.

setjmp/longjmp tricks may be used, but only to rollback from a given

point (ie. going back in a context deeper in the stack has a totally

undefined behavior - correct me if I am wrong)

you do not need to use stack variables
just

f()
{

f1_label:

// some code

goto(main1_label);

}

main()
[
goto(f1_label);
//some code

main1_label:
}

should probably work, but i am not sure
as to casting labels on void* and then
passing this to assembly

Yes, that'll probably work, but why the function, then?
You cannot use it for return, because the return address is not on stack
frame and base ptr etc are all wrong... it would jump to nirvana... If
you are trying to set up something coroutine like, you'll want to look
at POSIX' ucontext.h. It's available on most unices and similar
functionality can often be hacked up on other OSs.

 

[Eric Sosman]

I want to ask if some global goto
could be done in c (specifically in c with
inline assembly extension) (in this
time I cannot even run compiler and test
it myself so sorry for that)

something like

inline goto(void* label)
{
asm
{
jmp label;
}
}

I understand that in c you could
get adress of any "label:" you could
then pass it to assembly as a jump
argument and then it should work (?)

No.

First, in C there is no way to take the address of a label.

Second, if you could somehow get the address of a label (some
compilers offer this capability as an extension), there is no
assurance that a void* could represent that address.

Third, if you could somehow get the label's address and cram
it into a void* (or some other type), jumping into the middle of
a piece of code without first establishing the environment the
code relies on is a bad idea. For example, if the code at the
point of the label expects a frame pointer to aim HERE and a
return address to live THERE and register R5 to hold the value
of `a+b', how will you establish the preconditions?

Fourth -- Oh, the heck with it. Just "No" suffices.

(prof. fir)

Out of curiosity: What subject do you teach, Professor?

 

[fir]

W dniu czwartek, 6 czerwca 2013 14:59:47 UTC+2 użytkownik Eric Sosman napisał:

No.



First, in C there is no way to take the address of a label.



Second, if you could somehow get the address of a label (some

compilers offer this capability as an extension), there is no

assurance that a void* could represent that address.



Third, if you could somehow get the label's address and cram

it into a void* (or some other type), jumping into the middle of

a piece of code without first establishing the environment the

code relies on is a bad idea. For example, if the code at the

point of the label expects a frame pointer to aim HERE and a

return address to live THERE and register R5 to hold the value

of `a+b', how will you establish the preconditions?



Fourth -- Oh, the heck with it. Just "No" suffices.






Out of curiosity: What subject do you teach, Professor?

I am specally interested in the c language
improvements. (but have not to much time
this time to stop here, just asking the
question)

 

[fir]

W dniu czwartek, 6 czerwca 2013 14:28:12 UTC+2 użytkownik Bart napisał:

No. With gcc, you can obtain a label address using &&label, but the label

has to be within scope, which means in the local function.



It is possible to assign that label address to a file-scope variable, and

attempt to 'goto' that address from another function, but it will likely

crash because of other considerations. It will in any case need tricky setup

of those addresses.

If so it is damn sad, i think this label
adresses could be avaliable/accesible.

 

[fir]

W dniu czwartek, 6 czerwca 2013 14:30:14 UTC+2 użytkownik Johann Klammer napisał:

W dniu czwartek, 6 czerwca 2013 11:37:39 UTC+2 użytkownik Xavier Roche napisał:

On 06/06/2013 11:29 AM, fir wrote:

no, like



e()

{

label:



}



main()

{

goto(label); //label is any label in any function



}



Short answer: no. Entering in another function or inside a block require

to have some stack/heap initialization, and this is just not possible.

setjmp/longjmp tricks may be used, but only to rollback from a given

point (ie. going back in a context deeper in the stack has a totally

undefined behavior - correct me if I am wrong)

you do not need to use stack variables

just

f()

{

f1_label:

// some code

goto(main1_label);

}

main()

[

goto(f1_label);

//some code

main1_label:

}

should probably work, but i am not sure

as to casting labels on void* and then

passing this to assembly

Yes, that'll probably work, but why the function, then?

You cannot use it for return, because the return address is not on stack

frame and base ptr etc are all wrong... it would jump to nirvana... If

you are trying to set up something coroutine like, you'll want to look

at POSIX' ucontext.h. It's available on most unices and similar

functionality can often be hacked up on other OSs.

indeed it was in the context of the coroutine
stuff (where it could help to write/implement
such coroutines in c I think, but do not matter)

 

[Mark Storkamp]

W dniu czwartek, 6 czerwca 2013 11:37:39 UTC+2 u›ytkownik Xavier Roche
napisa½:

Short answer: no. Entering in another function or inside a block require

to have some stack/heap initialization, and this is just not possible.

setjmp/longjmp tricks may be used, but only to rollback from a given

point (ie. going back in a context deeper in the stack has a totally

undefined behavior - correct me if I am wrong)

you do not need to use stack variables
just

f()
{

f1_label:

// some code

goto(main1_label);

}

main()
[
goto(f1_label);
//some code

main1_label:
}

should probably work, but i am not sure
as to casting labels on void* and then
passing this to assembly

If f() contained any local variables, you wouldn't be able to use them
since the stack frame hasn't been set up. (and let's please not go down
the rabbit hole of c not requiring a stack). So you might just as well
make the code between f1_label: and the goto into a function of its own,
and call it from both main and from f(). Perhaps you can even inline it.

 

[Noob]

Out of curiosity: What subject do you teach, Professor?

Isn't it obvious? He teaches (us) the art of trolling.

Regards.

 

[Eric Sosman]

Isn't it obvious? He teaches (us) the art of trolling.

You'll notice that he responded to my question, but
did not answer it.

 

[Jorgen Grahn]

W dniu czwartek, 6 czerwca 2013 14:30:14 UTC+2 u??ytkownik Johann Klammer napisa??:

Please fix your newsreader. Seriously.

/Jorgen

 

[glen herrmannsfeldt]

(snip)

Seems right to me. PL/I has LABEL variables and a global GOTO
using them, but again, you can only go back in the call tree.

The last (and maybe only) time I rememeber using longjmp() was for
a translation of a Pascal program that used a global GOTO.
(I believe to go out of an internal procedure.)

(snip)

It might have a chance in Fortran 66, where there is no recursion,
all variables are static (in most implementations) but not in any
language allowing recursion.

If f() contained any local variables, you wouldn't be able to use them
since the stack frame hasn't been set up. (and let's please not go down
the rabbit hole of c not requiring a stack). So you might just as well
make the code between f1_label: and the goto into a function of its own,
and call it from both main and from f(). Perhaps you can even inline it.

Yes, PL/I, in the IBM implementations uses a linked list instead of
a (physical) stack, but it is logically a stack. The library routines
that handle global GOTO know how to undo what needs to be undone,
and to report an error for illegal GOTOs.

I believe both longjmp() and PL/I GOTO know about recursion, and
return to the appropriate instance of a recursive procedure.

-- glen

 

[Keith Thompson]

Please fix your newsreader. Seriously.

It's not his newsreader; the problem is that he's not using one.

groups.google.com causes this problem. In articles posted via Google
Groups, each quoted line (introduced by "> ") is treated as a
*paragraph*. This results in quoted text being double-spaced, then
quadruple-spaced, etc.

This probably works ok for Google's own web-based groups, but clearly
Google's convention interacts poorly with the plain-text posts produced
by most uses of NNTP newsreaders. Google has shown no signs of caring
about this problem.

fir, if you copy-and-paste your articles into a text editor, manually
edit them, and then copy them back into your browser before posting, it
*might* alleviate the problem. Better yet, get an account on a free or
cheap NNTP server (I use news.eternal-september.org) and use an
NNTP-based client program (Mozilla Thunderbird can do this).

 

[fir]

W dniu czwartek, 6 czerwca 2013 19:45:06 UTC+2 użytkownik Keith Thompson napisał:

It's not his newsreader; the problem is that he's not using one.
groups.google.com causes this problem. In articles posted via Google
Groups, each quoted line (introduced by "> ") is treated as a
*paragraph*. This results in quoted text being double-spaced, then
quadruple-spaced, etc.



This probably works ok for Google's own web-based groups, but clearly
Google's convention interacts poorly with the plain-text posts produced
by most uses of NNTP newsreaders. Google has shown no signs of caring
about this problem.



fir, if you copy-and-paste your articles into a text editor, manually
edit them, and then copy them back into your browser before posting, it
*might* alleviate the problem. Better yet, get an account on a free or
cheap NNTP server (I use news.eternal-september.org) and use an
NNTP-based client program (Mozilla Thunderbird can do this).

ye, thats google groups,
The best would be if they would repair it
(most of the time i prefer just to dont care
;(
Tried some newsreaders but dislike them, some
www usenet news gate could be good but i do
not know one (must be free - i was trying narkive but something did not work, i couldnt
register)
Besides I am searching for some good usenet
group about programming games and algorithms/
ways of programming things (in c) is there
some alive and reasonably good (some specialist onboard) usenet group for that?

fir

 

[fir]

W dniu czwartek, 6 czerwca 2013 21:17:33 UTC+2 użytkownik Scott Fluhrer napisał:

W dniu czwartek, 6 czerwca 2013 14:28:12 UTC+2 uzytkownik Bart napisal:





Why, what could you usefully do the label address (apart from jumping to it

within the same routine)?



Suppose you do just from function A() to a label in function B(). Then:



- What values do you expect that the local variables in B to have?



- What do you expect to happen if function B returns?



If you say that, in your problem space, you don't care about either of these

questions, then I would respond that your problem space is too small to

place this potential rake-in-the-grass feature into C; people would expect

reasonable answers to the above questions, and we can't provide them.



You mention coroutines; I believe that most coroutines have local variables

that are expected to be preserved when the coroutine resumes; how would that

work in your design?

In, say, 'most' cases goto do not need passing values
on stack. in some cases it even can do it :
lets say that a 'block' has
five entry-for-goto points, and three
exit-goto points; Entry goto pushes n bytes
of arguments then exit goto clears this
n bytes at exit - It could even be combined
with standard call-entry-point (clear it
before ret, maybe you will need to pass
values of n bytes to clear on exit goto and
m balues to clear on ret encounter or
something like this - it could be done
in some ways. As to usability i do not know
but maybe it could be usefull for something.

 

[fir]

W dniu czwartek, 6 czerwca 2013 20:02:52 UTC+2 użytkownik David Harmonnapisał:

Google "GOTO considered harmful"

sure, I totally do not know whot would be
the outcome of such global-goto programming
(does anybody know?) the classic procedural
way is enough complex