C doubts

[Chris Dollin]

1)can any one give an example for a C program that can be written
using goto only ? i.e a program in which we cannot avoid the keyword
goto

Dik and Al have mentioned a paper showing how to de-goto a program;
I'd just like to add what I found an illuminating tactic in understanding
the possibilities of goto-removal.

You can /clearly/ rewrite a [non-threaded] program into a single loop,
containing a single switch, using a single switch index variable; each
case of the switch does some work and then updates the index to refer
to the next case to execute.

We do this rewriting all the time: it's called "compilation", and the
loop-and-switch is encoded in your processor.

This shows [informally] that (a) you can always de-goto a [threadless]
program, (b) that a formal proof, while satisfying, may not really be
saying very much, and (c) just because some code is "structured" in
terms of while/if-switch/sequence doesn't mean its /good/.

 

[Charlie Gordon]

This code snippet demonstrates that:

switch (integer) {
case 534:
switch (n) {
case 254:
goto goon;
case 566:
//
break;
}
printf("Sub-item for 534 not found");
break;
}
return 0;
goon:
return 6445;
}

Obviously that *could* be rearranged but the point is that the language
does not provide a "named" break statement. If you want to break from
nested switches, nested loops, or nested constructs like that you have
to use the goto statement

You don't really have to, you could use a flag and further tests in the
outer loops/switch constructs. It is just more convenient, if you and your
organization don't mind gotos (which other programmers will find
inconvenient ;-)

Read the documentation
Yes, it will create a file

It will create a file, different from any existing file in the system, but
this file will be removed automatically upon closing its FILE* handle or
upon program termination at the latest. This feature is useful, but might
not be what you need.

 

[Philip Potter]

1)can any one give an example for a C program that can be written
using goto only ? i.e a program in which we cannot avoid the keyword
goto

It depends what you mean. There is no computation which can be done
using goto which cannot be done without using goto. However, there may
be a situation in which using goto is "nicer" than not using goto. The
case I normally use goto is a multi-loop break:

for(i=0;i<I_LIM;i++) {
for(j=0;j<J_LIM;j++) {
condition = f(i,j);
if(condition)
goto afterloop;
}
}
afterloop:

but this can be rewritten without gotos - say, by the use of "done"
flags or by loop unrolling. However, I feel that the goto version is
much nicer. (If C had Perl's feature of labelling loops and breaking by
label, this would be unnecessary.)

Donald Knuth presented a paper in 1974 called "Structured programming
with go to statements":
http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf
It provides some more examples where he feels that gotos result in
"nicer" code than normal structures. (However, I don't think I've ever
used any of the constructs he mentions.)

2)what exactly is the purpose of tmpfile() ? will it open a temporary
file ?

Read the documentation.

3)why there is no article on dangling pointer in the FAQ ?

Probably because it's a big enough concept that it is covered by several
different questions.

 

[Richard Harter]

1)can any one give an example for a C program that can be written
using goto only ? i.e a program in which we cannot avoid the keyword
goto

Perhaps it is worthwhile going into this a bit deeper since most
people haven't read the actual papers. I have and have them
filed away somewhere - where is another matter. Briefly, and to
the best of memory, there is a heirarchy of flow control
structures which runs something like this:

while loop
infinite loop with break
goto fixed target
function call/return
goto selectable target

The first major result was the Boehm-Jacopini theorem that showed
that all other control structures can be translated into while
loops. There is, however, a catch. These translations require
extra code and/or extra time. There are tradeoffs; you can trade
space for time. There are "proof of concept" programs for which
the growth in required space and time is very bad, e.g.,
polynomial growth in time or exponential growth in space as you
increase the program size.

The list is in order of the power of the construct. That is, the
"goto selectable target" construct aka the computed goto or the
switch is the most powerful construct. There are programs that
can be programmed efficiently using switches that cannot
otherwise be programmed efficiently. (These tend to be very
peculiar programs.)

Structured programming uses the while loop, function call/return,
and the switch (which actually is slightly weaker than the
full-blown selectable target goto) with the infinite loop being
optional.

Perhaps the reason that the goto controversey never quite dies is
that in structured programming within the actual body of
functions the constructs that are used (sans switches) are weaker
than the goto. The effect of this is that in some places there
are unavoidable little awkwardnesses. However this doesn't
amount to much because (good) programs are broken into relatively
short functions. This has two good effects. Firstly, since
functions are short the inefficiencies of the weaker constructs
do not accumulate. Secondly, the cumbersome goto is replaced by a
more powerful construct.

IHTH, HAND.


Richard Harter, (e-mail address removed)
http://home.tiac.net/~cri, http://www.varinoma.com
In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die

 

[dj3vande]

Dik and Al have mentioned a paper showing how to de-goto a program;
I'd just like to add what I found an illuminating tactic in understanding
the possibilities of goto-removal.

