Can't compile this with Cygwin!

Discussion in 'C Programming' started by JS, Mar 18, 2005.

  1. JS

    JS Guest

    I use winXP and have installed Cygwin. I use Dev-C++ and the Cygwin
    compiler, but for some reason I can't compile this code:

    #include <setjmp.h>
    #include <stdio.h>
    #include <stdlib.h>


    typedef int othread_t;

    typedef struct _othread_attr_t {
    } othread_attr_t;

    #define STACK_SIZE 1024


    struct pcb {
    void *(*start_routine) (void *);
    void *arg;
    jmp_buf state;
    int stak[STACK_SIZE];
    };

    static struct pcb first_thread;

    struct pcb *current = &first_thread;
    struct pcb *ready = NULL;

    int othread_create (othread_t *threadp,
    const othread_attr_t *attr,
    void *(*start_routine) (void *),
    void *arg)
    {
    int *state_pointer;
    int lokalt_reserveret;

    struct pcb *pcb_pointer;

    pcb_pointer = (struct pcb *) malloc(sizeof(struct pcb));
    if(pcb_pointer == NULL) {

    exit(-1);
    }

    pcb_pointer->start_routine = start_routine;
    pcb_pointer->arg = arg;

    if(setjmp(pcb_pointer->state)) {



    current->start_routine(current->arg);

    printf("En trĂ¥d har returneret - alt stoppes\n");
    exit(0);
    }

    state_pointer = (int *) &pcb_pointer->state;
    lokalt_reserveret = state_pointer[JB_BP] - state_pointer[JB_SP];
    state_pointer[JB_BP] = (int) (pcb_pointer->stak + STACK_SIZE);
    state_pointer[JB_SP] = (int) state_pointer[JB_BP] - lokalt_reserveret;


    ready = pcb_pointer;


    *threadp = (int) pcb_pointer;

    return 0;
    }


    int othread_yield (void)
    {
    if(ready != NULL) {

    struct pcb *old = current;
    current = ready;
    ready = old;
    if(setjmp(old->state) == 0) {
    longjmp(current->state, 1);
    }
    }

    return 0;
    }



    void *other(void *arg)
    {
    printf("Hello world from other\n");

    othread_yield();

    printf("other still going strong\n");

    othread_yield();

    printf("Godbye world from other\n");

    return NULL;
    }


    int main(void)
    {
    othread_t t1;

    othread_create(&t1, NULL, other, NULL);

    printf("Hello world from main\n");

    othread_yield();

    printf("main still going strong\n");

    othread_yield();

    printf("Godbye world from main\n");

    othread_yield();


    printf("Is never reached\n");

    return 0;
    }



    The error I get is:

    56 H:\thread\thread.c `JB_BP' undeclared (first use in this function)
    (Each undeclared identifier is reported only once
    for each function it appears in.)

    56 H:\thread\thread.c `JB_SP' undeclared (first use in this function)
    make H:\thread\make *** [thread.o] Error 1

    when I compile the same code on Linux it works fine! But I am sure that I
    use Cygwin so that should be as good as using Linux.

    Hope someone can help
     
    JS, Mar 18, 2005
    #1
    1. Advertising

  2. JS

    -berlin.de Guest

    JS <> wrote:

    <lots of cde snipped>

    > The error I get is:


    > 56 H:\thread\thread.c `JB_BP' undeclared (first use in this function)
    > (Each undeclared identifier is reported only once
    > for each function it appears in.)


    > 56 H:\thread\thread.c `JB_SP' undeclared (first use in this function)
    > make H:\thread\make *** [thread.o] Error 1


    > when I compile the same code on Linux it works fine! But I am sure that I
    > use Cygwin so that should be as good as using Linux.


    No, it doesn't compile, not even on Linux. I just took your code
    and tried to compile it (under Linux) and, voila,

    thr.c:55: error: `JB_BP' undeclared (first use in this function)
    thr.c:55: error: (Each undeclared identifier is reported only once
    thr.c:55: error: for each function it appears in.)
    thr.c:55: error: `JB_SP' undeclared (first use in this function)
    thr.c:27: warning: unused parameter `attr'
    thr.c: In function `other':
    thr.c:86: warning: unused parameter `arg'

    basically the same error message. So you must be defining 'JS_BP'
    and 'JB_BP' in places you don't show. It's nowhere defined in the
    code you posted (and I have no idea what they should be), so the
    compiler is completely right in complaining. (BTW, there's no good
    reason to cast the return value of malloc(), identifiers starting
    with an underscore are reserved for the implementation, your type-
    def of 'othread_attr_t' looks mysterious (a structure with no
    members), your casts look very strange to say the least (int's and
    pointers may have different sizes), and lots more of things that
    make no sense at all). What that's all supposed to do?

    Regards, Jens
    --
    \ Jens Thoms Toerring ___ -berlin.de
    \__________________________ http://www.toerring.de
     
    -berlin.de, Mar 19, 2005
    #2
    1. Advertising

  3. In article <>,
    <-berlin.de> wrote:
    :basically the same error message. So you must be defining 'JS_BP'
    :and 'JB_BP' in places you don't show. It's nowhere defined in the
    :code you posted (and I have no idea what they should be),

    They appear to be in <setjmp.h> at least on some systems.

    My copy of the standard is packed at the moment, so I can't check
    to see whether the standard has anything to say about what the
    interior structure of a jump buffer is.
    --
    Feep if you love VT-52's.
     
    Walter Roberson, Mar 19, 2005
    #3
  4. JS

    JS Guest

    On Sat, 19 Mar 2005 00:18:40 +0000, Jens.Toerring wrote:

    > JS <> wrote:
    >
    > <lots of cde snipped>
    >
    >> The error I get is:

    >
    >> 56 H:\thread\thread.c `JB_BP' undeclared (first use in this function)
    >> (Each undeclared identifier is reported only once
    >> for each function it appears in.)

    >
    >> 56 H:\thread\thread.c `JB_SP' undeclared (first use in this function)
    >> make H:\thread\make *** [thread.o] Error 1

    >
    >> when I compile the same code on Linux it works fine! But I am sure that I
    >> use Cygwin so that should be as good as using Linux.

    >
    > No, it doesn't compile, not even on Linux. I just took your code
    > and tried to compile it (under Linux) and, voila,
    >
    > thr.c:55: error: `JB_BP' undeclared (first use in this function)
    > thr.c:55: error: (Each undeclared identifier is reported only once
    > thr.c:55: error: for each function it appears in.)
    > thr.c:55: error: `JB_SP' undeclared (first use in this function)
    > thr.c:27: warning: unused parameter `attr'
    > thr.c: In function `other':
    > thr.c:86: warning: unused parameter `arg'
    >
    > basically the same error message. So you must be defining 'JS_BP'
    > and 'JB_BP' in places you don't show. It's nowhere defined in the
    > code you posted (and I have no idea what they should be), so the
    > compiler is completely right in complaining. (BTW, there's no good
    > reason to cast the return value of malloc(), identifiers starting
    > with an underscore are reserved for the implementation, your type-
    > def of 'othread_attr_t' looks mysterious (a structure with no
    > members), your casts look very strange to say the least (int's and
    > pointers may have different sizes), and lots more of things that
    > make no sense at all). What that's all supposed to do?
    >
    > Regards, Jens



    Well it compiles fine on my Ubuntu Linux....
     
    JS, Mar 19, 2005
    #4
  5. JS

    -berlin.de Guest

    JS <> wrote:
    > On Sat, 19 Mar 2005 00:18:40 +0000, Jens.Toerring wrote:


    >> JS <> wrote:
    >>
    >> <lots of cde snipped>
    >>
    >>> The error I get is:

    >>
    >>> 56 H:\thread\thread.c `JB_BP' undeclared (first use in this function)
    >>> (Each undeclared identifier is reported only once
    >>> for each function it appears in.)

    >>
    >>> 56 H:\thread\thread.c `JB_SP' undeclared (first use in this function)
    >>> make H:\thread\make *** [thread.o] Error 1

    >>
    >>> when I compile the same code on Linux it works fine! But I am sure that I
    >>> use Cygwin so that should be as good as using Linux.

    >>
    >> No, it doesn't compile, not even on Linux. I just took your code
    >> and tried to compile it (under Linux) and, voila,
    >>
    >> thr.c:55: error: `JB_BP' undeclared (first use in this function)
    >> thr.c:55: error: (Each undeclared identifier is reported only once
    >> thr.c:55: error: for each function it appears in.)
    >> thr.c:55: error: `JB_SP' undeclared (first use in this function)
    >> thr.c:27: warning: unused parameter `attr'
    >> thr.c: In function `other':
    >> thr.c:86: warning: unused parameter `arg'
    >>
    >> basically the same error message. So you must be defining 'JS_BP'
    >> and 'JB_BP' in places you don't show. It's nowhere defined in the


    > Well it compiles fine on my Ubuntu Linux....


    But not in standard compliant mode - unless you ask for that you get
    lots of non-portable extensions included - and you can't expect them
    to exist on a completely different type of system. If you search the
    C89 or C99 standard you won't find the string "JB" anywhere. If you
    want to check compile with at least the options '-ansi -pedantic' -
    normally gcc is far from standard compliant (and even in the POSIX
    standard I didn't find anything about 'JB_[A-Z]P' when looking up
    setjmp() and things related to it). And while 'JB_SP' and 'JB_BP'
    seem to be defined somewhere in the innards for setjmp() on IA32
    Linux I only found 'JB_SP' in a header file for IRIX or OSF1, but not
    'JB_BP'. There are no guarantees at all, at least from the C standard,
    when you start to mess around with the innards of a 'jmp_buf' variable
    - what's stored there and where and in what format is as system-depen-
    dent as you can get.
    Regards, Jens
    --
    \ Jens Thoms Toerring ___ -berlin.de
    \__________________________ http://www.toerring.de
     
    -berlin.de, Mar 19, 2005
    #5
  6. JS

    JS Guest

    > > Well it compiles fine on my Ubuntu Linux....
    >
    > But not in standard compliant mode - unless you ask for that you get
    > lots of non-portable extensions included - and you can't expect them
    > to exist on a completely different type of system. If you search the
    > C89 or C99 standard you won't find the string "JB" anywhere. If you
    > want to check compile with at least the options '-ansi -pedantic' -
    > normally gcc is far from standard compliant (and even in the POSIX
    > standard I didn't find anything about 'JB_[A-Z]P' when looking up
    > setjmp() and things related to it). And while 'JB_SP' and 'JB_BP'
    > seem to be defined somewhere in the innards for setjmp() on IA32
    > Linux I only found 'JB_SP' in a header file for IRIX or OSF1, but not
    > 'JB_BP'. There are no guarantees at all, at least from the C standard,
    > when you start to mess around with the innards of a 'jmp_buf' variable
    > - what's stored there and where and in what format is as system-depen-
    > dent as you can get.



    But how can it be that you get the error messages and I don't get them in
    Ubuntu Linux, is it because I don't compile with the right commands? I am a
    bit concerned that my compiler don't detect the errors, when your compiler
    does...
     
    JS, Mar 19, 2005
    #6
  7. JS

    Flash Gordon Guest

    JS wrote:
    >>>Well it compiles fine on my Ubuntu Linux....

    >>
    >>But not in standard compliant mode - unless you ask for that you get
    >>lots of non-portable extensions included - and you can't expect them
    >>to exist on a completely different type of system. If you search the
    >>C89 or C99 standard you won't find the string "JB" anywhere. If you
    >>want to check compile with at least the options '-ansi -pedantic' -

    ^^^^^^^^^^^^^^^
    >>normally gcc is far from standard compliant (and even in the POSIX


    <snip>

    > But how can it be that you get the error messages and I don't get them in
    > Ubuntu Linux, is it because I don't compile with the right commands? I am a
    > bit concerned that my compiler don't detect the errors, when your compiler
    > does...


    As stated above in the text you quoted, use the '-ansi -pedantic'
    options on gcc.
    --
    Flash Gordon
    Living in interesting times.
    Although my email address says spam, it is real and I read it.
     
    Flash Gordon, Mar 19, 2005
    #7
  8. JS

    CBFalconer Guest

    Flash Gordon wrote:
    > JS wrote:
    >
    > <snip>
    >
    >> But how can it be that you get the error messages and I don't get
    >> them in Ubuntu Linux, is it because I don't compile with the right
    >> commands? I am a bit concerned that my compiler don't detect the
    >> errors, when your compiler does...

    >
    > As stated above in the text you quoted, use the '-ansi -pedantic'
    > options on gcc.


    Also include -W -Wall.

    --
    "If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers." - Keith Thompson
     
    CBFalconer, Mar 19, 2005
    #8
  9. CBFalconer <> writes:
    > Flash Gordon wrote:
    >> JS wrote:
    >>
    >> <snip>
    >>
    >>> But how can it be that you get the error messages and I don't get
    >>> them in Ubuntu Linux, is it because I don't compile with the right
    >>> commands? I am a bit concerned that my compiler don't detect the
    >>> errors, when your compiler does...

    >>
    >> As stated above in the text you quoted, use the '-ansi -pedantic'
    >> options on gcc.

    >
    > Also include -W -Wall.


    There's been some debate about whether "-W -Wall" is as useful as it
    should be (some of the warnings may be questionable), but at worst
    you'll get too many warnings, which is probably better than too few.
    You just have to know which ones to ignore.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Mar 19, 2005
    #9
  10. JS

    Richard Bos Guest

    -cnrc.gc.ca (Walter Roberson) wrote:

    > In article <>,
    > <-berlin.de> wrote:
    > :basically the same error message. So you must be defining 'JS_BP'
    > :and 'JB_BP' in places you don't show. It's nowhere defined in the
    > :code you posted (and I have no idea what they should be),
    >
    > They appear to be in <setjmp.h> at least on some systems.


    Then some systems are broken; those identifiers are the programmer's,
    not the implementation's.

    Richard
     
    Richard Bos, Mar 21, 2005
    #10
  11. JS

    JS Guest

    On Sat, 19 Mar 2005 00:18:40 +0000, Jens.Toerring wrote:

    > JS <> wrote:
    >
    > <lots of cde snipped>
    >
    >> The error I get is:

    >
    >> 56 H:\thread\thread.c `JB_BP' undeclared (first use in this function)
    >> (Each undeclared identifier is reported only once
    >> for each function it appears in.)

    >
    >> 56 H:\thread\thread.c `JB_SP' undeclared (first use in this function)
    >> make H:\thread\make *** [thread.o] Error 1

    >
    >> when I compile the same code on Linux it works fine! But I am sure that I
    >> use Cygwin so that should be as good as using Linux.

    >
    > No, it doesn't compile, not even on Linux. I just took your code
    > and tried to compile it (under Linux) and, voila,
    >
    > thr.c:55: error: `JB_BP' undeclared (first use in this function)
    > thr.c:55: error: (Each undeclared identifier is reported only once
    > thr.c:55: error: for each function it appears in.)
    > thr.c:55: error: `JB_SP' undeclared (first use in this function)
    > thr.c:27: warning: unused parameter `attr'
    > thr.c: In function `other':
    > thr.c:86: warning: unused parameter `arg'
    >
    > basically the same error message. So you must be defining 'JS_BP'
    > and 'JB_BP' in places you don't show. It's nowhere defined in the
    > code you posted (and I have no idea what they should be), so the
    > compiler is completely right in complaining. (BTW, there's no good
    > reason to cast the return value of malloc(), identifiers starting
    > with an underscore are reserved for the implementation, your type-
    > def of 'othread_attr_t' looks mysterious (a structure with no
    > members), your casts look very strange to say the least (int's and
    > pointers may have different sizes), and lots more of things that
    > make no sense at all). What that's all supposed to do?
    >
    > Regards, Jens



    I just found JS_BP and JB_BP in setjmp.h in /usr/include/bits

    So I guess that is why it compiles and runs as it should on my Ubuntu
    Linux. But for some reason theses definitions are not in Cygwin.
     
    JS, Mar 25, 2005
    #11
  12. On Fri, 25 Mar 2005 15:57:29 +0100, JS
    <> wrote:

    > On Sat, 19 Mar 2005 00:18:40 +0000, Jens.Toerring wrote:
    >
    > I just found JS_BP and JB_BP in setjmp.h in /usr/include/bits


    Well, it's a violation of the C standard if that file gets included when
    you write #include <setjmp.h> (or any other standard header), since
    those names are not defined by the standard and are in the "user"
    namespace (they don't start with _ or one of the other prefixes). A
    strictly conforming program is free to declare JS_BP or JB_BP, and that
    would break on your system.

    > So I guess that is why it compiles and runs as it should on my Ubuntu
    > Linux. But for some reason theses definitions are not in Cygwin.


    Because the Cygwin library doesn't need them? Because the Cygwin
    library uses correct naming conventions for its implementation-specific
    names? They aren't in the C standard, so if you find them on some
    system without including a non-standard header they are incorrect (if
    you include a non-standard header (like "sys/types.h") then anything you
    find is implementation specific).

    As others have said, there is no portable way of accessing anything in a
    jmp_buf. The type is intentionally opaque to the user, the only thing
    known about it is that it is implemented as an array (that's how you can
    write setjmp(fred) instead of setjmp(&fred)), but that could be an aray
    of char, array of int, an array with only one member where that is a
    struct, or whatever.

    Chris C
     
    Chris Croughton, Mar 25, 2005
    #12
  13. JS <> writes:
    > On Sat, 19 Mar 2005 00:18:40 +0000, Jens.Toerring wrote:
    >> JS <> wrote:
    >> <lots of cde snipped>
    >>
    >>> The error I get is:

    >>
    >>> 56 H:\thread\thread.c `JB_BP' undeclared (first use in this function)
    >>> (Each undeclared identifier is reported only once
    >>> for each function it appears in.)

    [snip]
    > I just found JS_BP and JB_BP in setjmp.h in /usr/include/bits
    >
    > So I guess that is why it compiles and runs as it should on my Ubuntu
    > Linux. But for some reason theses definitions are not in Cygwin.


    There's no reason they should be.

    In fact, if the compiler is invoked in conforming mode, those
    identifiers should not be visible to any program that uses only
    standard headers.

    Based on an experiment I just tried on one of my own Linux systems,
    your code compiles without error using gcc with default options. "gcc
    -ansi" complains (correctly) that JS_BP and JB_BP are undeclared. And
    on my Cygwin system, those identifiers are not available at all.

    Apparently in the non-conforming mode that is gcc's default, these
    identifiers are provided to allow access to the internals of a
    jmp_buf. The price paid for this is that an otherwise conforming
    program that attempts to use these identifiers for itself will fail to
    compile -- and a program that uses the system-defined JS_BP and JB_BP
    will be non-portable. In conforming ("-ansi") mode, the identifiers
    are hidden, allowing the program to use them as it chooses.

    A portable program cannot do anything that depends on the internal
    details of a jmp_buf, beyond the standard's guarantee that it's an
    array type. As you've seen, it appears that a Cygwin jmp_buf has
    different internals than a Linux jmp_buf (or at least the Cygwin
    headers don't expose them the same way).

    You can write Linux-specific code that depends on the internals of a
    Linux-specific jmp_buf. Or you can write Cygwin-specific code that
    depends on the internals of a Cygwin-specific jmp_buf. (Likewise for
    other systems.) Or you can write portable code that doesn't assume
    anything beyond the fact that a jmp_buf is an array.

    Porting your Linux-specific code to Cygwin will require some
    non-trivial effort, if it's possible at all. We can't help you with
    that here; your best resource is probably the Cygwin mailing lists.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Mar 25, 2005
    #13
    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. Replies:
    0
    Views:
    452
  2. Replies:
    0
    Views:
    434
  3. WELCOME to

    , Sep 3, 2003, in forum: Python
    Replies:
    1
    Views:
    514
    Robin Becker
    Sep 5, 2003
  4. Replies:
    0
    Views:
    414
  5. Nagaraj
    Replies:
    1
    Views:
    870
    Lionel B
    Mar 1, 2007
Loading...

Share This Page