address of a statement in C

[dandelion]

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

I allready pointed some of the uses of goto, I did not say code using goto's
is by definition "bad", au contraire, I can imagine some quite good code
using goto...

So please elaborate.

If your point was "that's not the only purpose"... Yes. I allready noted
that.

 

[dandelion]

Thomas Stegen <[email protected]> wrote in message
Add more gotos
and labels into the mix, and the headaches increase geometrically.

exponentially.

 

[dandelion]

John Bode wrote:
[snip]

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

Glad you like it. Besides, i haven't missed your point. I just do not agree,
certainly not in the terms you put it.

Code using goto's without having a good reason is (in my view) bad code. For
the reasons Mr Bode pointed out more clearly than I did. Call it whatever
you want, but unless your name is E.W. Dijkstra, i'll probably won't be
persuaded.

 

[dandelion]

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

Without that dogma, programming is impossible.

 

[Thomas Stegen]

John Bode wrote:
[snip]

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

Glad you like it. Besides, i haven't missed your point. I just do not agree,
certainly not in the terms you put it.

Code using goto's without having a good reason is (in my view) bad code.

If you look carefully you will see that I did not express my views on
whether or not to use goto at all. So unless you are a mind reader you
cannot possibly make a statement about whether you agree with them or
not.

 

[dandelion]

John Bode wrote:
[snip]

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

Glad you like it. Besides, i haven't missed your point. I just do not agree,
certainly not in the terms you put it.

Code using goto's without having a good reason is (in my view) bad code.

If you look carefully you will see that I did not express my views on
whether or not to use goto at all. So unless you are a mind reader you
cannot possibly make a statement about whether you agree with them or
not.

Ok.

You win. You have succeeded in conceiling your point so good, I don't see
it, and a mind reader is (apparently) neccesary to do so.

So, politely asking: what the [BEEP] *is* your point?

 

[Thomas Stegen]

Ok.

You win. You have succeeded in conceiling your point so good, I don't see
it, and a mind reader is (apparently) neccesary to do so.

So, politely asking: what the [BEEP] *is* your point?

That the argument "This code is bad because it uses goto" is
bogus. Which is what the statement "Never use goto" basically
boils down to. Most people who argue against goto and invoke
Dijkstra just spout Dogma and usually haven't even read Go to
Statement Considered Harmful.

Which is a paraphrase of what I said originally.

So when you start arguing why goto is bad you are entering a
completely different debate. I am saying that most people who
are vehemently against goto are just regurgitating what someone
else has already regurgitated.

In the abstract I dare put forth the following as truth:

If a piece of code can be best improved by using goto then goto
should be used.

But that is self evident. I have never used goto myself, but if
I find myself in the right situation, I will. So there you have my
view on using goto. (These last three lines, the previous lines
are my view on brainless dogma).

And as a small disclaimer, I am not pointing the finger at anyone
in particular as I am not a mind reader. You will know yourself
whether this applies to you or not.

It is hard to write, because it is hard to read. Hence the previous two
paragraphs.

 

[dandelion]

dandelion wrote:

That the argument "This code is bad because it uses goto" is
bogus.

And that's where I (partially). disagree Code containing goto's
without a very good reason, is bad. The same goes for 'break'
(in loops, not switches) and 'continue'.

Which is what the statement "Never use goto" basically
boils down to.

For rookies, it's my usual advice. Experts (generaly) know good reasons to
employ goto and do not use it without.

Most people who argue against goto and invoke
Dijkstra just spout Dogma and usually haven't even read Go to
Statement Considered Harmful.

That's their miss.

Which is a paraphrase of what I said originally.

I think it's the other way around.

Besides

<quote Go to Statement Considered Harmful, E.W. Dijsktra.>
More recently I discovered why the use of the go to statement has such
disastrous effects, and I became convinced that the go to statement should
be abolished from all "higher level" programming languages (i.e. everything
except, perhaps, plain machine code).
</quote>

Dijkstra argues in favor of abolishing goto alltogether in higher level
languages. And