You can /clearly/ rewrite a [non-threaded] program into a single loop,
containing a single switch, using a single switch index variable; each
case of the switch does some work and then updates the index to refer
to the next case to execute.

We do this rewriting all the time: it's called "compilation", and the
loop-and-switch is encoded in your processor.

Alternatively, ask a nearby functional programmer to explain
continuation-passing style. (This is especially good if you're the
sort of person who likes having your brain explode.)

Having sort of wrapped my head around how that works is even turning
out to be useful for C programming of a less pathological sort than
removing gotos[1], since the GUI toolkit I'm trying to figure out how
to use[2] doesn't appear to support modal loops, so I'm having to write
operations requiring user interaction as chained callbacks in CPS
form: Set up a widget, attach a callback for the next step in the
process, go back to the main event loop and let the widget I just set
up invoke the callback when the user has reacted appropriately. (Or,
at least, that's the first way I came up with to make it work. There
may very well be an obvious and easy way to do what I'm trying to
accomplish that requires a little bit less of a bent mind to understand
it.)


dave

[1] Though I've heard rumours that there are people who would not
exactly describe Xt as "less pathological" than anything this side
of INTERCAL.
[2] ObC: It's implemented as a C API. Actually, it could be
(and, if I'm not mistaken, is or is mostly) implemented entirely in
C-plus-calls-to-a-lower-level-API-also-with-C-bindings, and the
nonportable bits of the whole thing end up being reducible to
not much more than pushing data through a socket.

 

[James Kuyper]

It has been shown (long ago) that any goto implemented program can
be implemented with only if and while.


I have no idea what you are talking about here. Please reference
the place in the C standard that defines these things.

tmpfile(): 7.19.4.3

dangling pointers: while that name is not used in the standard, it is a
name in common use for something the standard does describe: a pointer
whose value used to point at or into an object whose lifetime has since
ended. See 6.2.4p1 for the clause that allows such pointers to be
dangerous to use.

 

[Barry Schwarz]

tmpfile(): 7.19.4.3

dangling pointers: while that name is not used in the standard, it is a
name in common use for something the standard does describe: a pointer
whose value used to point at or into an object whose lifetime has since
ended. See 6.2.4p1 for the clause that allows such pointers to be
dangerous to use.

But it is not allowed. 6.2.4p2 specifically states that the value of
the pointer will indeterminate after the pointed to object's lifetime
has ended. Any use of an indeterminate value results in undefined
behavior.


Remove del for email

 

[pete]

On Sat, 17 Nov 2007 22:21:12 GMT, James Kuyper


But it is not allowed. 6.2.4p2 specifically states that the value of
the pointer will indeterminate after the pointed to object's lifetime
has ended. Any use of an indeterminate value results in undefined
behavior.

I think that is very similar in meaning to:

"allows such pointers to be dangerous to use"

 

[Richard]

But it is not allowed. 6.2.4p2 specifically states that the value of
the pointer will indeterminate after the pointed to object's lifetime
has ended. Any use of an indeterminate value results in undefined
behavior.

No one said it is allowed. James was merely pointing out that "dangling
pointers" is a well known programming issue and is something people
should be aware of. Falconers typically abrasive and rude reply
suggested that because "dangling pointers" are not *specifically*
mentioned in the standard then anyone who talks about the things known
as "dangling pointers" is stupid and ignorant.

 

[Chris Dollin]

Nonsense. The computer world has known better for about 50 years.
IF and WHILE suffice for any language.

WHILE doesn't work at all for pure-functional languages: it relies
on state in a way that IF doesn't.

On a less nit-picky level, I believe you're conflating theoretical
sufficiency with psychological efficacy (and that that's a bad thing).

 

[Chris Dollin]

But it is not allowed. 6.2.4p2 specifically states that the value of
the pointer will indeterminate after the pointed to object's lifetime
has ended. Any use of an indeterminate value results in undefined
behavior.

I think James might be thinking that provoking undefined behaviour would
be dangerous.

 

[Ben Bacarisse]

WHILE doesn't work at all for pure-functional languages: it relies
on state in a way that IF doesn't.

[Nit and now off-topic at that:] SASL and FP have "while". Miranda
and Haskell went for "until" but it could just have easily have been
while. There are probably others. While is quite logical in purely
function languages.

 

[James Kuyper]

On Sat, 17 Nov 2007 22:21:12 GMT, James Kuyper


But it is not allowed. 6.2.4p2 specifically states that the value of
the pointer will indeterminate after the pointed to object's lifetime
has ended. Any use of an indeterminate value results in undefined
behavior.

The standard doesn't disallow it; it only says that the behavior is
undefined. It's up to the programmer to realize that undefined behavior
is a bad idea. If the programmer doesn't realize that, and writes and
executes the program anyway, the clauses that you and I referred to are
the ones that allow the implementation to produce results that the
programmer would probably be very unhappy about.

 

[Chris Dollin]

WHILE doesn't work at all for pure-functional languages: it relies
on state in a way that IF doesn't.

[Nit and now off-topic at that:] SASL and FP have "while". Miranda
and Haskell went for "until" but it could just have easily have been
while. There are probably others. While is quite logical in purely
function languages.

Yeahbut -- they require that the condition be some kind of functional
abstraction, yes? [Easy in FP, which IIRC is all functional abstractions.]

Otherwise, (fx:red-face).

 

[Kevin Handy]

1)can any one give an example for a C program that can be written
using goto only ? i.e a program in which we cannot avoid the keyword
goto

It should be possible to write any program without using
goto, but sometimes it requires more complex code.
Sometimes goto just makes it easier to understand what
is going on.

Sometimes you get stuck with existing code containing
a goto, and instead of spending all day cleaning it up
with a reasonable substitute, it's easer to leave it
alone.

i.e. without actually running the following program,
will it compile? (Hint: yes). What does it do
for different values for 'limit' (try 7)? Change the
second loop to a '<' instead of the '<=' so the loops
are asymmetric. What will it do then? Have fun with
different increments in the loops. Use different loop
variables in the two loops with different limits
(hint: very bad).

#include <stdio.h>
int main()
{
int limit = 6;
int loop;

for (loop = 1; loop <= limit; loop++)
{
printf("A%d\n", loop);
goto two;
one:;
}

for (loop = 1; loop <= limit; loop++)
{
printf("B%d\n", loop);
goto one;
two:;
}
}

Some code just needs to be shot.
Note that I found this algorithm a long time ago
embedded in a Basic+ program, where it was actually
a cut/paste bug in a much larger segment of code.

2)what exactly is the purpose of tmpfile() ? will it open a temporary
file ?

