¿Está utilizando una buena práctica de desbordamiento de enteros sin signo?

Question

Estaba leyendo C Standard el otro día, y noté que a diferencia del desbordamiento de entero con signo (que no está definido), el desbordamiento de entero sin signo está bien definido. Lo he visto usado en una gran cantidad de códigos para máximos, etc. pero dado el vudú sobre el desbordamiento, ¿se considera esto una buena práctica de programación? ¿Está de alguna manera inseguro? Sé que muchos lenguajes modernos como Python no lo admiten, sino que continúan ampliando el tamaño de los números grandes.

Answer 1

Desbordamiento de entero sin signo (en forma de envolvente) se aprovecha de forma rutinaria en las funciones de hash, y lo ha sido desde el año dot.

Answer 2

Una forma en la que podría pensar en un desbordamiento de enteros sin signo que causa un problema es cuando se resta de un pequeño valor sin signo, lo que hace que se ajuste a un gran valor positivo.

Consejos prácticos para los desbordamientos de enteros:
http://www.gnu.org/software/hello/manual/autoconf/Integer-Overflow-Basics.html#Integer-Overflow-Basics

Answer 3

no confiaría en él sólo por razones de legibilidad. Va a depurar su código durante horas antes de averiguar dónde está restableciendo esa variable a 0.

Answer 4

Dado que los números con signo en las CPU se pueden representar de diferentes formas, el 99,999% de todas las CPU actuales usan la anotación de dos en complemento. Dado que esta es la mayoría de las máquinas que existen, es difícil encontrar un comportamiento diferente, aunque el compilador podría comprobarlo (posibilidad de grasa). Sin embargo, las especificaciones C deben representar el 100% de los compiladores, por lo que no han definido su comportamiento.

Por lo que haría las cosas más confusas, que es una buena razón para evitarlo. Sin embargo, si tiene una buena razón (por ejemplo, un aumento de rendimiento del factor de 3 para una parte crítica del código), documente bien y úselo.

Answer 5

Lo uso todo el tiempo para saber si es el momento de hacer algo.

UInt32 now = GetCurrentTime() 

if(now - then > 100) 
{ 
    // do something 
} 

Mientras se comprueba el valor antes de 'ahora' vueltas 'entonces', que están muy bien para todos los valores de 'ahora' y 'después'.

EDIT: Creo que esto es realmente un underflow.

Answer 6

Otro lugar donde desbordamiento sin firmar se puede utilizar de manera útil es cuando se tiene que recorrer hacia atrás a partir de un determinado tipo sin signo:

void DownFrom(unsigned n) 
{ 
    unsigned m; 

    for(m = n; m != (unsigned)-1; --m) 
    { 
     DoSomething(m); 
    } 
} 

Otras alternativas no son tan claras. Intentar hacer m >= 0 no funciona a menos que cambie m a signed, pero entonces podría estar truncando el valor de n - o peor - convirtiéndolo en un número negativo en la inicialización.

De lo contrario, tiene que hacer! = 0 o> 0 y luego hacer manualmente el caso 0 después del ciclo.

Answer 7

Para decirlo brevemente:

es perfectamente legal/OK/seguro de usar desbordamiento de entero sin signo como mejor le parezca, siempre y cuando se presta atención y se adhieren a la definición (para cualquier propósito - optimización, super algoritmos inteligentes, etc.)

Answer 8

Está bien confiar en el desbordamiento, siempre que sepa CUÁNDO ocurrirá ...

Yo, por ejemplo, tuve problemas con la implementación C de MD5 al migrar a un compilador más reciente ... El código esperaba desbordamiento pero también esperaba 32 bits de entrada.

¡Con 64 bits los resultados fueron incorrectos!

Afortunadamente para eso son las pruebas automatizadas: Detecté el problema temprano pero podría haber sido una verdadera historia de terror si hubiera pasado desapercibido.

Se podría argumentar "pero esto no suele suceder": sí, pero eso es lo que lo hace aún más peligroso! Cuando hay un error, todos sospechan del código escrito en los últimos días. Nadie sospecha que el código "solo funcionó durante años" y, por lo general, nadie sabe cómo funciona ...

Answer 9

El hecho de que usted conozca las minucias de la norma no significa que la persona que mantiene su código sí lo hace. Esa persona puede perder el tiempo preocupándose por esto mientras realiza la depuración más tarde, o tiene que buscar el estándar para verificar este comportamiento más adelante.

Claro, esperamos competencia con las características razonables de un lenguaje en un programador en funcionamiento, y diferentes compañías/grupos tienen una expectativa diferente sobre dónde se encuentra esa competencia razonable. Pero para la mayoría de los grupos esto parece ser demasiado esperar que la próxima persona lo sepa de la cabeza y no tenga que pensar en ello.

Si esto no fuera suficiente, es más probable encontrarse con errores de compilación cuando se trabaja alrededor de los bordes de la norma. O peor, la persona que transfiere este código a una nueva plataforma puede toparse con ellos.

En resumen, ¡voto no lo hagas!

Answer 10

Si lo usa con prudencia (bien comentado y legible), puede beneficiarse de ella por tener el código más pequeño y más rápido.

Answer 11

siukurnin hace un buen punto, que lo que necesita saber cuándo se producirán desbordamientos. La forma más fácil de evitar el problema de portabilidad que describió es usar los tipos de enteros de ancho fijo de stdint.h. uint32_t es un entero de 32 bits sin signo en todas las plataformas y sistemas operativos, y no se comportará de manera diferente cuando se compila para un sistema diferente.

Answer 12

Yo sugeriría tener siempre una conversión explícita cualquier momento se va a confiar en los números sin signo de envolver. De lo contrario, puede haber sorpresas. Por ejemplo, si "int" es de 64 bits, un código como:

UInt32 foo,bar; 
if ((foo-bar) < 100) // Report if foo is between bar and bar+99, inclusive) 
    ... do something 

puede fallar, ya que "foo" y "bar" se consiguen promovidos a enteros con signo de 64 bits. Agregar un typecast a UInt32 antes de verificar el resultado contra 100 evitaría problemas en ese caso.

Incidentalmente, creo que la única forma portátil de obtener directamente los 32 bits inferiores del producto de dos UInt32 es lanzar uno de los ints a un UInt64 antes de hacer el multiplicador. De lo contrario, el UInt32 podría convertirse a int64s firmados, con la multiplicación desbordante y produciendo resultados indefinidos.