[GCC-XML] Strange behaviour with hexadecimal numbers

Roman Yakovenko roman.yakovenko at gmail.com
Thu May 11 08:01:39 EDT 2006


Hi. Now when I know how to debug and/or modify xml.c file ....
I decided to fix the bug I reported. The short story is that I don't
understand how
to read variables that has type "tree". As for me it is very difficult
to find out what is a real
( == derived ) type of the variable. So I did not succeeded. :-(.

The long story is that I found work around.
Consider next use case:

template< unsigned long i1, unsigned long i2, unsigned long i3>
struct item_t{
    static const unsigned long v1 = i1;
    static const unsigned long v2 = i2;
    static const unsigned long v3 = i3;
};

struct buggy{
    typedef unsigned long ulong;
    typedef item_t< ulong( 0xDEECE66DUL ) | (ulong(0x5) << 32), 0xB,
ulong(1) << 31 >
                my_item_t;
    my_item_t my_item_var;
};


Right now gccxml reports my_item_t type as

"item_t<0deece66d,11,080000000>"

Obviously the reported name is wrong. But if we will take a look on
demangled string
we will see

item_t<3740067437l, 11l, 2147483648l>

This is valid C++ class name and it is correct.

Just wanted to share this work around.

Enjoy.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/



More information about the gccxml mailing list