3)why there is no article on dangling pointer in the FAQ ?

pointer got lost?

 

[CBFalconer]

WHILE doesn't work at all for pure-functional languages: it relies
on state in a way that IF doesn't.

What do you mean? To me, while operates on a logical expression.
So does if. Languages vary on how to define the controlled
expression(s).

 

[Philip Potter]

What do you mean? To me, while operates on a logical expression.
So does if. Languages vary on how to define the controlled
expression(s).

The difference is that (pure) functional languages have no state - no
variables. All functions depend only on their arguments. This is fine
for IF, which works more like the ?: operator than like C if(){}, but
WHILE needs some state to change between iterations of the loop in order
for the condition to change.

For example (in ML-like syntax):
fun fact(n) = IF n>0 THEN n*fact(n-1) ELSE 1;

To write the same thing using WHILE would require a variable.

(In any case it's a minor point; functional languages can achieve
everything WHILE can using recursion.)

 

[Chris Dollin]

What do you mean?

Exactly what I said.

To me, while operates on a logical expression.
So does if. Languages vary on how to define the controlled
expression(s).

In `while E do C`, the /same expression/ `E` is evaluated potentially
multiple times, with different results. This works only because there's
an underlying mutable state.

In `if E then Y else N endif`, `E` is evaluated but once [in this context].
So it need not be state-sensitive.

[If you use a p-f language with a while, the control expression won't have
type boolean, but something more complicated, typically a function type
whatever -> boolean -- /not/ just boolean: ie, it won't be "a logical
expression".]

 

[CBFalconer]

The difference is that (pure) functional languages have no state -
no variables. All functions depend only on their arguments. This
is fine for IF, which works more like the ?: operator than like C
if(){}, but WHILE needs some state to change between iterations of
the loop in order for the condition to change.

However, in C, while and if are NOT functions, they are reserved
words (or the C equivalent). The following parentheses are not
delimiting arguments, they are defining the logical statement
involved.

 

[sophia.agnes]

It should be possible to write any program without using
goto, but sometimes it requires more complex code.
Sometimes goto just makes it easier to understand what
is going on.

Sometimes you get stuck with existing code containing
a goto, and instead of spending all day cleaning it up
with a reasonable substitute, it's easer to leave it
alone.

i.e. without actually running the following program,
will it compile? (Hint: yes). What does it do
for different values for 'limit' (try 7)? Change the
second loop to a '<' instead of the '<=' so the loops
are asymmetric. What will it do then? Have fun with
different increments in the loops. Use different loop
variables in the two loops with different limits
(hint: very bad).

#include <stdio.h>
int main()
{
int limit = 6;
int loop;

for (loop = 1; loop <= limit; loop++)
{
printf("A%d\n", loop);
goto two;
one:;
}

for (loop = 1; loop <= limit; loop++)
{
printf("B%d\n", loop);
goto one;
two:;
}

}

Can i take this program as an example where goto can't be avoided...?????