¿La razón por la que Bash Shell no le advierte sobre el desbordamiento aritmético, etc.?

La evaluación se realiza en números enteros de ancho fijo sin verificación de desbordamiento,
aunque la división por 0 queda atrapada y marcada como un error. Los operadores
y su precedencia, asociatividad y valores son los mismos que en el
lenguaje C.

A qué entero de ancho fijo se refiere realmente se trata de qué tipo de datos se utiliza (y los detalles de por qué esto es más allá de esto) pero el valor límite se expresa en /usr/include/limits.h de esta manera:

#  if __WORDSIZE == 64
#   define ULONG_MAX     18446744073709551615UL
#  ifdef __USE_ISOC99
#  define LLONG_MAX       9223372036854775807LL
#  define ULLONG_MAX    18446744073709551615ULL

Y una vez que sepa eso, puede confirmar este estado de hecho así:

# getconf -a | grep 'long'
LONG_BIT                           64
ULONG_MAX                          18446744073709551615

Este es un entero de 64 bits y esto se traduce directamente en el shell en el contexto de la evaluación aritmética:

# echo $(((2**63)-1)); echo $((2**63)); echo $(((2**63)+1)); echo $((2**64))
9223372036854775807        //the practical usable limit for your everyday use
-9223372036854775808       //you're that much "away" from 2^64
-9223372036854775807     
0
# echo $((9223372036854775808+9223372036854775807))
-1

Entonces, entre 2 y 2-1, obtiene números enteros negativos que le muestran qué tan lejos está de ULONG_MAX. Cuando la evaluación alcanza ese límite y se desborda, en el orden que sea, no recibe ninguna advertencia y esa parte de la evaluación se restablece a 0, lo que puede generar un comportamiento inusual con algo como asociación derecha exponenciación por ejemplo:

echo $((6**6**6))                      0   // 6^46656 overflows to 0
echo $((6**6**6**6))                   1   // 6^(6^46656) = 6^0 = 1
echo $((6**6**6**6**6))                6   // 6^(6(6^46656)) = 6^(6^0) = 6^1
echo $((6**6**6**6**6**6))         46656   // 6^(6^(6^(6^46656))) = 6^6
echo $((6**6**6**6**6**6**6))          0   // = 6^6^6^1 = 0
...

Usando sh -c 'command' no cambia nada, así que debo suponer que se trata de un resultado normal y compatible. Ahora que creo que tengo una comprensión básica pero concreta del rango y límite aritmético y lo que significa en el shell para la evaluación de expresiones, pensé que podría echar un vistazo rápidamente a los tipos de datos que usa el otro software en Linux. Usé algo de bash fuentes tuve que complementar la entrada de este comando:

{ shopt -s globstar; for i in /path/to/source_bash-4.2/include/**/*.h /usr/include/**/*.h; do grep -HE 'b(([UL])|(UL)|())LONG|bFLOAT|bDOUBLE|bINT' $i; done; } | grep -iE 'bash.*max'

bash-4.2/include/typemax.h:#    define LLONG_MAX   TYPE_MAXIMUM(long long int)
bash-4.2/include/typemax.h:#    define ULLONG_MAX  TYPE_MAXIMUM(unsigned long long int)
bash-4.2/include/typemax.h:#    define INT_MAX     TYPE_MAXIMUM(int)

Hay más resultados con if declaraciones y puedo buscar un comando como awk también, etc. Me doy cuenta de que la expresión regular que utilicé no capta nada sobre las herramientas de precisión arbitrarias que tengo, como bc y dc .

Preguntas

1. ¿Cuál es la razón para no advertirle (como awk hace al evaluar 2^1024) cuando su evaluación aritmética se desborda? ¿Por qué los números enteros negativos entre 2 y 2-1 están expuestos al usuario final cuando está evaluando algo?
2. He leído en alguna parte que algún tipo de UNIX puede cambiar ULONG_MAX de forma interactiva. ¿Alguien ha oído hablar de esto?
3. Si alguien cambia arbitrariamente el valor del número máximo de enteros sin signo en limits.h , luego vuelve a compilar bash , ¿qué podemos esperar que suceda?

Respuesta aceptada:

> max=$((2**63 - 1)); echo $max
9223372036854775807

> echo $(($max + 1))
-9223372036854775808

> echo $(($max + 1 + $max))
-1

> echo $(($max + 2 + $max))
0

11111111 11111110