problem in modular programing

[ashu]

lets look at the code given below
here i m trying to do mudular programming
/* this is my main prog.*/
/*mmod.c*/
#include<stdio.h>
#include "mod1.h"
int main(void)
{
int n;
puts("enter the value of n");
scanf("%d",&n);
printf("the square of %d is :- %ld",n,sqr(n));
return 0;
}

/*this is my secondary module */
/*mod1.c*/
#include "mod1.h"

long sqr(int x)
{
return ((long)((x)*(x)));
}

/*this is my header file*/
/*mod1.h*/
long sqr(int x);
when i compile main & secondary module,every thing is ok, but as i am

trying to link them,there is a linker error i.e,undefined symbol _sqr

in mmod.exe

[Vladimir S. Oka]

ashu wrote:

lets look at the code given below
here i m trying to do mudular programming
/* this is my main prog.*/
/*mmod.c*/
#include<stdio.h>
#include "mod1.h"
int main(void)
{
int n;
puts("enter the value of n");
scanf("%d",&n);
printf("the square of %d is :- %ld",n,sqr(n));
return 0;
}

/*this is my secondary module */
/*mod1.c*/
#include "mod1.h"

long sqr(int x)
{
return ((long)((x)*(x)));
}

/*this is my header file*/
/*mod1.h*/
long sqr(int x);
when i compile main & secondary module,every thing is ok, but as i am

trying to link them,there is a linker error i.e,undefined symbol _sqr

in mmod.exe

<OT>
Did you remember to tell your linker about mod1.o[bj]? The exact way
will depend on your toolchain.
</OT>

--
BR, Vladimir

[osmium]

"ashu" writes:

lets look at the code given below
here i m trying to do mudular programming
/* this is my main prog.*/
/*mmod.c*/
#include<stdio.h>
#include "mod1.h"
int main(void)
{
int n;
puts("enter the value of n");
scanf("%d",&n);
printf("the square of %d is :- %ld",n,sqr(n));
return 0;
}

/*this is my secondary module */
/*mod1.c*/
#include "mod1.h"

long sqr(int x)
{
return ((long)((x)*(x)));
}

/*this is my header file*/
/*mod1.h*/
long sqr(int x);
when i compile main & secondary module,every thing is ok, but as i am

trying to link them,there is a linker error i.e,undefined symbol _sqr

in mood.exe

Looks OK to me. This kind of problem relates to your compiler setup and
this group doesn't discuss such things. So repost to a group dealing with
your compiler. But first,search the group you select for words such as make
file, IDE, project. Use the advanced search of Google groups. It is
unlikely you are the first person to have this problem.

[tmp123]

ashu wrote:

lets look at the code given below
here i m trying to do mudular programming
/* this is my main prog.*/
/*mmod.c*/
#include<stdio.h>
#include "mod1.h"
int main(void)
{
int n;
puts("enter the value of n");
scanf("%d",&n);
printf("the square of %d is :- %ld",n,sqr(n));
return 0;
}

/*this is my secondary module */
/*mod1.c*/
#include "mod1.h"

long sqr(int x)
{
return ((long)((x)*(x)));
}

/*this is my header file*/
/*mod1.h*/
long sqr(int x);
when i compile main & secondary module,every thing is ok, but as i am

trying to link them,there is a linker error i.e,undefined symbol _sqr

in mmod.exe

Hi,

I do not see any error in your sources that can cause this problem.
It could be a problem with the way you compile and link. In particular,
check the order of the .c files.
If you are doing it with line commands or a makefile, please, post it.

Kind regards.

PS: To all readers: I known the compiler commands are OT, but it is the
best way to discard that error was in the source.

[pemo]

tmp123 wrote:

ashu wrote:

lets look at the code given below
here i m trying to do mudular programming
/* this is my main prog.*/
/*mmod.c*/
#include<stdio.h>
#include "mod1.h"
int main(void)
{
int n;
puts("enter the value of n");
scanf("%d",&n);
printf("the square of %d is :- %ld",n,sqr(n));
return 0;
}

