c++ - Is this code really undefined, as Clang seems to indicate? -

i switched on -fsanitize=undefined on project uses catch, unit testing library. 1 line catch signalled causing undefined behaviour flag. managed make isolated example:

#include <iomanip> #include <sstream>  int main() {     std::ostringstream os;      os << "0x" << std::setfill('0') << std::hex; } 

compiled with:

clang++ -fsanitize=undefined main.cpp 

if run this, following print given:

/usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2/bits/ios_base.h:96:24: runtime error: load of value 4294967221, not valid value type 'std::_ios_fmtflags' /usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2/bits/ios_base.h:76:67: runtime error: load of value 4294967221, not valid value type 'std::_ios_fmtflags' 

this happens me on clang 3.6.0 , friend clang 3.4-1ubuntu3. not happen me on gcc version 4.9.2

so here? code bad, or there fishy going on on clang's end?

this bug in libstdc++, cfe-dev mailing list thread title -fsanitize=undefined , shared libraries says:

this bug in libstdc++. able work around sanitizer blacklist file, once will's patch lands, now, filtering them out manually best option.

here's patch fix it; i'll looking pushing libstdc++ upstream in next few days. [...]

as noted dyp in comments not uncommon see systems clang uses libstdc++ opposed libc++ , if test on coliru explicitly using libstdc++ via -stdlib=libstdc++ indeed can reproduce issue.

the following libstdc++ bug report: bad enum values computed operator~ in ios_base.h covers issue , says:

the overloaded operator~s defined enumerations in ios_base.h have following form:

enum operator~(enum e) { return enum(~static_cast<int>(e)); } 

the ~ creates values outside range of values of enumeration type, cast enum type has unspecified value (see [expr.static.cast]p10), , in practice produces enum value outside range of representable values enum type, behavior undefined.

for reference [expr.static.cast]p10 says:

a value of integral or enumeration type can explicitly converted enumeration type. value unchanged if original value within range of enumeration values (7.2). otherwise, resulting value unspecified (and might not in range). value of floating-point type can converted enumeration type. resulting value same converting original value underlying type of enumeration (4.9), , subsequently enumeration type.

and hvd says formally unspecified behavior richard points out in practice ends being undefined behavior.

t.c. points out changed unspecified undefined behavior dr 1766: values outside range of values of enumeration:

although issue 1094 clarified value of expression of enumeration type might not within range of values of enumeration after conversion enumeration type (see 5.2.9 [expr.static.cast] paragraph 10), result unspecified value. should strengthened produce undefined behavior, in light of fact undefined behavior makes expression non-constant. see 9.6 [class.bit] paragraph 4.

the new wording appears in draft standard in n4431.