Estoy depurando un código de producción escrito en C y su forma más simple se puede mostrar como:
void test_fun(int sr) { int hr = 0; #define ME 65535 #define SE 256 sr = sr/SE; <-- This should yield 0 if(sr == 1) hr = ME; else hr = (ME+1)/sr; <-- We should crash here. } Estamos pasando sr como 128, lo que idealmente debería producir un error de división por cero en el procesador. Veo que esta división ocurre con éxito con un cociente como 0x7ffffffff ( hr es este valor). Esto no sucede (se bloquea cuando intenta la división por cero) cuando compilo y ejecuto lo mismo en la plataforma Intel con gcc.
Quiero saber el principio detrás de este gran cociente. No estoy seguro si es solo otro error que aún necesito descubrir. Alguien me puede ayudar con otro programa que haga lo mismo?
La división por cero es un comportamiento indefinido , consulte el estándar C11 6.5.5#5 (borrador final).
Obtener una trampa o SIGFPE es solo una cortesía de la CPU/SO. PowerPC como CPU RISC típica no lo detecta, ya que puede detectarse con seguridad mediante una simple comprobación del divisor justo antes de realizar la división real. x86 OTOH capta esto: comportamiento típico de CISC.
Si lo requiere un estándar de capa superior, probablemente haya perdido una opción del compilador que emite esta verificación automáticamente. POSIX, por ejemplo, no aplica SIGFPE, esto es opcional.
Según el manual de arquitectura de PPC (que puede obtener de IBM ), dividir por 0 en un PPC no da como resultado ningún tipo de señal o trampa; en cambio, solo obtiene un valor indefinido que varía de un procesador a otro. En su caso, parece que la variante PPC particular que tiene genera MAXINT (entero positivo más grande) al dividir un número positivo por 0.