porting old code, pointer problems

[gobo20]

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.

 

[James Kuyper]

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.

 

[gobo20]

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...

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.

 

[jameskuyper]

....
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.

....

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.