Mantis Bugtracker
Main | My View | View Issues | Change Log | Roadmap | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ View Advanced ] [ Issue History ] [ Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0007572 [GCC-XML] major always 2008-08-28 12:42 2008-08-29 10:58
Reporter Gustavo J. A. M. Carneiro View Status public  
Assigned To
Priority normal Resolution not fixable  
Status closed  
Summary 0007572: uint32_t converted to 'unsigned int' when parsing template arguments
Description 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.
Additional Information
Tags No tags attached.
Attached Files

- Relationships [ Relation Graph ] [ Dependency Graph ]

-  Notes
(0013217)
Gustavo J. A. M. Carneiro (reporter)
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.
(0013232)
Brad King (manager)
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 (www.itk.org). 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 :(
(0013231)
Brad King (manager)
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.

- Issue History
Date Modified Username Field Change
2008-08-28 12:42 Gustavo J. A. M. Carneiro New Issue
2008-08-28 12:52 Gustavo J. A. M. Carneiro Note Added: 0013217
2008-08-29 09:57 Brad King Note Added: 0013232
2008-08-29 10:54 Brad King Note Added: 0013231
2008-08-29 10:58 Brad King Status new => closed
2008-08-29 10:58 Brad King Resolution open => not fixable

Mantis 1.1.4[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker