address of a statement in C

[candy]

hi all,

Is there is any way in the C language by which I can get the

address of a statement? For eg,consider the following simple program:

1. #include<stdio.h>
2.
3. int main(void){
4. int variable;
5. return 0;
6. }

Well is there is any way by which I can know the address of the
statement which is in the line 4?

Also,if I know the address of a statement then can I

transfer the control to that statement by equating program

counter equal to that address? Well,I can access as well as

modify the program counter with the help of the

setjmp(jmp_buf env) function.


Thanks in advance,
Candice.

 

[Joona I Palaste]

hi all,

Is there is any way in the C language by which I can get the

address of a statement? No.

For eg,consider the following simple program:

1. #include<stdio.h>
2.
3. int main(void){
4. int variable;
5. return 0;
6. }

Well is there is any way by which I can know the address of the
statement which is in the line 4?
No.

Also,if I know the address of a statement then can I

transfer the control to that statement by equating program

counter equal to that address? Well,I can access as well as

modify the program counter with the help of the

setjmp(jmp_buf env) function.

That's as close as you're going to get.

 

[Joona I Palaste]

hi all,

Is there is any way in the C language by which I can get the

address of a statement? No.

For eg,consider the following simple program:

1. #include<stdio.h>
2.
3. int main(void){
4. int variable;
5. return 0;
6. }

Well is there is any way by which I can know the address of the
statement which is in the line 4?
No.

Also,if I know the address of a statement then can I

transfer the control to that statement by equating program

counter equal to that address?
No.

Well,I can access as well as

modify the program counter with the help of the

setjmp(jmp_buf env) function.

That's as close as you're going to get.

 

[Gordon Burditt]

Is there is any way in the C language by which I can get the

address of a statement?

Not portably, and there is no reason why a statement needs to
HAVE an address. Some statements generate no code at all.

For eg,consider the following simple program:

1. #include<stdio.h>
2.
3. int main(void){
4. int variable;
5. return 0;
6. }

Well is there is any way by which I can know the address of the
statement which is in the line 4?

The statement on line 4 may have no effect on the code at all.
The variable can be optimized out for the code shown. Or
it could be put in a register which does not HAVE an address.

Code for some statements may be scattered all over the map
rather than grouped in one place: 'for' statements are
likely an example of this.

Also,if I know the address of a statement then can I
transfer the control to that statement by equating program
counter equal to that address?

The program counter should not ever equal the address of "variable".
What does it mean to transfer control to a data declaration?
If you transfer control to random statements, there is no guarantee
that you won't run into problems (e.g. stack imbalance).

Even if the statement generated code (for example, code to initialize
the value of variable) there's no guarantee it occurs in a sequence
like it occurs in the code.

Well,I can access as well as
modify the program counter with the help of the
setjmp(jmp_buf env) function.

Not portably.

Gordon L. Burditt

 

[pete]

hi all,

Is there is any way in the C language by which I can get the

address of a statement? For eg,consider the following simple program:

1. #include<stdio.h>
2.
3. int main(void){
4. int variable;
5. return 0;
6. }

Well is there is any way by which I can know the address of the
statement which is in the line 4?

Also,if I know the address of a statement then can I

transfer the control to that statement by equating program

counter equal to that address? Well,I can access as well as

modify the program counter with the help of the

setjmp(jmp_buf env) function.

Are you familiar with goto?

 

[Neil Kurzman]

Are you familiar with goto?

goto will work (in scope this in not BASIC) But should be avoided at all
costs.
There are usually better ways to do it.

 

[suman kar]

hi all,

Is there is any way in the C language by which I can get the

address of a statement? For eg,consider the following simple program:

1. #include<stdio.h>
2.
3. int main(void){
4. int variable;
5. return 0;
6. }

Well is there is any way by which I can know the address of the
statement which is in the line 4?

Also,if I know the address of a statement then can I

transfer the control to that statement by equating program

counter equal to that address? Well,I can access as well as

modify the program counter with the help of the

setjmp(jmp_buf env) function.


Thanks in advance,
Candice.

You can use a label/goto if you are really out to murder sequential flow
But i guess you already tried that and that is not enough
Regards
Suman.

 

[Keith Thompson]

goto will work (in scope this in not BASIC) But should be avoided at all
costs.
There are usually better ways to do it.

