www.digitalmars.com         C & C++   DMDScript  

c++ - Preprocessor bug? - DMBug.c

reply Herbert.Oppmann siemens.com writes:
It's my first message here, I hope I've choosen the right group.

We have a big portable source code package written in C (ANSI C 1990) here.
To find out portability issues before our customers have to, I ported it to
several compilers, including Digital Mars. I ran into a problem, and spend
several hours now to isolate it and make a small example source file (attached).

I'm using the command line version of Digital Mars 8.41n on a Windows XP
machine.
Compiling the attached file with options -c -mn -r leads to the errors "function
'xxx' has no prototype" for 'int_Greater', 'float_Sub', 'double_Sub'.

It seems this is a problem with the preprocessor. Replacing option -r with -e
and -lDMBug.lst shows that the preprocessor correctly replaces the macro
EPSILON_UNSIGN and EPSILON_SIGN respectively, but it has problems doing further
macro replacements on the resulting string. In the case of EPSILON_UNSIGN, no
further replacement takes place, while on EPSILON_SIGN, xxx_Greater and
xxx_Positive are replaced but not xxx_Sub ?!?

I have to admit that this code is tricky. But according to my understanding of
the ANSI C standard, this should be legal. Also, all the other compilers
processed that code without problems.

Thanks in advance for your efforts

Dipl-Inf. Herbert Oppmann
Siemens AG, Automation & Drives
Nürnberg, Germany
begin 0644 DMBug.c



