[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