problem in modular programing

[Jordan Abel]

True, if this is the case. Special types I tend to keep in type
headers though. If, as in your example one needs to do that then I
have always tried to only include in those modules which need.

I'm interested in this other statement that the compiler needs it to check
the prototype against the declaration : while I can see that this
might be useful I've not (habitually) done it since I tend to export
the headers from the module anyway and also the linker raises any
issues.

Eh? what issues does the linker raise if the name is right but the type
is wrong?

 

[osmium]

The above definition for the sqr() module is rather poor. The way you have
it, the compiler will probably multiply x*x as ints and then convert the
result to a long. Thus for any value of x greater than MAXINT/2 you will
likely get an overflow error.
Perhaps you really want
return (long)x * (long)x;

Yes, I noticed that too. But the first step is to be able to compile, link,
and execute his program. I hope the OP can detect the fact that the pissing
war he has triggered has nothing at all to do with the problem *he* has. It
has to do with variants of his program that might have caused a failure to
compile. The OPs program does, in fact, compile.

 

[Ben Pfaff]

Eh? what issues does the linker raise if the name is right but the type
is wrong?

There's no reason the linker *can't* raise such issues, as far as
I know. The behavior is undefined. This gives the
implementation the latitude to, e.g., do C++-style name mangling
and thereby flag type mismatches at link time.

 

[Richard G. Riley]

Eh? what issues does the linker raise if the name is right but the type
is wrong?

Hence my question : its not a problem I have come across. Common types
I tend to store seperate from the "x.h" header which represents the
"h.c" module.

I guess really my question is, and then I stand corrected, is it
really necessary to include function declarations into the module
where the functions are implemented? Its not something I have tended
to do with small standalone programs : bigger legacy system frequently
do this and I leave them untouched - and just as well if I'm missing
something really important here.

 

[Richard G. Riley]

Headers include more than function prototypes. They often define
structures, enumerations, unions, macros, etc. If the .c file
wants to use those (and it normally does) then it'll need to
include the .h.

Hi Ben : I addressed in another post. My own convention has tended to
be to seperate such declarations from function prototypes and to
include those in the module specifically.

 

[Chris Torek]

I guess really my question is, and then I stand corrected, is it
really necessary to include function declarations into the module
where the functions are implemented?

It is not *necessary*. It *is* a good idea.

A C compiler is not obliged to complain if we write the following, in
three separate files that build two translation units that build one
program:

/* main.c */
#include <stdio.h>
#include "bob.h"

int main(void) {
printf("bob() = %d\n", bob());
return 0;
}

/* bob.h */
int bob(void);

/* bob.c */
#include <string.h>
double bob(char *arg) {
if (strcmp(arg, "forty-two") == 0)
return 42.0;
return 3.1415926535897932384626433832795;
}

(Cut apart at comments, put into obvious files, and compile and see.)

Here main.c includes bob.h; bob.h lies, saying that bob() takes no
arguments and returns "int". Meanwhile, bob.c fails to include
bob.h. The compiler is not required to produce a diagnostic, and
most do not. The resulting executable (if we get one, and we usually
do) does not work right.

Had bob.c included bob.h, however, the compiler would have been
obligated to produce a diagnostic. We would have discovered, at
compile time, that bob.h lied about function bob(), and been given
a chance to fix the bug *before* it manifested.

 

[pete]

Verify prototypes?

That's the usual reason.