<quote>
The unbridled use of the go to statement has an immediate consequence that
it becomes terribly hard to find a meaningful set of coordinates in which to
describe the process progress.
[...]
The difficulty is that such a coordinate, although unique, is utterly
unhelpful. In such a coordinate system it becomes an extremely complicated
affair to define all those points of progress where, say, n equals the
number of persons in the room minus one!
</quote>

He cites (allbeit paraprased) breaking invariants as one (if not, the main)
reason.

So when you start arguing why goto is bad you are entering a
completely different debate.

I think not. In fact, you make it clear that I understood correctly the
first time round.

I am saying that most people who
are vehemently against goto are just regurgitating what someone
else has already regurgitated.

In the abstract I dare put forth the following as truth:

If a piece of code can be best improved by using goto then goto
should be used.

Ok. I'll follow.

* This is a very rare occasion.
* If that piece of code becomes harder to maintain/understand, i'll throw
your "truth" (and the goto with it) out of the window.

Admittedly the second does depend on what you call "improved".

But that is self evident. I have never used goto myself, but if
I find myself in the right situation, I will. So there you have my
view on using goto. (These last three lines, the previous lines
are my view on brainless dogma).

You, perhaps, discount other views as "brainless dogma" too soon.

And as a small disclaimer, I am not pointing the finger at anyone
in particular as I am not a mind reader. You will know yourself
whether this applies to you or not.

It is hard to write, because it is hard to read. Hence the previous two
paragraphs.

I'll quote Dijkstra again.

"The go to statement as it stands is just too primitive; it is too much an
invitation to make a mess of one's program. "

And

"The remark about the undesirability of the go to statement is far from new.
I remember having read the explicit recommendation to restrict the use of
the go to statement to alarm exits, but I have not been able to trace it;
presumably, it has been made by C. A. R. Hoare. In [1, Sec. 3.2.1.] Wirth
and Hoare together make a remark in the same direction in motivating the
case construction: "Like the conditional, it mirrors the dynamic structure
of a program more clearly than go to statements and switches, and it
eliminates the need for introducing a large number of labels in the
program."

And leave you with these remarks for consideration.

 

[Thomas Stegen]

And that's where I (partially). disagree Code containing goto's
without a very good reason, is bad. The same goes for 'break'
(in loops, not switches) and 'continue'.

My point is simply that "goto is bad because it is goto" does not
stand up to scrutiny because it is circular and I reacted because I
see and hear that particular one quite often.

<quote>
The unbridled use of the go to statement has an immediate consequence that
it becomes terribly hard to find a meaningful set of coordinates in which to
describe the process progress.

This is simply false because it is stated as an absolute. What is true
is that goto is the perfect tool for making a mess of code. But there is
nothing immidiate or unavoidable about it. Code with goto in it can
usually, not always, but almost always, be written just as well without
goto. Never written code myself with gotos so yeah...

Of course, as a piece of rhethoric it is not so bad.

[...]
The difficulty is that such a coordinate, although unique, is utterly
unhelpful. In such a coordinate system it becomes an extremely complicated
affair to define all those points of progress where, say, n equals the
number of persons in the room minus one!
</quote>

He cites (allbeit paraprased) breaking invariants as one (if not, the main)
reason.

I never disagreed that goto can break invariants. I have in fact
disagreed with very little of what you have said, just your
interpretation of my position.

I think not. In fact, you make it clear that I understood correctly the
first time round.

When I say this particular argument is bad because such and such
I am not necessarily supporting either side of the argument. That's
me, I am aware most people usually don't poke holes in bogus arguments
which purports to support their side. Maybe this is the cause of
our confusion.

Ok. I'll follow.

* This is a very rare occasion.

From my experience this is a very rare occasion. Others might have
other experiences.

* If that piece of code becomes harder to maintain/understand, i'll throw
your "truth" (and the goto with it) out of the window.

Admittedly the second does depend on what you call "improved".

It does, but it depends on what I call "best improved". If it adversely
affects your code in a way which outways the benefits then it is no
longer really best improved any more. It is a pragmatic judgement.

You, perhaps, discount other views as "brainless dogma" too soon.

Nope, my view is that goto is most often obfuscatory and unnecessary. So
you see that I don't discount your views at all.

I am saying that this kind argument is bad (I have actually seen this
said):

