c++ - for - llvm 3.7 0

Diferentes comportamientos de g++ y clang++ con entrada de flujo y entero sin signo

Question

Me encontré con una diferencia en el comportamiento, entre gcc (4.9.2) y clang (3.5.0), lo que me sorprendió.

Cuando trato de alimentar un unsigned int desde un std::istringstream inicializado con un valor negativo ("-15", en el ejemplo) obtengo

• un error (con fail() bit levantado) con clang ++
• la inicialización con signed(-15) con gcc ++

Preparé el siguiente programa trivial de ejemplo.

#include <sstream>
#include <iostream>

int main ()
 {
   std::istringstream iss("-15");

   unsigned int  ui;

   iss >> ui;

   std::cout << "ui[" << ui << "] signed(ui)[" << signed(ui)
      << "] flags[" << iss.fail() << iss.good() << iss.bad()
      << iss.eof() << "]/n";

   return 0;
 }

Con clang ++, obtengo la siguiente salida

ui[0] signed(ui)[0] flags[1001]

Con g ++, obtengo la siguiente salida

ui[4294967281] signed(ui)[-15] flags[0001]

Tengo dos preguntas.

Lo primero es obvio: ¿quién tiene razón? ¿Clang ++, g ++ o es un comportamiento indefinido?

La segunda es: ¿cómo puedo forzar que gcc ++ se comporte como clang ++, dando un error al extraer un valor sin signo de una cadena que comienza con un signo menos?

Gracias y lo siento por mi mal inglés.

EDITAR 2016.04.03

Me di cuenta de que esto no es una diferencia entre g ++ y clang ++, sino una diferencia entre libstd ++ y libc ++.

Compilando y enlazando con clang ++ y libstd ++, obtengo el mismo resultado que obtengo con g ++.

Lo siento.

Answer 1

Esto se ha discutido anteriormente aquí: cadena numérica negativa (por ejemplo, "-10") a corto sin firmar

La respuesta es que de acuerdo con el estándar de C ++ 22.4.2.1.2p3, la conversión debe fallar y los almacenes de valores deben ser:

el valor representable más negativo o cero para un tipo entero sin signo , si el campo representa un valor negativo demasiado grande para ser representado en val. ios_base :: failbit se asigna a err.

Por lo tanto, clang ++ es el comportamiento correcto.