http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52538
Bug #: 52538
Summary: Extend C++11 UDLs to be compatible with inttypes.h
macros
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
C++11 defines user-defined literals in a way that breaks compatibility with
some code that uses the formatting macros from <inttypes.h>:
$ cat test.cc
#define __STDC_FORMAT_MACROS
#include <inttypes.h>
#include <stdio.h>
int main() {
int64_t i64 = 123;
printf("My int64: %"PRId64"\n", i64);
}
$ install_gcc46/bin/g++ -Wall test.cc -o test && ./test
My int64: 123
$ install_gcc46/bin/g++ -std=c++0x -Wall test.cc -o test && ./test
My int64: 123
$ install_gcc47/bin/g++-4.7pre -Wall test.cc -o test && ./test
My int64: 123
$ install_gcc47/bin/g++-4.7pre -Wall -Wc++11-compat test.cc -o test && ./test
My int64: 123
$ install_gcc47/bin/g++-4.7pre -std=c++0x -Wall test.cc -o test && ./test
test.cc: In function ‘int main()’:
test.cc:7:29: error: unable to find string literal operator ‘operator"" PRId64’
Clang is working around this by interpreting literal suffixes that don't start
with underscores as separate tokens, which allows them to expand as macros:
http://llvm.org/viewvc/llvm-project?view=rev&revision=152287
According to [lex.ext]p10 and [usrlit.suffix], these suffixes are ill-formed,
no diagnostic required, so allowing them to expand as macros is a conforming
extension.
It would also be possible to fix the code by inserting a space between the "
and the macro name, but in Google's codebase, this cleanup would be 3-4x as
large as the narrowing conversion cleanup, which you have already made
optional.
