DEFAULT_PLUGIN_PATH shouldn't be stringified by two levels of macro

[GoogleCodeExporter]

If DEFAULT_PLUGIN_PATH contains other macro names, 
TOSTRING(DEFAULT_PLUGIN_PATH) at 
https://code.google.com/p/edb-debugger/source/browse/trunk/src/Configuration.cpp
#60 will produce wrong result.

For example，DEFAULT_PLUGIN_PATH=/usr/lib/x86_64-linux-gnu/edb, 
TOSTRING(DEFAULT_PLUGIN_PATH) will produce "/usr/lib/x86_64-1-gnu/edb", not 
"/usr/lib/x86_64-linux-gnu/edb".
This is because the word "linux" is defined at another place:
$ cpp -dM < /dev/null | grep linux
#define __linux 1
#define __linux__ 1
#define __gnu_linux__ 1
#define linux 1

Original issue reported on code.google.com by xuzhen...@gmail.com on 2 Aug 2014 at 8:03

[GoogleCodeExporter]

So, unfortunately I cannot reproduce this issue on my linux machine. What 
compiler are you using? And what version?

Also, the code isn't really doing two levels of stringification. The way it (is 
intended) to work is like this:

Using the following qmake command

    qmake -makefile DEFAULT_PLUGIN_PATH="/usr/lib/x86_64-linux-gnu/edb"

the following code

    TOSTRING(DEFAULT_PLUGIN_PATH);

will resolve to:

    STRINGIFY(/usr/lib/x86_64-linux-gnu/edb)

which will in turn resolve to:

    #/usr/lib/x86_64-linux-gnu/edb

which of course becomes

    "/usr/lib/x86_64-linux-gnu/edb"

Finally, when I try to replicate your result, and then runs strings on the 
resultant binary I see this:

    $ strings .release-shared/obj/Configuration.o
        ...
        /usr/lib/x86_64-linux-gnu/edb
        ...

Are you sure that what you are reporting is the actual problem?

Original comment by evan.teran on 12 Aug 2014 at 2:06

• Changed state: Invalid

[GoogleCodeExporter]

strange. this is what I got
$ strings edb | grep /usr/lib
/usr/lib/x86_64-1-gnu/edb

I made a simplified test program
$ cat a.cpp
#include <iostream>
#define aaa 1
#define STRINGIFY(x) #x
#define TOSTRING(x) STRINGIFY(x)
int main() {
    std::cout << TOSTRING(x-aaa-x) << std::endl;
    return 0;
}
$ g++ a.cpp
$ ./a.out

It also outputs x-1-x, not x-aaa-x on my system

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.9.1-6ubuntu1' 
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs 
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-4.9 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls 
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify 
--enable-plugin --with-system-zlib --disable-browser-plugin 
--enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home 
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib 
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.1 (Ubuntu 4.9.1-6ubuntu1)

Original comment by xuzhen...@gmail.com on 17 Aug 2014 at 5:16

[GoogleCodeExporter]

also tested on ubuntu 14.04 with g++ version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
got same result.

Original comment by xuzhen...@gmail.com on 17 Aug 2014 at 5:20

[GoogleCodeExporter]

The gcc docment https://gcc.gnu.org/onlinedocs/cpp/Argument-Prescan.html said:
"Macro arguments are completely macro-expanded before they are substituted into 
a macro body, unless they are stringified or pasted with other tokens."

therefore,
TOSTRING(DEFAULT_PLUGIN_PATH);
will be completely expanded to
TOSTRING(/usr/lib/x86_64-1-gnu/edb);
before the expansion of TOSTRING macro.

Original comment by xuzhen...@gmail.com on 17 Aug 2014 at 5:54

[GoogleCodeExporter]

Interesting, but I think that places the issue outside of edb's scope. If the 
macro is expanded to replace "linux" with "1" even before the TOSTRING macro is 
called, not much I can do about it :-(.

Original comment by evan.teran on 22 Aug 2014 at 1:44