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+RH-"D-O;7!I;&EN9R!T:&ES('=I=&  1&EG:71A;"!-87)S(# N-#%N+"!O
M<'1I;VYS("UC("UM;B`M<BP-"G)E<W5L=', :6X 97)R;W)S. T*#0I$34)U
M9RYC*#0T*2`Z($5R<F]R.B!F=6YC=&EO;B`G:6YT7T=R96%T97(G(&AA<R!N
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;W(Z(&9U;F-T:6]N("=D;W5B;&5?4W5B)R!H87, ;F\ <')O=&]T>7!E#0HJ
M+PT*#0HC9&5F:6YE(&EN=%]'<F5A=&5R*&$L8BD ("` ("` *"AA*2`^("AB
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#0HC9&5F:6YE(&9L;V%T7U-U8BAX+'DI("` ("` ("` *"AX*2`M("AY*2D-
M"B-D969I;F4 9FQO871?4&]S:71I=F4H>"D ("` ("`H*' I(#X](#`N,"D-
M" T*(V1E9FEN92!D;W5B;&5?1W)E871E<BAX+'DI("` (" H>"D /B`H>2DI
M#0HC9&5F:6YE(&1O=6)L95]3=6(H>"QY*2` ("` ("` *"AX*2`M("AY*2D-
M"B-D969I;F4 9&]U8FQE7U!O<VET:79E*' I("` ("`H*' I(#X](#`N,"D-
M" T*#0HC9&5F:6YE($504TE,3TY?54Y324=.*&=R96%T97(L<W5B=')A8W0L
M82QB+&5P<RD 7`T*("` (&=R96%T97(H9W)E871E<BAA+&(I(#\ <W5B=')A
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#0H ("` *"!G<F5A=&5R*&$L8BD /R!<#0H ("` ("` ("AP;W-I=&EV92AA
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*'-U8G1R86-T*&(L82DL(&5P<RDI("D-" T*#0IU;G-I9VYE9"!C:&%R($-H
M96-K17!S:6QO;E)A;F=E*`T*=6YS:6=N960 <VAO<G0 ("!U<U1Y<&4L#0IV
M;VED("` ("` ("` ("`J('!%<'-I;&]N+`T*=F]I9"` ("` ("` ("` *B!P
M1&%T82P-"G9O:60 ("` ("` ("` ("H <$)A<V4I#0I[#0H)<W=I=&-H("AU
M<U1Y<&4I('L-" EC87-E(#$Z('L-" D)=6YS:6=N960 8VAA<B!U8T)A<V4 
M("` /2`J*'5N<VEG;F5D(&-H87( *BDH<$)A<V4I.PT*"0EU;G-I9VYE9"!C
M:&%R('5C1&%T82` ("`]("HH=6YS:6=N960 8VAA<B`J*2AP1&%T82D[#0H)
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-$
M871A+"!U8T5P<VEL;VXI.PT*"0E]#0H)8V%S92`R.B![#0H)"69L;V%T(&9"
M87-E("` (#T *BAF;&]A="`J*2AP0F%S92D[#0H)"69L;V%T(&9$871A("` 
M(#T *BAF;&]A="`J*2AP1&%T82D[#0H)"69L;V%T(&9%<'-I;&]N(#T *BAF
M;&]A="`J*2AP17!S:6QO;BD[#0H)"7)E='5R;B`H=6YS:6=N960 8VAA<BD 
M15!324Q/3E]324=.*&9L;V%T7T=R96%T97(L(&9L;V%T7U-U8BP 9FQO871?
M4&]S:71I=F4L#0H)"0EF0F%S92P 9D1A=&$L(&9%<'-I;&]N*3L-" D)?0T*
M"6-A<V4 ,SH >PT*"0ED;W5B;&4 9$)A<V4 ("` /2`J*&1O=6)L92`J*2AP
M0F%S92D[#0H)"61O=6)L92!D1&%T82` ("`]("HH9&]U8FQE("HI*'!$871A
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)
M9$)A<V4L(&1$871A+"!D17!S:6QO;BD[#0H)"7T-" ED969A=6QT. T*"0ER
1971U<FX ,#L-" E]#0I]#0IS
`
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 FOO(pred, x) BAR(pred##(x))
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