Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > porting old code, pointer problems

Reply
Thread Tools

porting old code, pointer problems

 
 
gobo20@lycos.com
Guest
Posts: n/a
 
      11-25-2008
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.
 
Reply With Quote
 
 
 
 
James Kuyper
Guest
Posts: n/a
 
      11-25-2008
Jack Klein wrote:
> On Mon, 24 Nov 2008 19:54:05 -0800 (PST), http://www.velocityreviews.com/forums/(E-Mail Removed) 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.
 
Reply With Quote
 
 
 
 
gobo20@lycos.com
Guest
Posts: n/a
 
      11-25-2008
On Nov 25, 5:20 am, James Kuyper <(E-Mail Removed)> wrote:
> Jack Klein wrote:
> > On Mon, 24 Nov 2008 19:54:05 -0800 (PST), (E-Mail Removed) 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.


 
Reply With Quote
 
jameskuyper
Guest
Posts: n/a
 
      11-25-2008
(E-Mail Removed) wrote:
> On Nov 25, 5:20 am, James Kuyper <(E-Mail Removed)> wrote:
> > Jack Klein wrote:
> > > On Mon, 24 Nov 2008 19:54:05 -0800 (PST), (E-Mail Removed) 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Pointer to pointer or reference to pointer A C++ 7 07-05-2011 07:49 PM
Pointer to pointer Vs References to Pointer bansalvikrant@gmail.com C++ 4 07-02-2009 10:20 AM
passing the address of a pointer to a func that doesnt recieve a pointer-to-a-pointer jimjim C Programming 16 03-27-2006 11:03 PM
Pointer-to-pointer-to-pointer question masood.iqbal@lycos.com C Programming 10 02-04-2005 02:57 AM
Porting old non ansi code TheDD C++ 5 02-23-2004 11:25 PM



Advertisments