[pygccxml-development] uint32_t vs unsigned int, cygwin problems

[Gustavo C. <gjc...@gm...>]

I am having a problem with (py)gccxml parsing of templated types, where a
different type is being reported.

For example, here:

std::set<uint32_t> get_set ();

With this code:

        for fun in
module_namespace.free_functions(function=self.location_filter,
                                                   allow_empty=True,
recursive=False):
            if fun.name.startswith('__'):
                continue
            for dependency in fun.i_depend_on_them(recursive=False):
                type_info = dependency.depend_on_it
                traits = container_traits.find_container_traits(type_info)
                if traits is None:
                    continue
                print >> sys.stderr, "** type: %s; ---> partial_decl_string:
%r" % (type_info, type_info.partial_decl_string)

It prints:

** type: std::set<unsigned int,std::less<unsigned
int>,std::allocator<unsigned int> >; ---> partial_decl_string: '::std::set<
unsigned int >'

Yes, I know what you are thinking, it's ok, unsigned int and uint32_t are
the same type after all.  Well, usually it is, sometimes it's not.  I
received a report about generated code not compiling in cygwin, and I found
out that it's because in cygwin uint32_t is typdefed as 'unsigned long int',
instead of 'unsigned int'.  Yes, cygwin is broken, I know, but we have to
live with it :|

Is there anything that I can do to make this right?  I would like to avoid
losing the type information and keep uint32_t around instead of unsigned
int, else the generated code is not very portable.

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert