Open TysonAndre opened 1 year ago
Yeah, that behavior is not correct; however, key_t
is underspecified by POSIX; it merely mandates that key_t
is an arithmetic type, so we probably can't assume it is int
everywhere.
Yeah, that behavior is not correct; however, key_t is underspecified by POSIX; it merely mandates that key_t is an arithmetic type, so we probably can't assume it is int everywhere.
key != (zend_long)(key_t)key
should work as a runtime check.
key != (zend_long)(key_t)key
should work as a runtime check.
If key_t
is signed and its rank is less than that of zend_long
, wouldn't that possibly be undefined behavior.
Anyhow, shm_attach()
has exactly the same issue than shmop_open()
.
it merely mandates that
key_t
is an arithmetic type
This is ugly, since arithmetic types even include float
etc. However, we can hopefully assume that it is actually an integer type, and as such could determine the details during configuration: its size (sizeof(key_t)
, and its signedness.
Description
The following code:
Resulted in this output:
But I expected this output instead:
(seen on 64-bit linux with sizeof(int) == 4, sizeof(zend_long) == 8)
Not really something users are likely to do deliberately
This also means that 0x1_0000_0000 is an alias for IPC_PRIVATE, which always creates a new memory segment.
Noticed while looking into #9944
PHP Version
Any
Operating System
No response