porting old code, pointer problems

Discussion in 'C Programming' started by gobo20@lycos.com, Nov 25, 2008.

  1. Guest

    i'm trying to port some old code to a more current linux compiler.
    i've run into an error that i
    have been at a loss to correct. the following, very brief, sections
    compile and generate executables
    under pcdos turbo-c and gcc 3.3.6 (slackware 10.1). i've not included
    much code, so i hope
    someone has come across this before and can recognize it.

    this is defined in .h:
    typedef struct {
    unsigned attr;
    unsigned valu;
    char oname[7];
    } OPCODE;

    code section with error:

    110 OPCODE *find_code(nam)
    111 char *nam;
    112 {
    113 OPCODE *bsearch();
    114
    115 static OPCODE opctbl[] = {
    116 { AJMP, 0x11,
    "ACALL" },
    117 { ADD + ((R7 - A) << 5) + A, 0x24,
    "ADD" },


    under gcc 4.2.1 (suse 10.3) i get the following error:

    util.c:113: error: conflicting types for ‘bsearch’
    /usr/include/stdlib.h:775: error: previous declaration of ‘bsearch’
    was here

    i did not write this code and i'm still trying to understand the
    authors use of
    bsearch return as a pointer. problem is, i know it "used" to work...

    any suggestions?
    thanks.
    , Nov 25, 2008
    #1
    1. Advertising

  2. James Kuyper Guest

    Jack Klein wrote:
    > On Mon, 24 Nov 2008 19:54:05 -0800 (PST), wrote in
    > comp.lang.c:
    >
    >> i'm trying to port some old code to a more current linux compiler.
    >> i've run into an error that i
    >> have been at a loss to correct. the following, very brief, sections
    >> compile and generate executables
    >> under pcdos turbo-c and gcc 3.3.6 (slackware 10.1). i've not included
    >> much code, so i hope
    >> someone has come across this before and can recognize it.
    >>
    >> this is defined in .h:
    >> typedef struct {
    >> unsigned attr;
    >> unsigned valu;
    >> char oname[7];
    >> } OPCODE;
    >>
    >> code section with error:
    >>
    >> 110 OPCODE *find_code(nam)
    >> 111 char *nam;
    >> 112 {
    >> 113 OPCODE *bsearch();
    >> 114
    >> 115 static OPCODE opctbl[] = {
    >> 116 { AJMP, 0x11,
    >> "ACALL" },
    >> 117 { ADD + ((R7 - A) << 5) + A, 0x24,
    >> "ADD" },
    >>
    >>
    >> under gcc 4.2.1 (suse 10.3) i get the following error:
    >>
    >> util.c:113: error: conflicting types for ‘bsearch’
    >> /usr/include/stdlib.h:775: error: previous declaration of ‘bsearch’
    >> was here
    >>
    >> i did not write this code and i'm still trying to understand the
    >> authors use of
    >> bsearch return as a pointer. problem is, i know it "used" to work...
    >>
    >> any suggestions?
    >> thanks.

    >
    > Your compiler is telling you what the problem is. The standard header
    > <stdlib.h> declares a prototype for the standard C library function
    > bsearch(), including its return type, which is not a pointer to an
    > OPCODE struct.
    >
    > When you compile this code, you are directly or indirectly including
    > <stdlib.h>, so the compiler has the correct prototype in scope. When
    > it comes across the prototype in your source file, with a different


    What's on line 113 is a declaration for bsearch(), not a prototype.

    > return type, it quite rightly complains.
    >
    > The minimal proper solution is to remove the incorrect prototype from
    > the source file, since is already has the proper prototype.


    While that is the minimum change that might make the program correct,
    there are other things that need to be done as well as, or instead of,
    removing line 113.

    Before doing anything else, determine whether or not the program
    provides it's own definition of a function named bsearch(). If it does,
    rename that function, both in the definition, and also in every call to
    the function, so it doesn't conflict with the standard library function.

    If there is no such definition in the code, remove line 113, and then
    check to make sure that the code uses bsearch() in a way consistent with
    the requirements of the C standard library. To a considerable extent,
    any decent compiler with warning levels set high will catch many of
    possible problems, just because of the prototype declared in <stdlib.h>.
    However, it's possible that there's some more subtle issues, so check
    each call to bsearch() and make sure you understand what it's doing, and
    that it's doing it correctly.
    James Kuyper, Nov 25, 2008
    #2
    1. Advertising

  3. Guest

    On Nov 25, 5:20 am, James Kuyper <> wrote:
    > Jack Klein wrote:
    > > On Mon, 24 Nov 2008 19:54:05 -0800 (PST), wrote in
    > > comp.lang.c:

    >
    > >> i'm trying to port some old code to a more current linux compiler.
    > >> i've run into an error that i
    > >> have been at a loss to correct. the following, very brief, sections
    > >> compile and generate executables
    > >> under pcdos turbo-c and gcc 3.3.6 (slackware 10.1). i've not included
    > >> much code, so i hope
    > >> someone has come across this before and can recognize it.

    >
    > >> this is defined in .h:
    > >> typedef struct {
    > >> unsigned attr;
    > >> unsigned valu;
    > >> char oname[7];
    > >> } OPCODE;

    >
    > >> code section with error:

    >
    > >> 110 OPCODE *find_code(nam)
    > >> 111 char *nam;
    > >> 112 {
    > >> 113 OPCODE *bsearch();
    > >> 114
    > >> 115 static OPCODE opctbl[] = {
    > >> 116 { AJMP, 0x11,
    > >> "ACALL" },
    > >> 117 { ADD + ((R7 - A) << 5) + A, 0x24,
    > >> "ADD" },

    >
    > >> under gcc 4.2.1 (suse 10.3) i get the following error:

    >
    > >> util.c:113: error: conflicting types for ‘bsearch’
    > >> /usr/include/stdlib.h:775: error: previous declaration of ‘bsearch’
    > >> was here

    >
    > >> i did not write this code and i'm still trying to understand the
    > >> authors use of
    > >> bsearch return as a pointer. problem is, i know it "used" to work...

    >
    > >> any suggestions?
    > >> thanks.

    >
    > > Your compiler is telling you what the problem is. The standard header
    > > <stdlib.h> declares a prototype for the standard C library function
    > > bsearch(), including its return type, which is not a pointer to an
    > > OPCODE struct.

    >
    > > When you compile this code, you are directly or indirectly including
    > > <stdlib.h>, so the compiler has the correct prototype in scope. When
    > > it comes across the prototype in your source file, with a different

    >
    > What's on line 113 is a declaration for bsearch(), not a prototype.

    i agree that it's not a prototype. but is it really a "declaration
    for bsearch()" or a declaration for a pointer to the value returned by
    bsearch()? if it is a pointer def, and i'm leaning in that direction,
    then it is poorly formed. that would go a little ways to explaining
    why gcc 3.x will accept it and gcc 4.x will not. but, i've not really
    proven that idea to myself...

    >
    > > return type, it quite rightly complains.

    >
    > > The minimal proper solution is to remove the incorrect prototype from
    > > the source file, since is already has the proper prototype.

    >
    > While that is the minimum change that might make the program correct,
    > there are other things that need to be done as well as, or instead of,
    > removing line 113.
    >
    > Before doing anything else, determine whether or not the program
    > provides it's own definition of a function named bsearch(). If it does,
    > rename that function, both in the definition, and also in every call to
    > the function, so it doesn't conflict with the standard library function.
    >

    that was actually my first thought. i knew of lsearch but not
    remember bsearch until i started pulling books off the shelf. there
    is no function bsearch() in the program.


    > If there is no such definition in the code, remove line 113, and then
    > check to make sure that the code uses bsearch() in a way consistent with
    > the requirements of the C standard library.

    i thought i did that, but i'll have to go try again.

    To a considerable extent,
    > any decent compiler with warning levels set high will catch many of
    > possible problems, just because of the prototype declared in <stdlib.h>.

    that's true. if i use the -Wall option on the gcc 3.x compiler, it
    will issue the message about the conflict but with a warning. so it
    was indeed a problem there too, just overlooked.


    > However, it's possible that there's some more subtle issues, so check
    > each call to bsearch() and make sure you understand what it's doing, and
    > that it's doing it correctly.

    i'm still working my way through the understanding of his code.
    , Nov 25, 2008
    #3
  4. jameskuyper Guest

    wrote:
    > On Nov 25, 5:20 am, James Kuyper <> wrote:
    > > Jack Klein wrote:
    > > > On Mon, 24 Nov 2008 19:54:05 -0800 (PST), wrote in
    > > > comp.lang.c:

    ....
    > > >> this is defined in .h:
    > > >> typedef struct {
    > > >> unsigned attr;
    > > >> unsigned valu;
    > > >> char oname[7];
    > > >> } OPCODE;

    > >
    > > >> code section with error:

    > >
    > > >> 110 OPCODE *find_code(nam)
    > > >> 111 char *nam;
    > > >> 112 {
    > > >> 113 OPCODE *bsearch();
    > > >> 114
    > > >> 115 static OPCODE opctbl[] = {
    > > >> 116 { AJMP, 0x11,
    > > >> "ACALL" },
    > > >> 117 { ADD + ((R7 - A) << 5) + A, 0x24,
    > > >> "ADD" },

    ....
    > > > When you compile this code, you are directly or indirectly including
    > > > <stdlib.h>, so the compiler has the correct prototype in scope. When
    > > > it comes across the prototype in your source file, with a different

    > >
    > > What's on line 113 is a declaration for bsearch(), not a prototype.

    > i agree that it's not a prototype. but is it really a "declaration
    > for bsearch()" or a declaration for a pointer to the value returned by
    > bsearch()?


    Yes, line 113 declares bsearch() as the name of a function taking an
    unspecified (but not variable) number of arguments, and returning a
    value of type pointer to OPCODE. The () characters are the key thing
    that identifies this as a function declaration. It's quite possible
    for a parenthesis to occur in the declaration of a pointer object, but
    not when they're used this way.

    ....
    > > any decent compiler with warning levels set high will catch many of
    > > possible problems, just because of the prototype declared in <stdlib.h>.

    > that's true. if i use the -Wall option on the gcc 3.x compiler, it
    > will issue the message about the conflict but with a warning. so it
    > was indeed a problem there too, just overlooked.


    Once you've removed the conflicting declaration, you may discover
    additional problems, that were hidden by that declaration.
    jameskuyper, Nov 25, 2008
    #4
    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. TheDD

    Porting old non ansi code

    TheDD, Feb 23, 2004, in forum: C++
    Replies:
    5
    Views:
    532
    TheDD
    Feb 23, 2004
  2. Jim Hill
    Replies:
    3
    Views:
    388
    Jim Hill
    Feb 12, 2007
  3. *Prot3anThr3ad*

    old repository for old C++ source code

    *Prot3anThr3ad*, Sep 29, 2006, in forum: C++
    Replies:
    6
    Views:
    364
    *Prot3anThr3ad*
    Oct 2, 2006
  4. John Henry
    Replies:
    24
    Views:
    989
    alex23
    May 30, 2008
  5. raj s
    Replies:
    5
    Views:
    303
Loading...

Share This Page