goto should usually be avoided, but not "at all costs". For example,
it's often the cleanest way to exit from a nested loop. (A labeled
break statement would be even better, but C doesn't have one.)

A goto can also be a sensible way (but not the only way) to implement
a finite state machine.

 

[Sreenivas]

hi all,

Is there is any way in the C language by which I can get the

address of a statement? For eg,consider the following simple program:

1. #include<stdio.h>
2.
3. int main(void){ 3.1 mylabel:
4. int variable;
5. return 0;
6. }

how about defining a label? like i did... look at statment ( 3.1 mylabel: )
i guess that works, i haven't checked though...
-Sreenivas T.

 

[Thomas Stegen]

goto should usually be avoided, but not "at all costs". For example,
it's often the cleanest way to exit from a nested loop. (A labeled
break statement would be even better, but C doesn't have one.)

A goto can also be a sensible way (but not the only way) to implement
a finite state machine.

There seems to be a wide spread consensus that code that uses goto
is bad because it uses goto. This utterly utterly wrong. I have even
seen arguments to the effect of "this code is a bit cleaner, but it
uses goto so it is worse".

Utter, utter BS if you ask me. Code is not bad because of any particular
feature it uses. It is bad because it is hard to read and follow.

Goto is a great tool for making code hard to follow, but that is not the
only purpose of goto.

Avoid goto at all costs? Even if the cost is higher than including the
goto? (Which is a cost covered by the set of all costs). Sounds like
dogma to me.

 

[Sreenivas]

_goto_ statments in C wud do the same job, check out any standard C
Language book, to find out how to use them. But everyone suggests not
to use GOTO statements.
Cheers,
Sreenivas T.

 

[dandelion]

There seems to be a wide spread consensus that code that uses goto
is bad because it uses goto. This utterly utterly wrong. I have even
seen arguments to the effect of "this code is a bit cleaner, but it
uses goto so it is worse".

The main reason for a general dislike of goto is that it makes a joke
of your invariants and (therefore) tends to get messy.

This is inherent in the nature of that "feature".

Utter, utter BS if you ask me.

Code is not bad because of any particular
feature it uses.

Code is bad when it's invariants aren't clear. Using "goto" will get you
there in no time flat.

It is bad because it is hard to read and follow.

Goto is a great tool for making code hard to follow, but that is not the
only purpose of goto.

Ah... You get that point.

Avoid goto at all costs? Even if the cost is higher than including the
goto?

I can hardly think of an example, provided a good optimizing compiler is
used.

(Which is a cost covered by the set of all costs). Sounds like
dogma to me.

Ok. Then it's "dogma" as in "invariants are just dogma".

Code using goto's can (usually) be replaced by some default structure. The
problem with goto is that it invites you to come up up with alternate loop
and if/then/else structures. If you turn down that "invitation" you'll find
that the standard structures (do, while, etc) will satisfy almost every
programming need, especially in combination with "break" and "continue",
which, after all, are little more than goto's in a fancy dress.

Hence: code with goto's is bad, unless you've got a *very* good reason for
using it. Such a reason could be optimizing or error-handling (see the Linux
kernel for an example of that), but little more.

Regards,

dandelion.

 

[Michael Wojcik]

The main reason for a general dislike of goto is that it makes a joke
of your invariants and (therefore) tends to get messy.

This is inherent in the nature of that "feature".

True of return and break as well. Shall we eschew them?

Code is bad when it's invariants aren't clear. Using "goto" will get you
there in no time flat.

As will any number of other constructions.

Code using goto's can (usually) be replaced by some default structure.

Any C code that uses goto can be rewritten to not use goto. So what?

The
problem with goto is that it invites you to come up up with alternate loop
and if/then/else structures.

"Feature X invites poor practice Y" is true for some Y for nearly every
X.

If you turn down that "invitation" you'll find
that the standard structures (do, while, etc) will satisfy almost every
programming need, especially in combination with "break" and "continue",
which, after all, are little more than goto's in a fancy dress.

They're nothing more than goto with implicit labels. And while
continue does not add a "hidden invariant", break certainly does,
so your criticism of goto applies just as well to break. In fact,
it applies more strongly, because goto can be used in a manner
that doesn't affect invariants, whereas break cannot (except when
used to exit from a switch statement).

Hence: code with goto's is bad, unless you've got a *very* good reason for
using it.

No construct should ever be used unless there's a good reason for
doing so. I don't believe you've made the case that goto is special
in this regard.

