Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Chiusa
  • Qualcosa non va?
#142 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
cpp, php
Ambito
compilers

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
PHP
Stelle
1.4k
Fork
80
Merge medio
1g 9h
PR unite (30g)
25

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di swoole/typephp

Tutte le issue di swoole/typephp

Issue simili

Altre issue su PHP

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.