M;R!P<F]T;W1Y<&4-"D1-0G5G+F,H-3(I(#H 17)R;W(Z(&9U;F-T:6]N("=F
M;&]A=%]3=6(G(&AA<R!N;R!P<F]T;W1Y<&4-"D1-0G5G+F,H-3DI(#H 17)R


M*2D-"B-D969I;F4 :6YT7U-U8BAA+&(I("` ("` ("` ("`H*&$I("T *&(I
M*0T*(V1E9FEN92!I;G1?4&]S:71I=F4H82D ("` ("` (" H82D /CT ,"D-
M" T*(V1E9FEN92!F;&]A=%]'<F5A=&5R*' L>2D ("` (" H>"D /B`H>2DI

M"B-D969I;F4 9FQO871?4&]S:71I=F4H>"D ("` ("`H*' I(#X
M" T*(V1E9FEN92!D;W5B;&5?1W)E871E<BAX+'DI("` (" H>"D /B`H>2DI

M"B-D969I;F4 9&]U8FQE7U!O<VET:79E*' I("` ("`H*' I(#X


M8W0H82QB*2`Z('-U8G1R86-T*&(L82DL(&5P<RD-" T*(V1E9FEN92!%4%-)
M3$].7U-)1TXH9W)E871E<BQS=6)T<F%C="QP;W-I=&EV92QA+&(L97!S*2!<

M*2`_(&=R96%T97(H<W5B=')A8W0H82QE<',I+"!B*2`Z(&=R96%T97(H<W5B
M=')A8W0H82QB*2P 97!S*2D 7`T*("` (#H 7`T*("` ("` ("`H<&]S:71I
M=F4H8BD /R!G<F5A=&5R*'-U8G1R86-T*&(L97!S*2P 82D .B!G<F5A=&5R


M;VED("` ("` ("` ("`J('!%<'-I;&]N+`T*=F]I9"` ("` ("` ("` *B!P


M("` /2`J*'5N<VEG;F5D(&-H87( *BDH<$)A<V4I.PT*"0EU;G-I9VYE9"!C

M"75N<VEG;F5D(&-H87( =6-%<'-I;&]N(#T *BAU;G-I9VYE9"!C:&%R("HI
M*'!%<'-I;&]N*3L-" D)<F5T=7)N("AU;G-I9VYE9"!C:&%R*2!%4%-)3$].
M7U5.4TE'3BAI;G1?1W)E871E<BP :6YT7U-U8BP-" D)"75C0F%S92P =6-$

M87-E("` (#T
M(#T

M15!324Q/3E]324=.*&9L;V%T7T=R96%T97(L(&9L;V%T7U-U8BP 9FQO871?

M"6-A<V4 ,SH >PT*"0ED;W5B;&4 9$)A<V4 ("` /2`J*&1O=6)L92`J*2AP

M*3L-" D)9&]U8FQE(&1%<'-I;&]N(#T *BAD;W5B;&4 *BDH<$5P<VEL;VXI
M.PT*"0ER971U<FX *'5N<VEG;F5D(&-H87(I($504TE,3TY?4TE'3BAD;W5B
M;&5?1W)E871E<BP 9&]U8FQE7U-U8BP 9&]U8FQE7U!O<VET:79E+`T*"0D)

1971U<FX ,#L-
`
end
Nov 26 2004
next sibling parent "Walter" <newshound digitalmars.com> writes:
Thanks, I'll add it to the queue.
Nov 26 2004
prev sibling parent reply Daniel James <daniel calamity.org.uk> writes:
Herbert.Oppmann siemens.com wrote:

 It seems this is a problem with the preprocessor. Replacing option -r with -e
 and -lDMBug.lst shows that the preprocessor correctly replaces the macro
 EPSILON_UNSIGN and EPSILON_SIGN respectively, but it has problems doing further
 macro replacements on the resulting string. In the case of EPSILON_UNSIGN, no
 further replacement takes place, while on EPSILON_SIGN, xxx_Greater and
 xxx_Positive are replaced but not xxx_Sub ?!?


Sorry, that this reply is very late, I've only just checked this list 
for the first time in a while. It might be too late to help you, but I 
came across the same bug a while ago, and found a few work arounds. I 
wrote the following about it:


 ...in a statement like this:

    #define FOO(pred, x) BAR(pred(x))

 pred(x) won't get expanded. There are several ways to work around
 this, the one I've mostly used is to write:

    #define


This is the easiest way to work around the bug, but it's not standard 
and won't work on a lot of compilers - if you do this you'll have to use 
a '#ifdef __DMC__'/'#else' to provide 2 implementations.


 You can also use:

    #define CALL(pred, x) pred(x)
    #define FOO(pred, x) BAR(CALL(pred, x))


This one will work on other compilers, but is awkward.


 And, with the patch [added to boost]:

    #define FOO(pred, x) BAR(BOOST_PP_EXPAND(pred(x)))


The patch to do this was added to boost v1.32. Boost is mostly C++, but 
the preprocessor library will work for C.

The full post is at:

http://lists.boost.org/MailArchives/boost/msg68726.php

Daniel
Dec 08 2004
parent reply Herbert Oppmann <Herbert_member pathlink.com> writes:
In article <cp6jor$1daf$1 digitaldaemon.com>, Daniel James says...


It might be too late to help you, but I 
came across the same bug a while ago, and found a few work arounds.


Daniel, thanks a lot for your suggestions. 
Unfortunately, I won't use them, but it will help other users reading this
forum.

The Digital Mars compiler is not one of our targets and I only used it to find
out portability issues. Inserting compiler specific #ifdefs into the core
sources violates our style guide and is only the last option. I can wait for the
problem being fixed in the compiler.

BTW, are there plans for a new release?

Dipl-Inf. Herbert Oppmann
Siemens AG, Automation & Drives
Nürnberg, Germany
Dec 13 2004
parent "Walter" <newshound digitalmars.com> writes:
"Herbert Oppmann" <Herbert_member pathlink.com> wrote in message
news:cpjpi0$1aes$1 digitaldaemon.com...

 Daniel, thanks a lot for your suggestions.
 Unfortunately, I won't use them, but it will help other users reading this
 forum.

 The Digital Mars compiler is not one of our targets and I only used it to


find

 out portability issues. Inserting compiler specific #ifdefs into the core
 sources violates our style guide and is only the last option. I can wait


for the

 problem being fixed in the compiler.

 BTW, are there plans for a new release?


Yes, there are!
Dec 15 2004