Executing code inside "#if 0"

qazmlp

There are some blocks of C/C++ code put under
#if 0

#end if
Is there anyway to make the code inside these blocks to get executed
(may be by using some command line options)?
I am using SUN compiler.

Nov 13 '05 #1

John Howells

qazmlp wrote:

There are some blocks of C/C++ code put under
#if 0

#end if

Is there anyway to make the code inside these blocks to get executed
(may be by using some command line options)?

I am using SUN compiler.

No. While it is there the enclosed code will be ignored by the compiler,
so there is nothing in the executable to execute. To run the code you
will have to recompile the program without the "#if 0", or after
changing it to something like "#if 01".

John Howells

Nov 13 '05 #2

Barry Margolin

In article <db*************************@posting.google.com> ,
qazmlp <qa********@rediffmail.com> wrote:

There are some blocks of C/C++ code put under
#if 0

#end if
Is there anyway to make the code inside these blocks to get executed
(may be by using some command line options)?

Why did you use "#if 0" if you meant for it to be an option you could
select at compile time? Change it to something like:

#if DEBUGGING
....
#endif

and then you can use -DDEBUGGING=1 when compiling to enable that block.

--
Barry Margolin, ba************@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

Nov 13 '05 #3

Timo Weggen

On Fri, 11 Jul 2003 16:21:04 +0200, Barry Margolin wrote:

In article <db*************************@posting.google.com> , qazmlp
<qa********@rediffmail.com> wrote:

There are some blocks of C/C++ code put under #if 0

#end if
Is there anyway to make the code inside these blocks to get executed
(may be by using some command line options)?

Why did you use "#if 0" if you meant for it to be an option you could
select at compile time? Change it to something like:

#if DEBUGGING
...
#endif

and then you can use -DDEBUGGING=1 when compiling to enable that block.

That's a good thing, you even can go further and use
use the symbol NDEBUG as used by the assert macro calls.
In a final/production build, -DNDEBUG is set.

Nov 13 '05 #4

Joerg Schilling

In article <3F***************@sun.com>,
Eric Sosman <Er*********@Sun.COM> wrote:

qazmlp wrote:

There are some blocks of C/C++ code put under
#if 0

#end if

Is there anyway to make the code inside these blocks to get executed
(may be by using some command line options)?

I am using SUN compiler.

tr 0 1 <original.c >tmp.c
mv tmp.c original.c
cc original.c

... and then debug ;-)

Because you need to find all the other funny places where a '0' has been
replaced by a '1' ;-)

--
EMail:jo***@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
sc*******@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Nov 13 '05 #5

bd

On Fri, 11 Jul 2003 03:47:15 -0700, qazmlp wrote:

There are some blocks of C/C++ code put under
#if 0

#end if
Is there anyway to make the code inside these blocks to get executed
(may be by using some command line options)?

Change the #if 0 to #if 1
--
Freenet distribution not available
Grelb's Reminder:
Eighty percent of all people consider themselves to be above
average drivers.

Nov 13 '05 #6

Ed Morton

Eric Sosman wrote:

qazmlp wrote:

There are some blocks of C/C++ code put under
#if 0

#end if

Is there anyway to make the code inside these blocks to get executed
(may be by using some command line options)?

I am using SUN compiler.
tr 0 1 <original.c >tmp.c

Appologies if this is getting too OT, but if you REALLY want to go this route,
then use this translation instead:

sed '/#if/s/0/1/' original.c > tmp.c

so you only translate the zeros on the "#if" lines rather than everywhere in
your program, then do a quick "diff" (or tkdiff if available) on the 2 files to
check the differences before compiling. I'd also keep a backup of original.c
before starting this process!

Ed.
mv tmp.c original.c
cc original.c

... and then debug ;-)

(In other words, no. The compiler is obeying your orders,
and cannot be persuaded to disobey.)

--
Er*********@sun.com

Nov 13 '05 #7

Emmanuel Delahaye

In 'comp.lang.c', qa********@rediffmail.com (qazmlp) wrote:

There are some blocks of C/C++ code put under
#if 0

#end if
Is there anyway to make the code inside these blocks to get executed
(may be by using some command line options)?

The question is not to be /executed/ of not, but to be *compiled* or not.

The #if 0 trick is used to uncomment easily one or several lines of code.

You could also use a more clever trick that is

#ifndef DBG
#define DBG 0 /* 0 | 1 */
#endif

<...>

#if DBG
/* code to be commented out (or not) */
#endif

Now, some compilers allows you to define a macro on the command line.

Say ...

-DDBG=1
or
-DDBG=0

.... according to your needs.

I often use this trick on embedded systems to reduce the size of some library
code when parts of it are not used.

--
-ed- em**********@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

Nov 13 '05 #8

Emmanuel Delahaye

In 'comp.lang.c', Zoran Cutura <zo**********@daimlerchrysler.com> wrote:

That's a good thing, you even can go further and use
use the symbol NDEBUG as used by the assert macro calls.
In a final/production build, -DNDEBUG is set.

I wouldn't, because obviously this code and assertions are not meant to
be included at the same time.

Actually I'ld probably never use NDEBUG in my code, because this IMHO as
an option from the standard library should only be used for the standard
library.

I don't see why. It often happens that I insert assert() in my code as design
checker, and I'm glad to have it automatically commented out at release time
(final target code). Using assert() implies an implicit use of NDEBUG.

--
-ed- em**********@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

Nov 13 '05 #9

Zoran Cutura

In comp.lang.c Emmanuel Delahaye <em**********@noos.fr> wrote:

In 'comp.lang.c', Zoran Cutura <zo**********@daimlerchrysler.com> wrote:

That's a good thing, you even can go further and use
use the symbol NDEBUG as used by the assert macro calls.
In a final/production build, -DNDEBUG is set.

I wouldn't, because obviously this code and assertions are not meant to
be included at the same time.

Actually I'ld probably never use NDEBUG in my code, because this IMHO as
an option from the standard library should only be used for the standard
library.

I don't see why. It often happens that I insert assert() in my code as design
checker, and I'm glad to have it automatically commented out at release time
(final target code). Using assert() implies an implicit use of NDEBUG.

You're talking about the implicit usage of NDEBUG? Me not. I mean I
don't do

#ifndef NDEBUG
/* code */
#endif

or

#if !defined NDEBUG
#endif

because I want to be able switch my code on or off separately from
assertions.

--
Z (Zo**********@daimlerchrysler.com)
"LISP is worth learning for the profound enlightenment experience
you will have when you finally get it; that experience will make you
a better programmer for the rest of your days." -- Eric S. Raymond

Nov 13 '05 #10

pete

Zoran Cutura wrote:

In comp.lang.c Emmanuel Delahaye <em**********@noos.fr> wrote:

Using assert() implies an implicit use of NDEBUG.

Using assert() implies a use of NDEBUG.
Using assert() is an implicit use of NDEBUG.
You're talking about the implicit usage of NDEBUG?
Me not. I mean I don't do

#ifndef NDEBUG
/* code */
#endif

or

#if !defined NDEBUG
#endif

because I want to be able switch my code on or off separately from
assertions.

I think he means that the defintition of the assert macro,
depends on the value of NDEBUG at that point in code.

Nov 13 '05 #11