• Herbert.Oppmann siemens.com Nov 26 2004
• "Walter" <newshound digitalmars.com> Nov 26 2004
• Daniel James <daniel calamity.org.uk> Dec 08 2004
• Herbert Oppmann <Herbert_member pathlink.com> Dec 13 2004
• "Walter" <newshound digitalmars.com> Dec 15 2004

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

Thanks, I'll add it to the queue.

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

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

"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!