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

Discussion in 'C Programming' started by Raman, Jun 7, 2008.

  1. Raman

    Raman Guest

    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<culprit.c>

    void someOtherFunc(){

    callAFunctionDefinedinCluprit()

    }
    =====


    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
     
    Raman, Jun 7, 2008
    #1
    1. Advertising

  2. Raman <> writes:

    > 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<culprit.c>
    >
    > void someOtherFunc(){
    > callAFunctionDefinedinCluprit()
    > }
    > =====
    >
    >
    > 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.
     
    Ben Bacarisse, Jun 7, 2008
    #2
    1. Advertising

  3. Ben Bacarisse <> wrote:
    > Raman <> writes:


    > > 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<culprit.c>
    > >
    > > void someOtherFunc(){
    > > callAFunctionDefinedinCluprit()
    > > }
    > > =====
    > >
    > >
    > > 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 ___
    \__________________________ http://toerring.de
     
    Jens Thoms Toerring, Jun 7, 2008
    #3
  4. Raman

    Louis Guest

    Re: How to avoid including C files in other C files in an old codebase

    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<culprit.c>
    >
    > void someOtherFunc(){
    >
    > callAFunctionDefinedinCluprit()
    >
    > }
    > =====
    >
    >
    > 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<culprit.c>

    void someOtherFunc(){

    callAFunctionDefinedinCluprit()

    }
    =====



    >
    > 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
     
    Louis, Jun 7, 2008
    #4
  5. Raman

    Guest

    Raman <> wrote:
    >
    > 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
     
    , Jun 7, 2008
    #5
  6. Raman

    Lew Pitcher Guest

    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. ------
     
    Lew Pitcher, Jun 7, 2008
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. *Prot3anThr3ad*

    old repository for old C++ source code

    *Prot3anThr3ad*, Sep 29, 2006, in forum: C++
    Replies:
    6
    Views:
    390
    *Prot3anThr3ad*
    Oct 2, 2006
  2. Jorgen Grahn
    Replies:
    2
    Views:
    317
    Jorgen Grahn
    Sep 8, 2008
  3. Steve Wesorick

    Avoid including @ Register tag on every page

    Steve Wesorick, Jan 21, 2004, in forum: ASP .Net Building Controls
    Replies:
    2
    Views:
    140
    Patrice Scribe
    Jan 23, 2004
  4. George  Moschovitis
    Replies:
    3
    Views:
    109
    George Moschovitis
    Nov 19, 2004
  5. Nathan Beyer
    Replies:
    0
    Views:
    119
    Nathan Beyer
    Nov 15, 2009
Loading...

Share This Page