/*this is my secondary module */
/*mod1.c*/
#include "mod1.h"

long sqr(int x)
{
return ((long)((x)*(x)));
}

/*this is my header file*/
/*mod1.h*/
long sqr(int x);
when i compile main & secondary module,every thing is ok, but as i am

trying to link them,there is a linker error i.e,undefined symbol _sqr

in mmod.exe

Hi,

I do not see any error in your sources that can cause this problem.
It could be a problem with the way you compile and link. In
particular, check the order of the .c files.
If you are doing it with line commands or a makefile, please, post it.

Kind regards.

PS: To all readers: I known the compiler commands are OT, but it is
the best way to discard that error was in the source.

Sounds like you're possibly using Visual C?

The code looks ok, btw, you don't need to include mod1.h in mod1.c - but
it's doing no harm.

If you've got the MS compiler set up to run from a command prompt, then this
should work ...

cl mmod.c mod1.c [output in mmod.exe]

Or, if you just want to use the linker ...

link mmod.obj mod1.obj [output in mmod.exe]

To set up the Microsoft compiler so that it works from a command prompt,
open a command prompt, navigate to ...\Microsoft Visual Studio\VC98\Bin and
run vcvars32
--
==============
*Not a pedant*
==============

[Richard G. Riley]

On 2006-02-22, ashu <ri*********@yahoo.com> wrote:

lets look at the code given below
here i m trying to do mudular programming
/* this is my main prog.*/
/*mmod.c*/
#include<stdio.h>
#include "mod1.h"
int main(void)
{
int n;
puts("enter the value of n");
scanf("%d",&n);
printf("the square of %d is :- %ld",n,sqr(n));
return 0;
}

/*this is my secondary module */
/*mod1.c*/
#include "mod1.h"

long sqr(int x)
{
return ((long)((x)*(x)));
}

/*this is my header file*/
/*mod1.h*/
long sqr(int x);
when i compile main & secondary module,every thing is ok, but as i am

trying to link them,there is a linker error i.e,undefined symbol _sqr

in mmod.exe

You are doing something wrong in the linker stage. Can you get the
compiler specific options to compile & link? Check them.

e.g using gcc under linux the following works fine

gcc -g mmod.c mod1.c
../a.out

(runs fine)

One thing : you dont need to include mod1.h into mod1.c : unless
someone can tell me a good reason why one should do so?

There will be a lot of people telling you this is OT for this NG and
they will be kind of right but stick with it - it can all be
confusing when you start :) Learn about make files. Use google.

--
Remove evomer to reply

[tmp123]

Richard G. Riley wrote:

One thing : you dont need to include mod1.h into mod1.c : unless
someone can tell me a good reason why one should do so?

Verify prototypes?

[tmp123]

pemo wrote:

tmp123 wrote:

ashu wrote:

lets look at the code given below
here i m trying to do mudular programming

....
I do not see any error in your sources that can cause this problem.
It could be a problem with the way you compile and link. In
particular, check the order of the .c files.
If you are doing it with line commands or a makefile, please, post it.

Sounds like you're possibly using Visual C?

O, no, me not: VC is too expensive for my bank account.
Was you trying to reply to the OP?

[Chris Dollin]

pemo wrote:

The code looks ok, btw, you don't need to include mod1.h in mod1.c - but
it's doing no harm.

You /should/ so include the .h in the .c; how else can you portably be
sure the compiler is going to detect mismatches between the declaration
and the definition?

--
Chris "was stirred, now shaken" Dollin
RIP Andreas "G'Kar" Katsulas, May 1946 - February 2006

[Richard G. Riley]

On 2006-02-22, Chris Dollin <ke**@hpl.hp.com> wrote:

pemo wrote:

