Skip to content

Replace hardcoded strcmp(sapi_module.name, "cli") SAPI checks with a capability flag #168

Description

@EdmondDantes

Background

For the static-php-cli based binaries (#156) we ship a phpmicro (micro.sfx) SAPI so end users can bundle their index.php into a single self-executable file. The micro SAPI name is not "cli", so PHP core's many hardcoded checks like:

strcmp(sapi_module.name, "cli") == 0

treat micro as a web SAPI and break CLI behavior (php://stdin/stdout/stderr, opcache enablement, pcre per-request cache, display_errors mode, etc.).

Today this is worked around with static-php-cli's cli_checks patch, which mechanically appends || strcmp(sapi_module.name, "micro") == 0 to every such site across the tree (main/main.c, ext/opcache/ZendAccelerator.c, ext/pcre/php_pcre.c, ext/sqlite3, ext/ffi, ext/standard/php_fopen_wrapper.c, ext/readline, win32, ...).

This is brittle: every PHP version drifts the surrounding code and the patch has to be regenerated. (e.g. 8.6 moved the opcache check into a new accel_sapi_is_cli() helper.)

Proposal

Stop string-matching the SAPI name. Introduce a proper capability instead, e.g.:

  • a sapi_module.flags / is_cli_like bit set by cli, phpdbg, micro, embed, or
  • a small helper sapi_is_cli_like() used consistently across core,

so that micro (and embed, phpdbg) inherit CLI semantics without per-site strcmp hacks. Ideally upstream this so the patch can be dropped entirely.

Scope

  • This is a cleanup / hardening task, not a blocker — the cli_checks patch works.
  • Relates to the static binary distribution work in Download request for installation package #156.
  • Remove the dependency on static-php-cli's cli_checks patch once a capability-based check lands.

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request
No fields configured for Feature.

Projects

Status
Todo

Relationships

None yet

Development

No branches or pull requests

Issue actions