By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,562 Members | 1,282 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,562 IT Pros & Developers. It's quick & easy.

Preprocessor Directives Management Tool

P: n/a
All,

I'm looking for a tool that is able to take my code base (which is
full of preprocessor directives) and spit out source code that is
"clean" of any preprocessor directives based on the options I choose
(possibly via some kind of user input screen).

Does such a tool exist? A Visual Studio plugin would be even better.

FYI: I have requirements to rid my code of all conditionally compiled
code.

Thanks,
Dan
Oct 22 '08 #1
Share this Question
Share on Google+
14 Replies


P: n/a
lagman wrote:
All,

I'm looking for a tool that is able to take my code base (which is
full of preprocessor directives) and spit out source code that is
"clean" of any preprocessor directives based on the options I choose
(possibly via some kind of user input screen).
Most compilers have an options to output the pre-processes code. -E is
often used for this.

--
Ian Collins
Oct 22 '08 #2

P: n/a
Ian Collins wrote:
lagman wrote:
>All,

I'm looking for a tool that is able to take my code base (which is
full of preprocessor directives) and spit out source code that is
"clean" of any preprocessor directives based on the options I choose
(possibly via some kind of user input screen).
Most compilers have an options to output the pre-processes code. -E is
often used for this.
... but that's not a good tool for the task, because it will
expand all the macros and replace #include directives with the
included source.

The FAQ has pointers to some tools that might address the
problem better. (Can't vouch for them myself, but the pointers
are probably worth a look.)

--
Er*********@sun.com
Oct 22 '08 #3

P: n/a
Eric Sosman wrote:
Ian Collins wrote:
>lagman wrote:
>>All,

I'm looking for a tool that is able to take my code base (which is
full of preprocessor directives) and spit out source code that is
"clean" of any preprocessor directives based on the options I choose
(possibly via some kind of user input screen).
Most compilers have an options to output the pre-processes code. -E is
often used for this.

... but that's not a good tool for the task, because it will
expand all the macros and replace #include directives with the
included source.
Isn't #include a preprocessor directive?

The OP asked for something that would 'spit out source code that is
"clean" of any preprocessor directives'.

--
Ian Collins
Oct 22 '08 #4

P: n/a
Ian Collins <ia******@hotmail.comwrites:
Eric Sosman wrote:
>Ian Collins wrote:
>>lagman wrote:
All,

I'm looking for a tool that is able to take my code base (which is
full of preprocessor directives) and spit out source code that is
"clean" of any preprocessor directives based on the options I choose
(possibly via some kind of user input screen).

Most compilers have an options to output the pre-processes code. -E is
often used for this.

... but that's not a good tool for the task, because it will
expand all the macros and replace #include directives with the
included source.
Isn't #include a preprocessor directive?
Yes, but...
The OP asked for something that would 'spit out source code that is
"clean" of any preprocessor directives'.
They clarified the requirement:

| FYI: I have requirements to rid my code of all conditionally compiled
| code.

--
Ben.
Oct 22 '08 #5

P: n/a
Ben Bacarisse wrote:
Ian Collins <ia******@hotmail.comwrites:
>Eric Sosman wrote:
>>Ian Collins wrote:
lagman wrote:
All,
>
I'm looking for a tool that is able to take my code base (which is
full of preprocessor directives) and spit out source code that is
"clean" of any preprocessor directives based on the options I choose
(possibly via some kind of user input screen).
>
Most compilers have an options to output the pre-processes code. -E is
often used for this.
... but that's not a good tool for the task, because it will
expand all the macros and replace #include directives with the
included source.
Isn't #include a preprocessor directive?

Yes, but...
>The OP asked for something that would 'spit out source code that is
"clean" of any preprocessor directives'.

They clarified the requirement:

| FYI: I have requirements to rid my code of all conditionally compiled
| code.
Which -E would do.

--
Ian Collins
Oct 22 '08 #6

