Watcom C didn’t care where my function protoptypes were. Now GNU C
requires them to be the last thing before the code section. How come?
J. Scott Franko <jsfranko@switch.com> wrote:
Watcom C didn’t care where my function protoptypes were. Now GNU C
requires them to be the last thing before the code section. How come?
Could you elaborate?
Well, I have a header called cctstr.h, and it defines a long structure.
Then I have a header file called cse_func.h that describes the protototypes
for a process called cse.
And then I have some functions that include the cctstr.h and the cse_func.h
and define functions that have a pointer to a cctstr as a parameter. In
one function it compiles ok, in another it doesn’t, and complains of a
function mismatch. I discovered that it was because of the position of the
cse_func include. If it was the last of the includes, the function
compiled. If it was in the middle of the list of includes, the function
complained of a mismatch in the function prototype. Before I discovered
that it was the order, I was able to make the problem go away by putting
register in front of the parameter definition. All of this stuff has
compiled for years on Watcom. But I am finding bugs like missing return
types, and such, between the prototypes and functions so this is a
benefitial process. Watcom may have been too forgiving.
Here is the text I was preparing to post before I solved it myself:
I have the following entries in these files:
file: ./headers/cse_func.h
void ccut(struct cctstr *);
void ccut2(struct cctstr *);
file: ./cse/ccut.c
#include #include #includeextern GLOBAL_SHARED_MEM_PTR shared_mem_ptr;
register void ccut(c) /* calculate cut information */
struct cctstr c; / car control table pointer */
{
file: ./cse/ccut2.c
#include #include #include #include/* STRUCTURES */
#include <shared_memory.h>
extern GLOBAL_SHARED_MEM_PTR shared_mem_ptr;
void ccut2(c) /* calculate cut information /
struct cctstr * c; / car control table pointer */
{
The first file compiles, the second one doesn’t, giving the error:
cc -I /home/colton/headers -wall -O -g -c ccut.c -o ccut.o
cc -I /home/colton/headers -wall -O -g -c ccut2.c -o ccut2.o
ccut2.c: In function ccut2': ccut2.c:58: argument c’ doesn’t match prototype
/home/colton/headers/cse_func.h:61: prototype declaration
cc: error 33
make: *** [ccut2.o] Error 1
As soon as I moved the inlcude down past <shared_memory.h>, ccut2 compiled.
The other method was to duplicate the register keyword found in the first
function. But another function that uses that same structure pointer as a
parameter works without the register keywoard.
I’m sure it’s next to impossible to figure this out without seeing all of
our sources. That would be difficult to post, not to mention a problem with
sending out proprietary source, that I don’t have the authority to do, but
if you need me to, I can work with you on this too develop as short example
where it fails.
Scott
Colin Burgess wrote:
J. Scott Franko <> jsfranko@switch.com> > wrote:
Watcom C didn’t care where my function protoptypes were. Now GNU C
requires them to be the last thing before the code section. How come?Could you elaborate?
Could you mail me the preprocessed output of the bad version?
cc -I /home/colton/headers -P ccut2.c
This will produce a ccut2.i, which is the result of passing
the preprocessor over it, and it will contain all the contents
of the includes.
J. Scott Franko <jsfranko@switch.com> wrote:
Well, I have a header called cctstr.h, and it defines a long structure.
Then I have a header file called cse_func.h that describes the protototypes
for a process called cse.And then I have some functions that include the cctstr.h and the cse_func.h
and define functions that have a pointer to a cctstr as a parameter. In
one function it compiles ok, in another it doesn’t, and complains of a
function mismatch. I discovered that it was because of the position of the
cse_func include. If it was the last of the includes, the function
compiled. If it was in the middle of the list of includes, the function
complained of a mismatch in the function prototype. Before I discovered
that it was the order, I was able to make the problem go away by putting
register in front of the parameter definition. All of this stuff has
compiled for years on Watcom. But I am finding bugs like missing return
types, and such, between the prototypes and functions so this is a
benefitial process. Watcom may have been too forgiving.Here is the text I was preparing to post before I solved it myself:
I have the following entries in these files:file: ./headers/cse_func.h
void ccut(struct cctstr *);
void ccut2(struct cctstr *);file: ./cse/ccut.c
snip
#include <env.h
#include <yrddef.h
#include <cse_func.hextern GLOBAL_SHARED_MEM_PTR shared_mem_ptr;
register void ccut(c) /* calculate cut information */
struct cctstr c; / car control table pointer */
{snip
file: ./cse/ccut2.c
snip
#include <env.h
#include <yrddef.h
#include <retcondef.h
#include <cse_func.h/* STRUCTURES */
#include <shared_memory.hextern GLOBAL_SHARED_MEM_PTR shared_mem_ptr;
void ccut2(c) /* calculate cut information /
struct cctstr * c; / car control table pointer */
{snip
The first file compiles, the second one doesn’t, giving the error:
cc -I /home/colton/headers -wall -O -g -c ccut.c -o ccut.o
cc -I /home/colton/headers -wall -O -g -c ccut2.c -o ccut2.o
ccut2.c: In functionccut2': ccut2.c:58: argumentc’ doesn’t match prototype
/home/colton/headers/cse_func.h:61: prototype declaration
cc: error 33
make: *** [ccut2.o] Error 1As soon as I moved the inlcude down past <shared_memory.h>, ccut2 compiled.
The other method was to duplicate the register keyword found in the first
function. But another function that uses that same structure pointer as a
parameter works without the register keywoard.I’m sure it’s next to impossible to figure this out without seeing all of
our sources. That would be difficult to post, not to mention a problem with
sending out proprietary source, that I don’t have the authority to do, but
if you need me to, I can work with you on this too develop as short example
where it fails.Scott
Colin Burgess wrote:
J. Scott Franko <> jsfranko@switch.com> > wrote:
Watcom C didn’t care where my function protoptypes were. Now GNU C
requires them to be the last thing before the code section. How come?Could you elaborate?