Wrong linkage of system functions

Discussion in 'C Programming' started by Cristóvão Sousa, Mar 5, 2008.

  1. Hi,
    I'm having some trouble with a C project in a Linux system.
    I already know which is the problem but I don't know how to fix it.

    I have a program that links to a third party static library.
    The problem is that the library declares a internal global variable
    named 'accept' not visible by the user.
    In my program I use the system Internet Sockets which API have a
    function named 'accept'.
    When I compile it does not complies but when I run the program it
    segfaults because a call to Internet Sockets 'accept' function tries
    to execute a function which address is the address of the 'accept'
    global variable from the third party library.

    I made a little source code that reproduce the problem with the
    'printf' function. In this case the compiler gives me a warning, but
    the beavior is equal.

    Is this my problem? Is it a bug? I don't think a programer have to
    know all possible system functions names...


    I have three files:
    mylib.c and mylib.h represents the third party library;
    main.c is my program.
    I also made a simple Makefile.

    Here are the files:

    ---------------------------------------
    $ cat mylib.h
    int myfunc();

    ---------------------------------------
    $ cat mylib.c
    #include "mylib.h"

    int printf[2];

    int myfunc(){ // Just for example
    printf[0] = 0;
    return printf[1];
    }

    ---------------------------------------
    $ cat main.c
    #include <stdio.h>
    #include "mylib.h"

    int main(){
    printf("Helo World!");
    return 0;
    }

    ---------------------------------------
    $ cat Makefile
    exec: main mylib
    gcc main.o mylib.o -o exec

    main: main.c
    gcc main.c -c -o main.o

    mylib: mylib.c
    gcc mylib.c -c -o mylib.o

    ---------------------------------------------------


    And here are the results:


    $ make
    gcc main.c -c -o main.o
    gcc mylib.c -c -o mylib.o
    mylib.c:3: warning: built-in function 'printf' declared as non-
    function
    gcc main.o mylib.o -o exec

    $ ./exec
    Segmentation fault (core dumped)

    $ gdb ./exec core
    Core was generated by `./exec'.
    Program terminated with signal 11, Segmentation fault.
    #0 0x0000000000600884 in printf ()



    Thanks in advance,

    Cristóvão Sousa
    ISR - FCT - University of Coimbra
    Cristóvão Sousa, Mar 5, 2008
    #1
    1. Advertising

  2. Cristóvão Sousa <> writes:

    > Hi,
    > I'm having some trouble with a C project in a Linux system.
    > I already know which is the problem but I don't know how to fix it.
    >
    > I have a program that links to a third party static library.
    > The problem is that the library declares a internal global variable
    > named 'accept' not visible by the user.


    This is non-standard terminology and might be confusing. In you
    example below, the name class is with a file-scope object with
    external linkage. The "not visible by the user" is still confusing
    me, but if the problem is an object called "accept" with external
    linkage in the library, then I think you will need to use system
    specific trickery to solve the problem.

    A post to comp.unix.programmer or a gcc group might bear fruit. It is
    possible that some linker magic can help here, but that is a matter
    for another group.

    > In my program I use the system Internet Sockets which API have a
    > function named 'accept'.
    > When I compile it does not complies but when I run the program it
    > segfaults because a call to Internet Sockets 'accept' function tries
    > to execute a function which address is the address of the 'accept'
    > global variable from the third party library.
    >
    > I made a little source code that reproduce the problem with the
    > 'printf' function. In this case the compiler gives me a warning, but
    > the beavior is equal.


    This example is a little different since, printf is a reserved
    identifier (when used like this) so your example in not "proper" C.
    The compiler is allowed to do pretty much what it likes with it.

    The identifier in question ("accept") is not reserved in this way, so
    the library is allowed to define it. Of course, it is very bad
    practice to do so. A library should define as few externally visible
    identifiers as possible, and they should, usually, have some form of
    prefixed name to reduce the chance of clashes like this.

    If you have access to the source, fix the library. If the identifier
    is not needed outside the library, you may be able to declare it
    static so that it will not have external linkage,

    <snip example code that defines an external array called "printf">

    --
    Ben.
    Ben Bacarisse, Mar 5, 2008
    #2
    1. Advertising

  3. On Mar 5, 6:32 pm, Ben Bacarisse <> wrote:
    > Cristóvão Sousa <> writes:
    > > Hi,
    > > I'm having some trouble with a C project in a Linux system.
    > > I already know which is the problem but I don't know how to fix it.

    >
    > > I have a program that links to a third party static library.
    > > The problem is that the library declares a internal global variable
    > > named 'accept' not visible by the user.

    >
    > This is non-standard terminology and might be confusing. In you
    > example below, the name class is with a file-scope object with
    > external linkage. The "not visible by the user" is still confusing
    > me, but if the problem is an object called "accept" with external
    > linkage in the library, then I think you will need to use system
    > specific trickery to solve the problem.


    Well, I really don't know very well the standard terminology, but, yes
    the 'accept' variable is global and non static. I call it a library
    because the object file is inserted in a archive .a file.
    I said "not visible by the user" in the way a person using the library
    doesn't know that the variable exists unless she search the source
    code, like I did when debugging.

    > A post to comp.unix.programmer or a gcc group might bear fruit. It is
    > possible that some linker magic can help here, but that is a matter
    > for another group.


    Ok I'll try there too.

    > > I made a little source code that reproduce the problem with the
    > > 'printf' function. In this case the compiler gives me a warning, but
    > > the beavior is equal.

    >
    > This example is a little different since, printf is a reserved
    > identifier (when used like this) so your example in not "proper" C.
    > The compiler is allowed to do pretty much what it likes with it.
    >
    > The identifier in question ("accept") is not reserved in this way, so
    > the library is allowed to define it. Of course, it is very bad
    > practice to do so. A library should define as few externally visible
    > identifiers as possible, and they should, usually, have some form of
    > prefixed name to reduce the chance of clashes like this.


    Ah, ok, that explains why the compiler does warn about 'printf' but
    not about 'accept', anyway the result is the same.

    > If you have access to the source, fix the library. If the identifier
    > is not needed outside the library, you may be able to declare it
    > static so that it will not have external linkage,


    Yes I have, and the static resolved it! But because I am not the
    developer of the library I'll prefer to ask the real developer to
    change it.

    Anyway as 'accept' is not a reserved identifier and even defining it
    externally visible is not a good practice I'll try to figure out which
    is the cause of the problem.


    Thanks,
    Cristóvão
    Cristóvão Sousa, Mar 5, 2008
    #3
    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. Mary
    Replies:
    1
    Views:
    3,986
    Thomas Fritsch
    Oct 11, 2004
  2. qazmlp
    Replies:
    0
    Views:
    348
    qazmlp
    Jul 17, 2003
  3. Bill Pursell

    simulating private member functions--static linkage

    Bill Pursell, Apr 27, 2006, in forum: C Programming
    Replies:
    4
    Views:
    328
    Michael Wojcik
    May 1, 2006
  4. Angel Tsankov

    linkage of free functions

    Angel Tsankov, Apr 11, 2006, in forum: C++
    Replies:
    3
    Views:
    287
    Pete Becker
    Apr 12, 2006
  5. Replies:
    1
    Views:
    589
    Michael DOUBEZ
    Sep 12, 2008
Loading...

Share This Page