P: n/a
Ian Collins <ia******@hotmail.comwrites:
Ben Bacarisse wrote:
>Ian Collins <ia******@hotmail.comwrites:
>>Eric Sosman wrote:
Ian Collins wrote:
lagman wrote:
>All,
>>
>I'm looking for a tool that is able to take my code base (which is
>full of preprocessor directives) and spit out source code that is
>"clean" of any preprocessor directives based on the options I choose
>(possibly via some kind of user input screen).
>>
Most compilers have an options to output the pre-processes code. -E is
often used for this.
... but that's not a good tool for the task, because it will
expand all the macros and replace #include directives with the
included source.

Isn't #include a preprocessor directive?

Yes, but...
>>The OP asked for something that would 'spit out source code that is
"clean" of any preprocessor directives'.

They clarified the requirement:

| FYI: I have requirements to rid my code of all conditionally compiled
| code.
Which -E would do.
I never said otherwise! A tool that follows #includes (so it can find
#defines and so on) but does not replace them is more useful than -E.
Once you have expanded #includes you may not even have C anymore! You
certainly won't have portable C. The result might not even compile
using different compiler flags.

Eric was saying that the OP's *real* requirement might be better
served with a tool that is less crude than actually running the
pre-processor.

--
Ben.
Oct 22 '08 #7

P: n/a
Ian Collins wrote:
Eric Sosman wrote:
>Ian Collins wrote:
>>lagman wrote:
All,

I'm looking for a tool that is able to take my code base (which is
full of preprocessor directives) and spit out source code that is
"clean" of any preprocessor directives based on the options I choose
(possibly via some kind of user input screen).

Most compilers have an options to output the pre-processes code. -E is
often used for this.
... but that's not a good tool for the task, because it will
expand all the macros and replace #include directives with the
included source.
Isn't #include a preprocessor directive?

The OP asked for something that would 'spit out source code that is
"clean" of any preprocessor directives'.
You're right. Sorry; I'd imagined for a moment that
the O.P. was asking for something useful.

O.P.: Follow Ian's suggestion to get source code that
is completely free from preprocessor directives (perhaps
after stripping out some #line directives), and almost
completely useless. You will never be able to move the
resulting source to another machine, or even to another
compiler. You may not even be able to move it to your
current compiler if you decide to change the compilation
options or apply the latest patches. Have a nice life!

--
Eric Sosman
es*****@ieee-dot-org.invalid
Oct 23 '08 #8

P: n/a
On Oct 23, 2:46*am, lagman <dan_hoff...@hailmail.netwrote:
All,

I'm looking for a tool that is able to take my code base (which is
full of preprocessor directives) and spit out source code that is
"clean" of any preprocessor directives based on the options I choose
(possibly via some kind of user input screen).

Does such a tool exist? *A Visual Studio plugin would be even better.

FYI: *I have requirements to rid my code of all conditionally compiled
code.
Do you wish that your code should be 'compilable' after you get rid of
all preprocessor directives ? Or you just want to run some static code
analysis tool on it ?

- Pranav
http://pranavsbrain.peshwe.com
Oct 23 '08 #9

P: n/a
On Oct 22, 8:05*pm, Eric Sosman <esos...@ieee-dot-org.invalidwrote:
Ian Collins wrote:
Eric Sosman wrote:
Ian Collins wrote:
lagman wrote:
All,
>>I'm looking for a tool that is able to take my code base (which is
full of preprocessor directives) and spit out source code that is
"clean" of any preprocessor directives based on the options I choose
(possibly via some kind of user input screen).
>Most compilers have an options to output the pre-processes code. *-E is
often used for this.
* * ... but that's not a good tool for the task, because it will
expand all the macros and replace #include directives with the
included source.
Isn't #include a preprocessor directive?
The OP asked for something that would 'spit out source code that is
"clean" of any preprocessor directives'.

* * *You're right. *Sorry; I'd imagined for a moment that
the O.P. was asking for something useful.

