Theoretical issue in frankenphp_init_persistent_string()

[nielsdos]

What happened?

The Zend engine has the implicit assumption that interned strings have their hash value already computed.
This is because interned strings live in a hashtable and therefore necessarily have a precomputed hash.
The strings created by frankenphp_init_persistent_string() don't precompute their hash. So if they ever end up (indirectly) into the VM or into some Zend APIs, this will cause issues. One good example of an API where this'll go wrong is zend_hash_append which just takes the hash value without checking if it had been set.
I don't know if this issue can manifest for real in your use cases, I took a brief look at the Go code but it's inconclusive for me. Just wanted to bring this up.

Build Type

Docker (Debian Bookworm)

Worker Mode

No

Operating System

GNU/Linux

CPU Architecture

x86_64

PHP configuration

Not relevant

Relevant log output

No response

[AlliBalliBaba]

These strings are right now only used for known $_SERVER keys and all pass through zend_hash_update_ind where the hash is computed. But you're making a good point, it might be a trap if we ever decide to use these persistent strings elsewhere in the future.