Inconsistent preprocessor output

Inconsistent preprocessor output

Post by Arpit » Sat, 30 Sep 2006 17:34:34


I am using a set of static libraries which are linked to form an
executable file.
In a header file of one archive, say x.a, a macro LRC is defined
conditionally (macro controlled again) to different values

//abc.h (goes into x.a)-------------

#if (MACRO1 == TRUE)
#define LRC 10
#endif

#if(MACRO2 == TRUE)
#define LRC 20
#endif

//--------------------------------------------

That macro is being referenced in another archive, say y.a.

What I find is, the value subsitued for the macro is x.a and y.a are
different, in x.a, the macro is substitued as 10, and in b, as 20.

How is this possible?
I understand that a symbol table per archive is constructed, and is
used across.
Also, how can I solve this problem.
Thanks for any help

~A
--
comp.lang.c.moderated - moderation address: XXXX@XXXXX.COM -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
 
 
 

Inconsistent preprocessor output

Post by Hans-Bernh » Thu, 05 Oct 2006 06:44:26


By lack of proper discipline on the side of whoever built those
archives.


But a macro isn't a symbol.

--
Hans-Bernhard Broeker ( XXXX@XXXXX.COM )
Even if all the snow were burnt, ashes would remain.
--
comp.lang.c.moderated - moderation address: XXXX@XXXXX.COM -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

 
 
 

Inconsistent preprocessor output

Post by Michael Ti » Thu, 05 Oct 2006 06:44:28


The value of a macro is not inserted into symbol table, it's only
used in expressions during compilation. If the same macro is defined
differently in different .c files, you have a problem.


One solution is to use the same macro definitions and the same .h
files for all compilations that will be a part of the same executable
(this includes dynamically linked libraries).

The 2nd solution is to define the value as a global variable.

-- abc,h

extern int Lrc;

-- yxz.c

#if (MACRO1 == TRUE)
#define LRC 10
#else
#if(MACRO2 == TRUE)
#define LRC 20
#else
#error wrong value of "MACRO1/2" ...
#endif
#endif

int Lrc = LRC;
------------------

Michael
--
comp.lang.c.moderated - moderation address: XXXX@XXXXX.COM -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
 
 
 

Inconsistent preprocessor output

Post by jgd » Thu, 05 Oct 2006 06:44:29

In article < XXXX@XXXXX.COM >, XXXX@XXXXX.COM



Very easily.


Unfortunately, you understand incorrectly.

Macro values are used at compile time: the point at which a .o file is
generated from a .c file and any other .c and/or .h files it happens to
#include. At the point of formation of the .o file, the macro has its
value and is used in creating the .o file. But the macro's name and
value do not automatically survive as a symbol in the object file,
unless you use it in some way that would imply that happening. Macros
are strictly a compile-time phenomon.

Now, different .o files can have different values for your LRC macro at
compile time, if the values for MACRO1 and MACRO2 happen to be different
when they are compiled. And if .o files with different values of a macro
go into the same .a archive library, that's fine; the archiver doesn't
complain at all. The only symbols which go into an archive's symbol
table are those that are meant to be visible from outside the .o file:
functions and global variables that aren't "static".

So a macro "having different values" in different archive libraries
isn't at all surprising. Your real problem is probably that the macros
in your collection of source file are giving your LRC macro different
values under circumstances where the value should be the same.

---
John Dallman, XXXX@XXXXX.COM , HTML mail is treated as probable spam.
--
comp.lang.c.moderated - moderation address: XXXX@XXXXX.COM -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
 
 
 

Inconsistent preprocessor output

Post by gordonb.uv » Thu, 05 Oct 2006 06:44:29

>I am using a set of static libraries which are linked to form an

The scope of a macro starts at the definition of the macro and ends
at the point where it is undefined with #undef or the end of the
compilation unit. It has nothing to do with an "archive" (whatever
that is. If, after compiling a bunch of compilation units, you
smoosh a bunch of compiled object files into one "library" file,
that does nothing whatever to macros).


If multiple compilation units include abc.h, and the values of MACRO1
and/or MACRO2 are different, the value of LRC may end up being different.


Macros are referenced in compilation units made of source code, not
"archives".


When you compile, are the values of MACRO1 and MACRO2 different?
If so, what did you expect?


Macros in different compilation units (roughly "source and header files
used in a single compilation") are completely unrelated.


A symbol table exists *PER COMPILATION UNIT*. From the point of view
of macros, "archives" don't exist.


You have not stated a problem. (2+2=4. How can I fix this?)
--
comp.lang.c.moderated - moderation address: XXXX@XXXXX.COM -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
 
 
 

Inconsistent preprocessor output

Post by Thad Smit » Thu, 05 Oct 2006 06:44:30


What do you mean by archive, as it relates to C programming?


What is the actual or potential source of the definition of MACRO1 and
MACRO2? If the source module in "archive" y.a includes the same abc.h
used in "archive" x.a then MACRO1 and MACRO2 must have been defined
differently, possibly by command line parameter or a source file
definition preceding inclusion of abc.h.

--
Thad
--
comp.lang.c.moderated - moderation address: XXXX@XXXXX.COM -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
 
 
 

Inconsistent preprocessor output

Post by Jack Klei » Thu, 05 Oct 2006 06:44:31

On 29 Sep 2006 08:34:34 GMT, "Arpita" < XXXX@XXXXX.COM > wrote
in comp.lang.c.moderated:


A macro is not referenced in an archive, it is expanded in a
translation unit, basically a source file and anything the source file
includes.


Macros do not exist in compiled code. Whatever results from their
expansion does, in one way or another, if they are expanded.


What you have written so far would not create anything in a library at
all. Show us how these macros are used, in what context are they
expanded?

If this set of macros expands to 10 in one source file and to 20 in
another, I would expect because that MACRO1 is TRUE and MACRO2 is not
TRUE in one file when the macros are read, and exactly the opposite
condition exists in the other source file.


--
Jack Klein
Home: http://www.yqcomputer.com/
FAQs for
comp.lang.c http://www.yqcomputer.com/
comp.lang.c++ http://www.yqcomputer.com/ ++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.yqcomputer.com/ ~ajo/docs/FAQ-acllc.html
--
comp.lang.c.moderated - moderation address: XXXX@XXXXX.COM -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.