How to avoid including C files in other C files in an old code base

[Raman]

Hi All,

We have an old code base which (unfortunatelty ) has some C files that
include other C files:e.g

File.c
=====
#include<stdio. h>
..
void someFunc(){
..
..
}

#include<culpri t.c>

void someOtherFunc() {

callAFunctionDe finedinCluprit( )

}
=====
Here, File.c includesa C file called culprit.c.

Problem:
We are porting this code base to Mainframes. The debugger there
( iSeries system debugger) does not support inclusion of the files.
When control of the execution reaches in culprit.c, debugger is unable
to highlight the statement being executed currently.

Possible Solution;
We could copy-paste the culprit.c in the File.c, However there are
some other files like Second.c that also include culprit.c. So the
code of culprit will be redundant.
Please help, if any other solution exists.

I understand this group is not about debugger/ Mainframes, However I
posted this query in this group because after all this is a bad
programming design as per the C language.

Also, If any one can suggest some place/group that discuss Mainframes.

Thanks and Regards,
Raman Chalotra

[Ben Bacarisse]

Raman <ra***********@ gmail.comwrites :

We have an old code base which (unfortunatelty ) has some C files that
include other C files:e.g

File.c
=====
#include<stdio. h>
.
void someFunc(){
}

#include<culpri t.c>

void someOtherFunc() {
callAFunctionDe finedinCluprit( )
}
=====
Here, File.c includesa C file called culprit.c.

Problem:
We are porting this code base to Mainframes. The debugger there
( iSeries system debugger) does not support inclusion of the files.

<snip>

Possible Solution;
We could copy-paste the culprit.c in the File.c, However there are
some other files like Second.c that also include culprit.c. So the
code of culprit will be redundant.

Please help, if any other solution exists.

Can you see any reason why the code is organised this way? If the
original authors are not playing tricks, it should be relatively easy
to replace this mechanism with the normal .h file with declarations
and .c with definitions, combined at like time.

This won't work if tricks are being played. The most common sort of
"trick" is to arrange for the included .c file to generate slightly
different code each time. So you see things like:

....
#define MAX_SIZE 1000
typedef double element_type;
#include "quick-and-dity-array-code.c"
....

where the .c file uses the defined and typedef'd names differently on
each include. If that is what is happening, ask again but giving
details of what is variable between includes -- there may be cleaner
way to do it.

--
Ben.

[Jens Thoms Toerring]

Ben Bacarisse <be********@bsb .me.ukwrote:

Raman <ra***********@ gmail.comwrites :

We have an old code base which (unfortunatelty ) has some C files that
include other C files:e.g

File.c
=====
#include<stdio. h>
.
void someFunc(){
}

#include<culpri t.c>

void someOtherFunc() {
callAFunctionDe finedinCluprit( )
}
=====
Here, File.c includesa C file called culprit.c.

Problem:
We are porting this code base to Mainframes. The debugger there
( iSeries system debugger) does not support inclusion of the files.

<snip>

Possible Solution;
We could copy-paste the culprit.c in the File.c, However there are
some other files like Second.c that also include culprit.c. So the
code of culprit will be redundant.

Please help, if any other solution exists.

Can you see any reason why the code is organised this way? If the
original authors are not playing tricks, it should be relatively easy
to replace this mechanism with the normal .h file with declarations
and .c with definitions, combined at like time.

This won't work if tricks are being played. The most common sort of
"trick" is to arrange for the included .c file to generate slightly
different code each time. So you see things like:

...
#define MAX_SIZE 1000
typedef double element_type;
#include "quick-and-dity-array-code.c"
...

where the .c file uses the defined and typedef'd names differently on
each include. If that is what is happening, ask again but giving
details of what is variable between includes -- there may be cleaner
way to do it.

