www.digitalmars.com Home | Search | C & C++ | D | DMDScript | News Groups | index | prev | next
Archives

D Programming
D
D.gnu
digitalmars.D
digitalmars.D.bugs
digitalmars.D.dtl
digitalmars.D.dwt
digitalmars.D.announce
digitalmars.D.learn
digitalmars.D.debugger

C/C++ Programming
c++
c++.announce
c++.atl
c++.beta
c++.chat
c++.command-line
c++.dos
c++.dos.16-bits
c++.dos.32-bits
c++.idde
c++.mfc
c++.rtl
c++.stl
c++.stl.hp
c++.stl.port
c++.stl.sgi
c++.stlsoft
c++.windows
c++.windows.16-bits
c++.windows.32-bits
c++.wxwindows

digitalmars.empire
digitalmars.DMDScript

c++ - Preprocessor bug? - DMBug.c

↑ ↓ ← 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
Nov 26 2004
→ "Walter" <newshound digitalmars.com> writes:
Thanks, I'll add it to the queue.
Nov 26 2004
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
↑ ↓ 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
↑ ↓ → "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

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

 problem being fixed in the compiler.

 BTW, are there plans for a new release?

Yes, there are!
Dec 15 2004