This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/55254] New: Warn for implicit conversion from int to char
- From: "david at doublewise dot net" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 09 Nov 2012 18:28:57 +0000
- Subject: [Bug c++/55254] New: Warn for implicit conversion from int to char
- Auto-submitted: auto-generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55254
Bug #: 55254
Summary: Warn for implicit conversion from int to char
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: david@doublewise.net
I sometimes want to construct a string with n copies of a char c. However, I
frequently get the order of elements in the constructor mixed up. Rather than
saying std::string(80, '='), I accidentally call std::string('=', 80).
To me, it seems like the underlying issue here is that gcc does not warn for
implicit conversion from int to char. Whenever I assign a literal to a char, I
always assign something wrapped in single quotes, never an integer literal.
However, I would suggest that perhaps this warning should have two levels. The
first level would only warn for char. The second level would warn for char,
signed char, and unsigned char. The reason for this separation is that int8_t
is a typedef for signed char and uint8_t is a typedef for unsigned char (on
most platforms), and those are regularly used as "small integers" (I use them
extensively in space-sensitive code). My experience is that when people use a
signed / unsigned char explicitly, or one of the typedefs in cstdint /
stdint.h, they are not used as actual characters, but bytes / small numbers,
and in that case, assigning from an integer wouldn't be incorrect.