Description
I'm not sure which issue category is the best fit, so I'm filing this as a bug.
I have several static analyzer messages like SIGN_EXTENSION posix.c:[387:2].log.
clock_t is implementation-defined (size/signedness), while zend_long is platform-dependent (32-bit on 32-bit builds, 64-bit on 64-bit builds).
If a clock_t value is not representable as zend_long, conversion result is implementation-defined and may truncate / flip sign.
This seems like a portability/correctness issue, (not a security issue), and probably rare in practice.
Could somebody clarify whether this is worth fixing?
PHP Version
PHP 8.4.21 (cli) (built: May 8 2026 05:56:48) (NTS)
Copyright (c) The PHP Group
Built by Debian
Zend Engine v4.4.21, Copyright (c) Zend Technologies
with Zend OPcache v8.4.21, Copyright (c), by Zend Technologies
Operating System
Debian 13
Description
I'm not sure which issue category is the best fit, so I'm filing this as a bug.
I have several static analyzer messages like SIGN_EXTENSION posix.c:[387:2].log.
clock_tis implementation-defined (size/signedness), whilezend_longis platform-dependent (32-biton 32-bit builds,64-biton 64-bit builds).If a
clock_tvalue is not representable aszend_long, conversion result is implementation-defined and may truncate / flip sign.This seems like a portability/correctness issue, (not a security issue), and probably rare in practice.
Could somebody clarify whether this is worth fixing?
PHP Version
Operating System
Debian 13