Los enteros en complemento a dos con solo el bit de signo activado deberían ser una representación trampa
Tratar el valor entero más bajo de complemento a dos (el patrón con solo el bit de signo activado, por ejemplo `INT_MIN`) como una trampa o un centinela similar a NaN podría hacer que los desbordamientos y los enteros opcionales sean más seguros y fáciles de manejar, pero rompería el código existente y requeriría soporte de hardware o del compilador. Los comentaristas sopesan el atractivo de los rangos simétricos y de los valores integrados para “ausente” frente a las realidades del rendimiento, la interoperabilidad FFI y décadas de software que asumen aritmética de wrap simple. Muchos sostienen que mejores herramientas (sanitizers, bigints explícitos o nuevos tipos de enteros con valores “nicho” reservados) son preferibles a redefinir la semántica central de los enteros en C, C++ y las ISA comunes.
Propuesta y motivación
- El hilo se centra en convertir el valor de complemento a dos de “solo bit de signo” (por ejemplo,
INT_MIN) en un caso especial:- O bien una representación trampa (usarlo provoca una falta/excepción).
- O bien un centinela similar a NaN para enteros “ausentes”/inválidos.
- Motivaciones discutidas:
- Rangos enteros simétricos (−N..+N en lugar de −N−1..+N).
- Representaciones más baratas de
optional<int>/ enteros nulos usando ese patrón de bits. - Eliminar casos límite como el desbordamiento de
abs(INT_MIN)en C.
Hardware, rendimiento e implementación
- Muchos sostienen que esto solo tiene sentido con soporte de hardware; las comprobaciones de software después de cada operación se consideran demasiado costosas para lenguajes de bajo nivel.
- Otros señalan que lenguajes dinámicos o de alto nivel (Python, Lisp, Swift, R) ya pagan costes similares (bignums, comprobaciones de límites, centinelas).
- Los DSP y algunas ISA admiten modos alternativos de aritmética (aritmética con saturación, banderas de desbordamiento), que podrían aprovecharse en su lugar.
Corrección, UB y semántica de lenguaje
- Hay un debate intenso sobre que el desbordamiento con signo en C/C++ sea comportamiento indefinido:
- Algunos quieren que el wrap (
-fwrapv) o los traps (-ftrapv) sean los valores predeterminados. - Otros subrayan que apoyarse en UB para optimización ha creado bugs de seguridad reales y comportamientos difíciles de depurar.
- Algunos quieren que el wrap (
- Se distingue entre:
- Una representación trampa (en C, solo leerla/escribirla ya es UB).
- Un valor tipo NaN con semántica de propagación definida.
- Varios señalan que adaptar esto retroactivamente a C rompería código existente, hoy correcto, y las expectativas de FFI.
Alternativas: bignums, saturación, centinelas
- Se discutieron alternativas:
- Enteros de precisión arbitraria como valor predeterminado (Lisp, Scheme, Python).
- Tipos de rango/intervalo donde los valores fuera de rango codifican “ausente”.
- Instrucciones de aritmética con saturación u ოპs de biblioteca.
- Tipos de nicho a nivel de lenguaje o biblioteca (no-cero, ints de 63 bits, optimización de “nicho” de Rust, ints etiquetados de OCaml, el entero NA de R).
Seguridad frente a disponibilidad
- Algunos prefieren fallar/trappear ante el desbordamiento para evitar corrupción silenciosa de datos.
- Otros, especialmente en dominios de seguridad o misión crítica, priorizan seguir operando incluso con valores erróneos antes que la muerte del proceso.
- El consenso: el comportamiento deseable depende mucho del dominio; un único valor predeterminado de hardware o de lenguaje no satisfará todos los casos de uso.