Another reason that could fail is if culprit.c defines global
variables with file scope. In this case every place where
culprit.c is included gets its own set of these variables but
when you just call the functions from culprit.c then there
will be only one such set (which also can't be accessed from
the parts that now only call the functions in culprit.c).

Regards, Jens
--
\ Jens Thoms Toerring ___ [e-mail]
\______________ ____________ http://toerring.de

[Louis]

On Sat, 07 Jun 2008 02:33:28 -0700, Raman wrote:

Hi All,

We have an old code base which (unfortunatelty ) has some C files that
include other C files:e.g

File.c
=====
#include<stdio. h>
.
void someFunc(){
.
.
}

#include<culpri t.c>

void someOtherFunc() {

callAFunctionDe finedinCluprit( )

}
=====
Here, File.c includesa C file called culprit.c.

Problem:
We are porting this code base to Mainframes. The debugger there (
iSeries system debugger) does not support inclusion of the files. When
control of the execution reaches in culprit.c, debugger is unable to
highlight the statement being executed currently.

Possible Solution;
We could copy-paste the culprit.c in the File.c, However there are some
other files like Second.c that also include culprit.c. So the code of
culprit will be redundant.

Here's a cut-and-paste equivalent that avoids manual
duplication of code. Generate the ".c" sources from
a template using cpp:

1. mv File.c File.tpl
2. Edit File.tpl to add "#ifdef TEMPLATE" around all ".h" includes.
3. Provide for the generation of the source ".c" files in the makefile:
cpp -P -D TEMPLATE File1.tp File.c
Add rules to the makefile to handle .tpl -.c

CPP=gcc -E -P # or /lib/cpp -P, /usr/bin/cpp -P etc.
.SUFFIXES: .tpl
.tpl.c:
$(CPP) -P -DTEMPLATE $^ $@

File.tpl
=====
#ifndef TEMPLATE
#include<stdio. h>
/* Any other includes */
#else
/* This File generated by cpp from File.tpl do not edit. */
#endif
void someFunc(){
..
..
}

#include<culpri t.c>

void someOtherFunc() {

callAFunctionDe finedinCluprit( )

}
=====

>
Please help, if any other solution exists.

Hope that helps. Your cpp may be different.
-Louis

I understand this group is not about debugger/ Mainframes, However I
posted this query in this group because after all this is a bad
programming design as per the C language.

Also, If any one can suggest some place/group that discuss Mainframes.

Thanks and Regards,
Raman Chalotra

[lawrence.jones]

Raman <ra***********@ gmail.comwrote:

>
Problem:
We are porting this code base to Mainframes. The debugger there
( iSeries system debugger) does not support inclusion of the files.
When control of the execution reaches in culprit.c, debugger is unable
to highlight the statement being executed currently.

Complain to the vendor. That is a serious and, in my opinion,
unacceptable limitation in the debugger. At the same time, debuggers,
while helpful, are not mandatory. If the code is used in multiple
places as you say, I'd be inclined to leave it be and accept that you'll
need to use alternative techniques to debug it as the lesser of two
evils.

-- Larry Jones

You just can't ever be too careful. -- Calvin

[Lew Pitcher]

In comp.lang.c, Raman wrote:

Hi All,

We have an old code base which (unfortunatelty ) has some C files that
include other C files
[snip]
We are porting this code base to Mainframes. The debugger there
( iSeries system debugger) does not support inclusion of the files.
When control of the execution reaches in culprit.c, debugger is unable
to highlight the statement being executed currently.

One potential way around your problem is to see if your C compiler supports
an option to save the source code "after preprocessing". With this option,
you could save the source code where all #includes and #defines have been
resolved, and this can then be used as both the source input into your C
compile stage, /and/ the source input into your debugger.

If you were using the GNU C compiler (and in the iSeries, that /may/ be one
of your compiler choices), the -E compiler option "stops after the
preprocessing stage... The output is in the form of preprocessed source
code". Look for some similar option on your C compiler

[snip]
HTH
--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------