The code looks ok, btw, you don't need to include mod1.h in mod1.c - but
it's doing no harm.

You /should/ so include the .h in the .c; how else can you portably be
sure the compiler is going to detect mismatches between the declaration
and the definition?

How does that affect including mod1.h into mod1.c?

--
Remove evomer to reply

[David Resnick]

Richard G. Riley wrote:

On 2006-02-22, Chris Dollin <ke**@hpl.hp.com> wrote:

pemo wrote:

The code looks ok, btw, you don't need to include mod1.h in mod1.c - but
it's doing no harm.

You /should/ so include the .h in the .c; how else can you portably be
sure the compiler is going to detect mismatches between the declaration
and the definition?

How does that affect including mod1.h into mod1.c?

--
Remove evomer to reply

If you include it, it lets the compiler diagnose mismatches between
the definitions and declarations as was said above. Often then
clearer what is going on. Not "required", just a good idea.

Code standards in my group say to include your own header
*first*. That guarantees that anything needed by your header itself
(e.g. including <stdio.h> for FILE that is in a declaration) will be
there
assuming that your file can then compile -- it won't be masked
by inclusion of <stdio.h> in some other header above yours.
That prevents other users of the header (if any) from
having to figure out why your header isn't working.

-David

[Richard G. Riley]

On 2006-02-22, David Resnick <ln********@gmail.com> wrote:

Richard G. Riley wrote:

On 2006-02-22, Chris Dollin <ke**@hpl.hp.com> wrote:

> pemo wrote:
>
>> The code looks ok, btw, you don't need to include mod1.h in mod1.c - but
>> it's doing no harm.
>
> You /should/ so include the .h in the .c; how else can you portably be
> sure the compiler is going to detect mismatches between the declaration
> and the definition?
>
How does that affect including mod1.h into mod1.c?

--
Remove evomer to reply

If you include it, it lets the compiler diagnose mismatches between
the definitions and declarations as was said above. Often then
clearer what is going on. Not "required", just a good idea.

I can buy into that. But does it give any real advantage considering
the users of that external do include the header? And then theres the
linking to hilite errors too.
Code standards in my group say to include your own header
*first*. That guarantees that anything needed by your header itself
(e.g. including <stdio.h> for FILE that is in a declaration) will be
there
assuming that your file can then compile -- it won't be masked
by inclusion of <stdio.h> in some other header above yours.
That prevents other users of the header (if any) from
having to figure out why your header isn't working.
Interesting. It was never a problem I came across but it makes some
sense. But I'm a little confused about what you mean by my *header*
needing things. I normally try to keep module headers as simple
declarations of that modules capabilities - the c module itself
includes the headers that it needs. If you follow me :)

-David

--
Remove evomer to reply

[CBFalconer]

pemo wrote:

.... snip ...
The code looks ok, btw, you don't need to include mod1.h in mod1.c
- but it's doing no harm.

Yes he should. That checks that the .h and .c files are compatible.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[Pedro Graca]

pemo wrote:
[snip: ashu's example of modular programming and tmp123 answer]

you don't need to include mod1.h in mod1.c - but
it's doing no harm.

Isn't this a standard thing to do (I mean #include WHATEVER.h in
WHATEVER.c) to validate the header file?

If the implementation is changed without a corresponding change to the
header file, I assume the error will not be caught.

Test to validate my assumption:

tmp$ cat main.c utils.h utils.c
/* main.c */
#include <stdio.h>
#include "utils.h"
int main(void) {
long x = sqr(42);
printf("sqr(42) is %ld.\n\n", x);
return 0;
}

/* utils.h */
long sqr(int);

/* utils.c */
/* changed return type (was long) */
double sqr(int a) {
return (double)a*a; /* added cast to force double result */
}

tmp$ gcc -W -Wall -std=c89 -pedantic main.c utils.c
tmp$ ./a.out
sqr(42) is 0.

