Replaced wrong type of "addr" in pcntl_signal callback arg

[Cobalt-Inferno]

Inside ext/pcntl/pcntl.c there was usage of add_assoc_double_ex() whilst also casting to (zend_long)
I replaced it with add_assoc_long_ex()

Closes GH-9815

[iluuu1994]

Thank you! This sounds reasonable. This does justify a mention in UPGRADING (since it oculd break === comparison). This can be done by whoever merges this.

[cmb69]

Maybe @arnaud-lb remembers why a double was used in the first place (cf. c58e2b9).

[arnaud-lb]

Unfortunately I can't remember. Apparently I exposed the int fields of siginfo_t with add_assoc_long and larger ones with add_assoc_double, so it may have been a (wrong) way to support systems with sizeof(void*) > sizeof(long).

The change looks good to me.

We could also expose addr as a string for the following reasons:

• It would avoid high values of addr being represented as negative values
• Although unlikely, sizeof(void*) > sizeof(zend_long) is theoretically possible

[cmb69]

We could also expose addr as a string for the following reasons:

That might indeed be even more reasonable.

[cmb69]

This does justify a mention in UPGRADING (since it oculd break === comparison).

This is an important point! If we introduce a small BC break (I doubt, though, that anybody compares addresses), we should probably have a string right away.

[haq0]

Will this still be useful or should it not be merged?

[iluuu1994]

We could also expose addr as a string for the following reasons:

• It would avoid high values of addr being represented as negative values
• Although unlikely, sizeof(void*) > sizeof(zend_long) is theoretically possible

This is an important point! If we introduce a small BC break (I doubt, though, that anybody compares addresses), we should probably have a string right away.

I think that was the main takeaway. Using a string representation for the pointer might make more sense.