Labels and pointers

Discussion in 'C Programming' started by Jean-Guillaume Pyraksos, Nov 23, 2007.

  1. Is a label something like a pointer i can store in a variable ?

    #include <stdio.h>

    void foo(void *p)
    {
    printf("foo\n");
    goto *p;
    }

    int main()
    {
    foo(&&L1); // ???????? Explain...
    printf("bar\n"); // should not be executed ?
    L1:
    printf("quit\n");
    return 0;
    }

    Can somebody elaborate on this code i found on the net ?...
    gcc compiles it but the result is strange (MacIntel Leopard, gcc 4.0.0)

    $ gcc prog.c -o prog
    $ ./prog
    foo
    r is not present to run this program
    bar
    quit
    $

    Thanks,

    -JG
    Jean-Guillaume Pyraksos, Nov 23, 2007
    #1
    1. Advertising

  2. Jean-Guillaume Pyraksos

    Mark Bluemel Guest

    Jean-Guillaume Pyraksos wrote:
    > Is a label something like a pointer i can store in a variable ?
    >
    > #include <stdio.h>
    >
    > void foo(void *p)
    > {
    > printf("foo\n");
    > goto *p;
    > }
    >
    > int main()
    > {
    > foo(&&L1); // ???????? Explain...
    > printf("bar\n"); // should not be executed ?
    > L1:
    > printf("quit\n");
    > return 0;
    > }
    >
    > Can somebody elaborate on this code i found on the net ?...


    It appears to use GCC specific extensions - try building it with the
    options "-ansi -Wall -pedantic"

    > gcc compiles it but the result is strange (MacIntel Leopard, gcc 4.0.0)
    >
    > $ gcc prog.c -o prog
    > $ ./prog
    > foo
    > r is not present to run this program
    > bar
    > quit


    The reference manual page I found
    (http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html) says "You may
    not use this mechanism to jump to code in a different function. If you
    do that, totally unpredictable things will happen. The best way to avoid
    this is to store the label address only in automatic variables and never
    pass it as an argument."

    So the code you quote is a) non-standard and b) broken even when && is
    supported.
    Mark Bluemel, Nov 23, 2007
    #2
    1. Advertising

  3. Jean-Guillaume Pyraksos

    Eric Sosman Guest

    Jean-Guillaume Pyraksos wrote:
    > Is a label something like a pointer i can store in a variable ?


    No. The only thing you can do with a label is `goto'
    it (or for a case label, `switch' to it).

    > Can somebody elaborate on this code [snipped] i found on the net ?...
    > gcc compiles it but the result is strange (MacIntel Leopard, gcc 4.0.0)


    Unless you tell it to do otherwise, the language gcc
    compiles is "C with extras" rather than "C". One of those
    extras is "labels as values," which allows the program to
    extract a value from a label, store the value in a variable,
    and `goto' the variable's value.

    There are at least two reasons not to use this feature:

    1) It's not C, so if you write a program that employs it
    you will have difficulty getting the program to work
    with compilers other than gcc.

    2) If "`goto' [is] considered harmful," `goto with gadgets'
    is even more so. When debugging a goto-laden program,
    the question that always arises is "How in the world
    did I get *here*?" With ordinary "static" gotos a text
    editor can search for all mentions of the label, but if
    you arrived at label `fred:' via `goto *george;' the task
    is noticeably harder.

    For more information on "labels as values," consult the
    gcc documentation. That's the only thing that can explain
    the behavior of your program; as I mentioned, it's not C.

    --
    Eric Sosman
    lid
    Eric Sosman, Nov 23, 2007
    #3
  4. In article <>,
    Eric Sosman <> wrote:
    ....
    > For more information on "labels as values," consult the
    >gcc documentation. That's the only thing that can explain
    >the behavior of your program; as I mentioned, it's not C.


    In much the same way as "cake with frosting" isn't "cake".

    I.e., only in the crazed imaginations of CLC regulars.
    Kenny McCormack, Nov 23, 2007
    #4
  5. Jean-Guillaume Pyraksos wrote:
    > Is a label something like a pointer i can store in a variable ?


    Not in the standard language. The code you posted uses a gcc extension
    (perhaps available on some other implementations) and is properly
    addressed in a gnu-specific newsgroup specific to gcc (or those other
    implementations). It cannot be used in programs intended to be portable.
    >
    > #include <stdio.h>
    >
    > void foo(void *p)
    > {
    > printf("foo\n");
    > goto *p;
    > }
    >
    > int main()
    > {
    > foo(&&L1); // ???????? Explain...

    This is explained in the gcc documentation.
    Always check the documentation for your
    implementation (along with the C FAQ) before posting.
    > printf("bar\n"); // should not be executed ?
    > L1:
    > printf("quit\n");
    > return 0;
    > }


    gcc invoked as a compiler for standard C should produce diagnostics like
    a.c: In function 'foo':
    a.c:6: warning: ISO C forbids 'goto *expr;'
    a.c: In function 'main':
    a.c:11: warning: taking the address of a label is non-standard
    where line 6 is the 'goto *p;'m and line 11 is 'foo(&&L1);'

    But even when gcc compiles its default non-standard language, called
    GNU-C, the above code is malformed. The gcc documentation contains the
    language "You may not use this mechanism to jump to code in a different
    function. If you do that, totally unpredictable things will happen. The
    best way to avoid this is to store the label address only in automatic
    variables and never pass it as an argument."

    So the code is
    a) complete gibberish as far as the standard C language is concerned
    b) incorrect even in the non-standard GNU-C language since it attempts
    "to jump to code in a different function", and violates the suggestion
    that one "never pass it as an argument."

    > Can somebody elaborate on this code i found on the net ?...
    > gcc compiles it but the result is strange (MacIntel Leopard, gcc 4.0.0)
    >
    > $ gcc prog.c -o prog
    > $ ./prog
    > foo
    > r is not present to run this program
    > bar
    > quit
    > $


    The output you see is one of the "totally unpredictable things" the gcc
    documentation warns about.
    Martin Ambuhl, Nov 23, 2007
    #5
  6. Jean-Guillaume Pyraksos

    Chris Dollin Guest

    Kenny McCormack wrote:

    > In article <>,
    > Eric Sosman <> wrote:
    > ...
    >> For more information on "labels as values," consult the
    >>gcc documentation. That's the only thing that can explain
    >>the behavior of your program; as I mentioned, it's not C.

    >
    > In much the same way as "cake with frosting" isn't "cake".


    You misspelled "engine oil".

    > I.e., only in the crazed imaginations of CLC regulars.


    And "prized".

    --
    And Teh Hedgehog
    "Never ask that question!" Ambassador Kosh, /Babylon 5/
    Chris Dollin, Nov 23, 2007
    #6
  7. In article <>,
    Jean-Guillaume Pyraksos <> wrote:

    >Is a label something like a pointer i can store in a variable ?


    As others have pointed out, only when using an extension like the
    one that gcc provides.

    >void foo(void *p)
    >{
    > printf("foo\n");
    > goto *p;
    >}
    >
    >int main()
    >{
    > foo(&&L1); // ???????? Explain...
    > printf("bar\n"); // should not be executed ?
    > L1:
    > printf("quit\n");
    > return 0;
    >}


    >Can somebody elaborate on this code i found on the net ?...


    Again, as others have pointed out, this code is using the gcc
    extension wrongly. You should only use it for jumps where a
    normal jump to the location would be legal.

    >gcc compiles it but the result is strange (MacIntel Leopard, gcc 4.0.0)
    >
    >$ gcc prog.c -o prog
    >$ ./prog
    >foo
    >r is not present to run this program
    >bar
    >quit


    My guess would be that the goto is "working", but because the function
    foo is still active the format string "quit" is not in the right place
    relative to the stack pointer, and instead it gets the end of some
    other string (you can find what it probably is by googling for "is not
    present to run this program"). It then executes main's return, but
    because foo's stack frame is still there it returns to main, and
    continues executing normally.

    -- Richard


    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
    Richard Tobin, Nov 23, 2007
    #7
  8. In article <>,
    Eric Sosman <> wrote:

    > There are at least two reasons not to use this feature:


    And there are also reasons to use it, though most people probably
    won't encounter them. It seems quite in accord with the spirit of
    C: no worse, for example, than setjmp()/longjmp().

    -- Richard
    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
    Richard Tobin, Nov 23, 2007
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Roger Leigh
    Replies:
    8
    Views:
    434
    Karl Heinz Buchegger
    Nov 17, 2003
  2. Replies:
    1
    Views:
    644
    -berlin.de
    Mar 28, 2005
  3. Marc Thrun
    Replies:
    15
    Views:
    857
    Tim Rentsch
    Oct 4, 2005
  4. Replies:
    4
    Views:
    337
    Keith Thompson
    Dec 14, 2006
  5. cerr

    pointers, pointers, pointers...

    cerr, Apr 7, 2011, in forum: C Programming
    Replies:
    12
    Views:
    669
Loading...

Share This Page