MantisBT - GCC-XML
View Issue Details
0007572GCC-XMLpublic2008-08-28 12:422008-08-29 10:58
Gustavo J. A. M. Carneiro 
closednot fixable 
0007572: uint32_t converted to 'unsigned int' when parsing template arguments
I have a definition like:

std::set<uint32_t> get_set ();

When looking at the return type, it is being reported (gccxml HEAD) like this:

  <Class id="_3104" name="set<unsigned int,std::less<unsigned int>,std::allocator<unsigned int> >" context="_2" incomplete="1" mangled="St3setIjSt4lessIjESaIjEE" demangled="std::set<unsigned int, std::less<unsigned int>, std::allocator<unsigned int> >" location="f133:94" file="f133" line="94" artificial="1" align="8"/>

So there is loss of information here, uint32_t is being converted to unsigned long.

I wouldn't mind too much if this was not causing a problem. But it turns out that in cygwin uint32_t is being defined as 'unsigned long' instead of 'unsigned int', and so any API definitions scanned with gccxml and code generated from them will not even compile in cygwin. I really need the original type back.
No tags attached.
Issue History
2008-08-28 12:42Gustavo J. A. M. CarneiroNew Issue
2008-08-28 12:52Gustavo J. A. M. CarneiroNote Added: 0013217
2008-08-29 09:57Brad KingNote Added: 0013232
2008-08-29 10:54Brad KingNote Added: 0013231
2008-08-29 10:58Brad KingStatusnew => closed
2008-08-29 10:58Brad KingResolutionopen => not fixable

Gustavo J. A. M. Carneiro   
2008-08-28 12:52   
Typo, when I wrote:

     So there is loss of information here, uint32_t is being converted to unsigned long.

I meant:

     So there is loss of information here, uint32_t is being converted to unsigned int.
Brad King   
2008-08-29 09:57   
FYI, the reason GCC-XML simulates native compilers is exactly so that we can avoid problems with each platform defining types differently. The original purpose of the project was for wrapping ITK ( We just do gccxml scanning separately for each compiler with which wrappers are to be generated. That way the interface information used to generate code always matches what the compiler provides. There is no such thing as a compiler-independent interface :(
Brad King   
2008-08-29 10:54   
This is a known problem, and it happens with function signatures too.

I would *love* to be able to provide the original types, but the internal GCC parser throws them out. I've complained to the GCC folks before, but I can only formulate it as a bug for them by showing error messages that don't report the user-specified types. Apparently their community has had large wars over whether messages should specify the typedef-ed types or the unwrapped types. My conclusion from discussion with them is that they won't be doing anything about it. If anyone makes a change it will start a new battle, so no one will do it.

The best part is the current behavior is inconsistent. In some cases the original types are kept and in other cases they are not. It depends on the context of the original function signature.