|
Mantis - GCC-XML
|
|
Viewing Issue Advanced Details |
|
|
ID:
|
Category:
|
Severity:
|
Reproducibility:
|
Date Submitted:
|
Last Update:
|
|
7572 |
|
major |
always |
2008-08-28 12:42 |
2008-08-29 10:58 |
|
|
Reporter:
|
Gustavo J. A. M. Carneiro |
Platform:
|
|
|
|
Assigned To:
|
|
OS:
|
|
|
|
Priority:
|
normal |
OS Version:
|
|
|
|
Status:
|
closed |
Product Version:
|
|
|
|
Product Build:
|
|
Resolution:
|
not fixable |
|
|
Projection:
|
none |
|
|
|
|
ETA:
|
none |
Fixed in Version:
|
|
|
|
|
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.
|
|
Steps To Reproduce:
|
|
|
Additional Information:
|
|
| Relationships | |
|
Attached Files:
|
|
|
|
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 |
|
Notes |
|
|
(0013217)
|
|
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. |
|
|
|
(0013232)
|
|
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 (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
|
|
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. |
|