Such a reason could be optimizing or error-handling (see the Linux
kernel for an example of that), but little more.

I use goto extensively to provide a single point of return from
functions, which I find particularly useful as a "finally" mechanism
for resource cleanup. No other C mechanism serves this purpose so
well.

--
Michael Wojcik (e-mail address removed)

It's like being shot at in an airport with all those guys running
around throwing hand grenades. Certain people function better with
hand grenades coming from all sides than other people do when the
hand grenades are only coming from inside out.
-- Dick Selcer, coach of the Cinci Bengals

 

[Jens.Toerring]

how about defining a label? like i did... look at statment ( 3.1 mylabel: )
i guess that works, i haven't checked though...

No, that won't work, you can't have a label in a place where you still
are defining variables (at least in C89, I don't know if it would be
allowed in C99 where you also can have variable declarations after the
first executable statement).
Regards, Jens

 

[John Bode]

There seems to be a wide spread consensus that code that uses goto
is bad because it uses goto. This utterly utterly wrong. I have even
seen arguments to the effect of "this code is a bit cleaner, but it
uses goto so it is worse".

Utter, utter BS if you ask me. Code is not bad because of any particular
feature it uses. It is bad because it is hard to read and follow.

Goto is a great tool for making code hard to follow, but that is not the
only purpose of goto.

Avoid goto at all costs? Even if the cost is higher than including the
goto? (Which is a cost covered by the set of all costs). Sounds like
dogma to me.

The main problem with using gotos and associated labels is that it can
destroy the ability do debug code by inspection. Assume the following
code fragment:

...
i = 1;
label: x = 2 * i;
printf("%d", x);
...

Can you say with any confidence what the value of x will be at any
given time? Not until you've accounted for every goto and traced
every possible execution path. If your function is 50 lines or so, no
problem. If it spans several pages, it gets harder. Add more gotos
and labels into the mix, and the headaches increase geometrically.
I've told the story several times of a coworker having to debug a 5000
line main() function with 13 gotos branching both directions. Took
him two weeks to figure out the flow of control.

It's possible to use goto in a manner that is structured and doesn't
lead to maintenance headaches. I've put gotos into production code on
a couple of occasions (mainly to break out of deeply nested loops),
but for the most part, it's best to avoid the practice.

 

[junky_fellow]

Avoid goto at all costs? Even if the cost is higher than including the
goto? (Which is a cost covered by the set of all costs). Sounds like
dogma to me.

I have seen some Interrupt handlers that extensively use goto (most
probable
due to efficiency). I could not find any other way that would be
faster as compared to goto.
For eg. Suppose multiple events may have occurred for a particular
resource when its ISR is called. In the ISR, all the events have to be
handled. If some error event occurred no need to handle other events,
just return from ISR.

----------------------------------------------------
ISR:

if error event :
do some handling.
goto ISR_DONE <== donts waste time in checking for other
events.
Simply return.

if event1 :
do some handling. <== handle other events as well.

if event2 :
do some handling.
goto ISR_DONE <== if event2 has occurred, no need to handle
other.
don't waste time in checking for other
events.
if event4 :
some handling.

ISR_DONE:
return
--------------------------------------------------------------

So, in the above scenario, the goto are more efficient. They prevent
from unnecessary checking of other events in case some error occurs.
Is this the right way of doing things ?
Can we achieve better efficiency using some other way ?

 

[dandelion]

True of return and break as well.

Nope. Return and break do not break any invariants if used properly. But
yes, it'sposible to create a mess using these two (preferably in combination
with lots of 'continue' statements).

Shall we eschew them?

Just use them right. Returns and breaks do not mess up *my* code. Besides,
you did not hear me promoting exchewing 'goto', just writing a warning
message and explaining just *why* goto has a bad reputation (one it fully
deserves). I even indicated "proper" usage.

So your post is directed at a strawman.

 

[Thomas Stegen]

John Bode wrote:
[snip]

It is nice to see how you and Dandelion manage to completely
miss the point.

No, I won't enlighten you. Read what I wrote and see that there
is nothing in there that disagrees with your post.

 

[Richard Bos]

Ok. Then it's "dogma" as in "invariants are just dogma".

I have no problem with that. In my experience, invariants often are
indeed nothing but dogma.

Richard

 

[Thomas Stegen]

Ah... You get that point.

But you didn't get mine. Please try harder.