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