* * *O.P.: Follow Ian's suggestion to get source code that
is completely free from preprocessor directives (perhaps
after stripping out some #line directives), and almost
completely useless. *You will never be able to move the
resulting source to another machine, or even to another
compiler. *You may not even be able to move it to your
current compiler if you decide to change the compilation
options or apply the latest patches. *Have a nice life!

--
Eric Sosman
esos...@ieee-dot-org.invalid- Hide quoted text -

- Show quoted text -
Sorry.. I'll clarify.. Not all preprocessor directives, just
conditionally compiled code (i.e. #ifdef/#ifndef)

Thanks,
Dan
Oct 23 '08 #10

P: n/a
lagman wrote:
All,

I'm looking for a tool that is able to take my code base (which is
full of preprocessor directives) and spit out source code that is
"clean" of any preprocessor directives based on the options I choose
(possibly via some kind of user input screen).

Does such a tool exist? A Visual Studio plugin would be even better.

FYI: I have requirements to rid my code of all conditionally compiled
code.

Thanks,
Dan
The lcc-win compiler will tell you which lines are active.
The utility browsegen from that system will show you which lines are
inactive.

For instance:

#ifdef FOO
int a;
#else
double a;
#endif

browsegen -showifdeflines -DFOO foo.c
3
4

browsegen -showifdeflines foo.c
1
2

Using the list of lines it is very easy to wrfite a simple utility that
will delete all the lines from a given file...

Obviously I can tailor the system to fit your needs, make it run under
linux/AIX/Solaris/ etc.

Just send me mail for price etc.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Oct 23 '08 #11

P: n/a
ja*********@verizon.net writes:
lagman wrote:
[...]
>Sorry.. I'll clarify.. Not all preprocessor directives, just
conditionally compiled code (i.e. #ifdef/#ifndef)

Do you want it to remove only the #ifdef and #ifndef statements? Do
you also want #if's removed? Do you want it to also remove the
corresponding #else, #elif, and #endif statements? Do you want it to
also remove all the code between each #ifdef/#ifndef direction and the
matching #endif directive? Those are all pretty trivial options.
They'll produce code that might not even compile, and if it does,
might not do what the original code did. But if that's what you want,
it's quite feasible.

I think it's most likely that you want it to remove all of the
conditional compilation directives, and the branches that would not
have been selected, while keeping the branches that would have been
selected. On some systems, preprocessing is performed by a completely
separate program; even when that's not the case, many compilers
provide an option (often -E) that has precisely that effect. However,
you've indicated that the conditional compilation directives are the
only ones you want removed, and that makes it much more complicated.
[...]

Here's an idea that won't quite work, but it might be the basis for
something that would.

Do it in three passes.

In pass 1, comment out all #include and #define directives. Do this
in a way that's reversible; each comment includes some unique string
that can be recognized in pass 3.

In pass 2, run the output of pass 1 through your preprocessor. (A
compiler isn't required to provide a preprocessor as a separate
program, but most do.)

In pass 3, uncomment the #include and #define directives that you
commented out in pass 1. Remember that if you had this line:

/* #include "foo.h" */

in your original source, it must remain as a comment in the final
result; this is why you need the unique string.

Why doesn't this actually work? Because some of your #if, #ifdef, and
#ifndef directives are likely to depend on macros that you'll have
commented out in pass 1.

My assumption is that, given this input:

#define FOO 42
#ifdef FOO
printf("FOO is defined as %d\n", FOO);
#else
puts("FOO is not defined");
#endif

you want this output:

#define FOO 42
printf("FOO is defined as %d\n", FOO);

If so, that means you need to pay attention macro definitions for
purposes of #if, #ifdef, and #ifndef, but not for purposes of
expansion. That makes it tricky.

Most Unix-like systems have a tool, originally from BSD, called
"unifdef" that might do much of what you want. If you have access to
it, read the documentation carefully; if you have questions about the
unifdef tool itself, comp.unix.programmer is probably the best place
to ask.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Oct 23 '08 #12

P: n/a
lagman <da*********@hailmail.netwrites:

<snip>
Sorry.. I'll clarify.. Not all preprocessor directives, just
conditionally compiled code (i.e. #ifdef/#ifndef)
Some C pre-processors can give you a leg up, so to speak. For
example, the GNU one has -fdirectives-only which gets you about 90% of
the way there.

It does process #includes but since it leaves a note of the files (and
line numbers) as it is reading the source, I suspect a small bit of
scripting could cut out the expansion of the includes and put the
original directives back.

--
Ben.
Oct 23 '08 #13

P: n/a
On Oct 23, 11:00*pm, Keith Thompson <ks...@mib.orgwrote:
jameskuy...@verizon.net writes:
lagman wrote:
[...]
Sorry.. I'll clarify.. Not all preprocessor directives, just
conditionally compiled code (i.e. #ifdef/#ifndef)
Do you want it to remove only the #ifdef and #ifndef statements? Do
you also want #if's removed? Do you want it to also remove the
corresponding #else, #elif, and #endif statements? Do you want it to
also remove all the code between each #ifdef/#ifndef direction and the
matching #endif directive? Those are all pretty trivial options.
They'll produce code that might not even compile, and if it does,
might not do what the original code did. But if that's what you want,
it's quite feasible.
I think it's most likely that you want it to remove all of the
conditional compilation directives, and the branches that would not
have been selected, while keeping the branches that would have been
selected. On some systems, preprocessing is performed by a completely
separate program; even when that's not the case, *many compilers
provide an option (often -E) that has precisely that effect. However,
you've indicated that the conditional compilation directives are the
only ones you want removed, and that makes it much more complicated.

[...]

Here's an idea that won't quite work, but it might be the basis for
something that would.

Do it in three passes.

In pass 1, comment out all #include and #define directives. *Do this
in a way that's reversible; each comment includes some unique string
that can be recognized in pass 3.

In pass 2, run the output of pass 1 through your preprocessor. *(A
compiler isn't required to provide a preprocessor as a separate
program, but most do.)

In pass 3, uncomment the #include and #define directives that you
commented out in pass 1. *Remember that if you had this line:

/* #include "foo.h" */

in your original source, it must remain as a comment in the final
result; this is why you need the unique string.

Why doesn't this actually work? *Because some of your #if, #ifdef, and
#ifndef directives are likely to depend on macros that you'll have
commented out in pass 1.
But, why to comment out the '#define's in the first place ? Without
doing that, your idea would probably work well.
Kindly CMIIW...

Pranav
http://pranavsbrain.peshwe.com
Oct 24 '08 #14

P: n/a
Pranav Peshwe <pr**********@gmail.comwrites:
On Oct 23, 11:00*pm, Keith Thompson <ks...@mib.orgwrote:
[...]
>Here's an idea that won't quite work, but it might be the basis for
something that would.

Do it in three passes.

In pass 1, comment out all #include and #define directives. *Do this
in a way that's reversible; each comment includes some unique string
that can be recognized in pass 3.

In pass 2, run the output of pass 1 through your preprocessor. *(A
compiler isn't required to provide a preprocessor as a separate
program, but most do.)

In pass 3, uncomment the #include and #define directives that you
commented out in pass 1. *Remember that if you had this line:

/* #include "foo.h" */

in your original source, it must remain as a comment in the final
result; this is why you need the unique string.

Why doesn't this actually work? *Because some of your #if, #ifdef, and
#ifndef directives are likely to depend on macros that you'll have
commented out in pass 1.

But, why to comment out the '#define's in the first place ? Without
doing that, your idea would probably work well.
Kindly CMIIW...
If you don't comment out the #defines, then this:

#define MAX_SIZE 1000
unsigned char buf[MAX_SIZE];

becomes this:

unsigned char buf[1000];

which I presume you don't want.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Oct 24 '08 #15

This discussion thread is closed

Replies have been disabled for this discussion.