[Bug c++/59945] New: "uint" typedef is visible with "g++ -std=c++11 -pedantic"
Keith.S.Thompson at gmail dot com
gcc-bugzilla@gcc.gnu.org
Sat Jan 25 22:42:00 GMT 2014
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59945
Bug ID: 59945
Summary: "uint" typedef is visible with "g++ -std=c++11
-pedantic"
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Keith.S.Thompson at gmail dot com
If a C++ program includes a standard header (I use <string.h> in my example), a
typedef
typedef unsigned int uint;
becomes visible. The identifier does not appear in the 2011 ISO C++ standard.
The problem occurs with "g++ -std=c++11 -pedantic". It does not occur with "g++
-std=c++03 -pedantic".
To demonstrate:
$ cat uint_bug.cpp
#include <string>
int uint;
int main() { }
$ g++ --version
g++ (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ g++ -std=c++03 -pedantic -c uint_bug.cpp
$ g++ -std=c++11 -pedantic -c uint_bug.cpp
uint_bug.cpp:2:5: error: ‘int uint’ redeclared as different kind of symbol
In file included from /usr/include/stdlib.h:320:0,
from /usr/include/c++/4.7/cstdlib:66,
from /usr/include/c++/4.7/ext/string_conversions.h:37,
from /usr/include/c++/4.7/bits/basic_string.h:2814,
from /usr/include/c++/4.7/string:54,
from uint_bug.cpp:1:
/usr/include/x86_64-linux-gnu/sys/types.h:153:22: error: previous
declaration of ‘typedef unsigned int uint’
$
Running "g++ -std=c++11 -E uint_bug.cpp" shows that the declaration "typedef
int uint;", along with similar declarations for "ushort" and "ulong", appears
in /usr/include/x86_64-linux-gnu/sys/types.h. Apparently the macro __USE_MISC
is defined. (The same macro appears to be defined with "-std=c++03", but the
problem doesn't occur with that option; I haven't figured out why.)
I'm not sure whether the bug is in the compiler or in the libc headers.
(The same problem occurs with clang++ version 3.4.)
More information about the Gcc-bugs
mailing list