Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Native mode: a runtime zero divisor or PHP_INT_MIN % -1 kills the process (SIGFPE)

Cerrado
  • ¿Algo no está bien?
#142 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
cpp, php
Área
compilers

Línea de trabajo

Start with the native-mode lowering for %, /, << and >>, comparing its runtime behavior with php::fn::intdiv() and the existing static undefined-behavior checks. Use the issue's zero-divisor, PHP_INT_MIN, and invalid-shift examples with UBSan; done means runtime cases no longer terminate the process and produce the specified PHP errors or result.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Since 0.8.0 native int storage is the default, so % and / on plain int values lower to the raw C++ operators. When the divisor is only known at runtime, PHP's catchable errors become a crash of the whole process:

<?php
function mod(int $a, int $b): int { return $a % $b; }
function main(): void
{
    try {
        var_dump(mod(5, 0));
    } catch (DivisionByZeroError $e) {
        echo $e->getMessage(), "\n";      // PHP: "Modulo by zero"
    }
}

Floating point exception (core dumped)
runtime operation (int params) PHP TypePHP native mode
$a % $b, $b = 0 DivisionByZeroError SIGFPE, process dies
$a / $b, $b = 0 DivisionByZeroError SIGFPE
PHP_INT_MIN % -1 0 SIGFPE
PHP_INT_MIN / -1 float(9.2233720368547758E+18) SIGFPE
$a << $b, $b = 64 0 1 (x86 masks the count)
$a << $b, $b = -1 ArithmeticError PHP_INT_MIN

I understand this is the documented trade-off ("Native std::int overflow and integer division behavior — Intentional Rule"), that use varint_types keeps PHP semantics, and that #45's guards were moved to varint mode on purpose in 2166e1a. The compiler already rejects all of these when they are statically detectable ("has undefined behavior in C++ native mode"), which suggests the runtime form is a gap rather than a goal. A few points that may be worth weighing now that native is the default:

  • Overflow vs. crash. Overflow and integer division change a value; these cases terminate the process, bypass try/catch, and in a server take every request with them. A zero divisor coming from input is common.
  • They are undefined behavior, not just a different result. With --sanitize undefined UBSan reports each of them (division by zero, division of -9223372036854775808 by -1 cannot be represented, shift exponent 64 is too large, shift exponent -1 is negative), so the optimizer is free to assume they never happen.
  • The guard is cheap. php::fn::intdiv() already implements exactly these checks; for %// it is one well-predicted compare on the divisor, and it can be skipped whenever the divisor is a non-zero, non--1 constant, which the compiler already knows. Shifts need one compare on the count.

Would you accept a change that keeps native storage and native arithmetic, but adds these runtime checks to %, /, << and >> (throwing the same DivisionByZeroError / ArithmeticError as PHP, and returning 0 for PHP_INT_MIN % -1)? If raw speed matters for specific code, std::int() could remain the explicit no-check opt-in, as it is today for constant divisors. Happy to implement it with benchmarks if that direction is acceptable.

Lenguaje dominante
PHP
Estrellas
1.4k
Forks
80
Merge medio
1 d 8 h
PR fusionados (30 d)
26

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de swoole/typephp

Todos los issues de swoole/typephp

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.