"The second example is cleaner and a bit easier to read than the first,
but it of course uses goto so the first example wins." (paraphrased).

I have not been able to find this articlem again. Feel free to look for
it though.

I'll quote Dijkstra again.

[snip]

And leave you with these remarks for consideration.

I considered them in depth a couple of years ago when I first read his
article and found that I mostly agree with them.

 

[dandelion]

dandelion wrote:

My point is simply that "goto is bad because it is goto" does not
stand up to scrutiny because it is circular and I reacted because I
see and hear that particular one quite often.

Fair enough.

This is simply false because it is stated as an absolute.

Methinks you missed "unbridled", mistook "terribly hard" for impossible and
forget that Dijkstra wrote at a time when Algol was considered very
advanced. Goto's were more abundant in those days.

What is true is that goto is the perfect tool for making a mess of code. But there is
nothing immidiate or unavoidable about it. Code with goto in it can
usually, not always, but almost always, be written just as well without
goto. Never written code myself with gotos so yeah...

I have.

Of course, as a piece of rhethoric it is not so bad.

Even properly placed goto's (ones would agree with) make it hard to follow
the flow of control. But (thinking of Knuth) program design is as much an
art as it is a science. Tastes tend to differ.

I never disagreed that goto can break invariants. I have in fact
disagreed with very little of what you have said, just your
interpretation of my position.

Ok. Let's just say we had this discussion for the benefit of lurking
rookies.

<snip>

Regards,

dandelion.

 

[Michael Wojcik]

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).

Sheer nonsense. Using break to escape from a loop - which is its only
use, except for breaking from a switch - violates the loop invariant.
(Or, more precisely, it adds a "hidden" invariant to the loop.) Since
control remains in the loop until the invariants no longer hold, *by
definition* encountering a break statement represents a new invariant.

Ditto any return from within a loop - that is, any return in the scope
of an invariant.

They have precisely the same effect on invariants as does goto, and for
precisely the same reason.

Just use them right.

An empty statement.

Returns and breaks do not mess up *my* code.

goto doesn't mess *mine* up. We can play vapid arguments all day if
you like.

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.

And I claim that your explanation and "'proper' usage" are bogus.

 

[Michael Wojcik]

Code using goto's without having a good reason is (in my view) bad code.

A pointless statement. Code that does anything without good reason
must by definition either do it for a poor reason, or do it for no
reason at all. Given finite resources, the latter is tantamount to
the former. Thus code that does anything without good reason is bad
code. Nothing special about goto there.

For the reasons Mr Bode pointed out more clearly than I did.

John's argument is little better than yours. He identified one case
of poor use of goto. Again, this generalizes to "a poor coding
practice is a poor coding practice".

I *have* seen cogent arguments against the use of goto in a variety
of contexts that reveal issues that may not be immediately apparent
to practitioners. I haven't seen any of them in this thread, though.
What I've seen here are overstated admonishments and hand-waving.
I'd hope that competent programmers ask for more when they're being
instructed to adopt some practice.

Call it whatever you want, but unless your name is E.W. Dijkstra,
i'll probably won't be persuaded.

And now you're reduced to argument by authority. I think your
position can safely be declared unsubstantiated.

Feel free to come back when you have a real argument.

--
Michael Wojcik (e-mail address removed)

Thanks for your prompt reply and thanks for your invitatin to your
paradise. Based on Buddihism transmigration, I realize you, European,
might be a philanthropist in previous life!
-- supplied by Stacy Vickers

 

[Stephen Sprunk]

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.

For the code fragment above, there's not enough information. Try this:

i = 1;
do {
x = 2 * i;
printf("%d", x);
...
} while (...);

Can you say with any confidence what the value of x will be at any given
time? Not until you've accounted for every if and loop and traced every
possible execution path.

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.

One can do equally perverse things with enough loops and ifs. Bad code is
bad code regardless of the constructs used. Goto makes bad code easier to
write, but their presence is not proof that the code is bad.

S

 

[Keith Thompson]

exponentially.