tmp$ sed -e 's/long/double/' -i utils.h
tmp$ gcc -W -Wall -std=c89 -pedantic main.c utils.c
tmp$ ./a.out
sqr(42) is 1764.

--
If you're posting through Google read <http://cfaj.freeshell.org/google>

[Jordan Abel]

On 2006-02-22, Richard G. Riley <rg***********@gmail.com> wrote:

Interesting. It was never a problem I came across but it makes some
sense. But I'm a little confused about what you mean by my *header*
needing things. I normally try to keep module headers as simple
declarations of that modules capabilities - the c module itself
includes the headers that it needs. If you follow me :)

The header may need to include other headers that declare types which
are used for parameters or return values within the header (as with FILE
in the example)

[Richard G. Riley]

On 2006-02-22, Jordan Abel <ra*******@gmail.com> wrote:

On 2006-02-22, Richard G. Riley <rg***********@gmail.com> wrote:

Interesting. It was never a problem I came across but it makes some
sense. But I'm a little confused about what you mean by my *header*
needing things. I normally try to keep module headers as simple
declarations of that modules capabilities - the c module itself
includes the headers that it needs. If you follow me :)

The header may need to include other headers that declare types which
are used for parameters or return values within the header (as with FILE
in the example)

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. Is this bad practice? if it is, I'll put it right but it never
caused me a problem. Any light you can throw on this is appreciated.
--
Remove evomer to reply

[Ben Pfaff]

"Richard G. Riley" <rg***********@gmail.com> writes:

On 2006-02-22, David Resnick <ln********@gmail.com> wrote:

Richard G. Riley wrote:

On 2006-02-22, Chris Dollin <ke**@hpl.hp.com> wrote:
> You /should/ so include the .h in the .c; how else can you portably be
> sure the compiler is going to detect mismatches between the declaration
> and the definition?

If you include it, it lets the compiler diagnose mismatches between
the definitions and declarations as was said above. Often then
clearer what is going on. Not "required", just a good idea.

I can buy into that. But does it give any real advantage considering
the users of that external do include the header? And then theres the
linking to hilite errors too.

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.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[Fred Kleinschmidt]

"ashu" <ri*********@yahoo.com> wrote in message
news:11*********************@o13g2000cwo.googlegro ups.com...

lets look at the code given below
here i m trying to do mudular programming
/* this is my main prog.*/
/*mmod.c*/
#include<stdio.h>
#include "mod1.h"
int main(void)
{
int n;
puts("enter the value of n");
scanf("%d",&n);
printf("the square of %d is :- %ld",n,sqr(n));
return 0;
}

/*this is my secondary module */
/*mod1.c*/
#include "mod1.h"

long sqr(int x)
{
return ((long)((x)*(x)));
}

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;
--
Fred L. Kleinschmidt
Boeing Associate Technical Fellow
Technical Architect, Software Reuse Project

[pemo]

CBFalconer wrote:

pemo wrote:

... snip ...

The code looks ok, btw, you don't need to include mod1.h in mod1.c
- but it's doing no harm.

Yes he should. That checks that the .h and .c files are compatible.

Whether he *should* include, vs. *need* include the header is really a
different question. Personally, I think I *would* include the .h if it were
my code - however, I just wanted to point out that it isn't actually
required.

--
==============
*Not a pedant*
==============

[David Resnick]

Richard G. Riley wrote:

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. Is this bad practice? if it is, I'll put it right but it never
caused me a problem. Any light you can throw on this is appreciated.
--
Remove evomer to reply

Errors and warnings from the compiler/linker
depend on the compiler/linker. But consider this gcc example:

foo.c
int main(void)
{
return 0;
}
void foo(long quux)
{
}

bar.c
#include "foo.h"

void bar(void) {
foo();
}

foo.h
void foo(void);

temp(1327)$ gcc -Wall -o foo foo.c bar.c
temp(1327)$