John Bode wrote the quoted text; the only thing you quoted that I
actually wrote was my name. (I don't think his use of the word
"geometrically" was incorrect, but hey, let's talk about C instead.)

 

[Mabden]

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?

Just put a label there - you don't need an address.

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?

Goto the label.

 

[Flash Gordon]

On 5 Nov 2004 01:40:17 -0800

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 ?

void isr(void)
{
/* Common startup code */

do {
if (contition1) {
/* do some handling. */
break;
}

if (contition2) {
/* do some handling. */
break;
}

if (contition3) {
/* do some handling. */
break;
}
} while (0);

/* common clean up */
}

I'm not saying it is better, but with a decent compiler it should be no
less efficient than using goto.

Having said that, I do use goto for exception processing some of the
time. You just have to think about what will be easiest to read and
avoid creating spaghetti code using goto.

IMHO it would have been nice if C99 had added something like:

_try {
/* code */

_exception(int);

/* code */
}
_recover (variable_that_receives_exception_code) {
/* code */
}

With the ability to nest this and to generate exceptions from within the
_recover block you could do a lot.

 

[Mabden]

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.

Old Meyers books used to recommend this as best practice back when
BASIC, Fortran, etc. were using goto's to jump around in code. He
codified the idea that "one entry, one exit" was best practice. Later
the "one exit" idea was depreciated, and in C in particular, exiting at
earliest opportunity seems the better idea.

Goto's can still be use sensibly as forward jumps within a routine -
i.e. NOT for looping. This is usually when the logic structure is very
deep or you want to perform a common series of commands (as in a
database read). For instance, a loop where you can't "continue" since
you need to get the next record first.

getfirst(x);
while (x)
{
switch (rec_type)
{
case one:
if (!do_that(&y)) goto Next;
process (y);
break;

case two:
if (!do_this(&y)) return (false);
if (*y > 10) goto Next;
break;
}

:Next
getnext(x);
}

 

[Kenny McCormack]

John Bode wrote:
[snip]

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

Glad you like it. Besides, i haven't missed your point. I just do not agree,
certainly not in the terms you put it.

Code using goto's without having a good reason is (in my view) bad code. For

This is, of course, true for all language features. For example:

Code using printf without having a good reason is bad code.

Note that using printf increases the size of your executable.
It should, therefore, not be used w/o a good reason.

 

[Tim Rentsch]

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?

[some generally similar comments snipped]

The tone here is that the effects of using 'goto' aren't that much
different from using 'break' or (presumably early) 'return'. That's
not so, for both a theoretical reason and a practical reason.

The theoretical reason is that 'goto' can lead to irreducible flow
graphs. Early returns or using 'break' to exit a loop (or a 'switch')
cannot cause irreducible flow graphs. Irreducible flows are more
difficult to reason about than reducible flow graphs.

The practical reason is that programs using 'goto' are harder to
comprehend than programs using early returns or loop exits. At least,
that was the conclusion of studies that were done looking at how the
different control mechanisms affected programmer performance. (Sorry
I don't have a citation handy; I think it was in Software Practice
and Experience, sometime in the early 1980's, or maybe late 1970's.)

The question about 'goto', I think, is not whether it's absolutely ok
or absolutely not ok, but under which circumstances is it ok. Most
developers that are (IMO) conscientious and competent limit their use
of 'goto' to very particular styles of use, and don't really use it
otherwise. And, this limitation is more often observed with 'goto'
than with (for example) 'return' or 'break'.

My own (informal) rules for goto are: (1) only forward, never
backward, (2) never into a nested scope, and (3) target label
at the outermost level in a function body. (Yes I know 2 and
3 are not independent. Furthermore, it doesn't come up very
often - the most common case for code that I write is for whole
files to have not a single 'goto' in them. At the other end
of the scale, I would guess files with early returns happen
more often than not, and occurrences of 'break' being somewhere
in the middle.

Anyone else want to register their views on when goto's
are/aren't acceptable coding practice?

 

[Tim Rentsch]

This is simply false because it is stated as an absolute. What is true
is that goto is the perfect tool for making a mess of code. But there is
nothing immidiate or unavoidable about it.

Note that the quote says "The UNBRIDLED use" of goto. When the use of
goto is truly "unbridled", the quoted statement is a lot closer to
true than it is to false. Wouldn't you agree?