No gripes. And foo the foo function will be reading garbage it seems.
Compare that to this foo.c (where foo.h and bar.c are unchanged)
#include "foo.h"

int main(void)
{
return 0;
}

void foo(long quux)
{
}

temp(1331)$ gcc -Wall -o foo foo.c bar.c
foo.c:9: conflicting types for `foo'
foo.h:1: previous declaration of `foo'

-David

[Jordan Abel]

On 2006-02-22, Richard G. Riley <rg***********@gmail.com> wrote:

On 2006-02-22, Jordan Abel <ra*******@gmail.com> wrote:

On 2006-02-22, Richard G. Riley <rg***********@gmail.com> wrote:

Interesting. It was never a problem I came across but it makes some
sense. But I'm a little confused about what you mean by my *header*
needing things. I normally try to keep module headers as simple
declarations of that modules capabilities - the c module itself
includes the headers that it needs. If you follow me :)

The header may need to include other headers that declare types which
are used for parameters or return values within the header (as with FILE
in the example)

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]

"Fred Kleinschmidt" writes:

"ashu" <ri*********@yahoo.com> wrote in message
news:11*********************@o13g2000cwo.googlegro ups.com...

lets look at the code given below
here i m trying to do mudular programming
/* this is my main prog.*/
/*mmod.c*/
#include<stdio.h>
#include "mod1.h"
int main(void)
{
int n;
puts("enter the value of n");
scanf("%d",&n);
printf("the square of %d is :- %ld",n,sqr(n));
return 0;
}

/*this is my secondary module */
/*mod1.c*/
#include "mod1.h"

long sqr(int x)
{
return ((long)((x)*(x)));
}

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]

Jordan Abel <ra*******@gmail.com> writes:

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.
--
"I've been on the wagon now for more than a decade. Not a single goto
in all that time. I just don't need them any more. I don't even use
break or continue now, except on social occasions of course. And I
don't get carried away." --Richard Heathfield

[Richard G. Riley]

On 2006-02-22, Jordan Abel <ra*******@gmail.com> wrote:

On 2006-02-22, Richard G. Riley <rg***********@gmail.com> wrote:

On 2006-02-22, Jordan Abel <ra*******@gmail.com> wrote:

On 2006-02-22, Richard G. Riley <rg***********@gmail.com> wrote:
Interesting. It was never a problem I came across but it makes some
sense. But I'm a little confused about what you mean by my *header*
needing things. I normally try to keep module headers as simple
declarations of that modules capabilities - the c module itself
includes the headers that it needs. If you follow me :)

The header may need to include other headers that declare types which
are used for parameters or return values within the header (as with FILE
in the example)

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?

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.
--
Remove evomer to reply

[Richard G. Riley]

On 2006-02-22, Ben Pfaff <bl*@cs.stanford.edu> wrote:

"Richard G. Riley" <rg***********@gmail.com> writes:

On 2006-02-22, David Resnick <ln********@gmail.com> wrote:

Richard G. Riley wrote:
On 2006-02-22, Chris Dollin <ke**@hpl.hp.com> wrote:
> You /should/ so include the .h in the .c; how else can you portably be
> sure the compiler is going to detect mismatches between the declaration
> and the definition?

If you include it, it lets the compiler diagnose mismatches between
the definitions and declarations as was said above. Often then
clearer what is going on. Not "required", just a good idea.

I can buy into that. But does it give any real advantage considering
the users of that external do include the header? And then theres the
linking to hilite errors too.

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.
--
Remove evomer to reply

[Chris Torek]

In article <46************@individual.net>
Richard G. Riley <rg***********@gmail.com> wrote:

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.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[pete]

tmp123 wrote:

Richard G. Riley wrote:

One thing : you dont need to include mod1.h into mod1.c : unless
someone can tell me a good reason why one should do so?

Verify prototypes?

That's the usual reason.

--
pete