The previous shifting logic is problematic for two reasons:
1. It invokes undefined behavior when the `->last_generated_size` is at least
as large as the target integer in `result`, because the shift is larger than
the target integer. This was reported in GH-9083.
2. It expands the returned bytes in a big-endian fashion: Earlier bytes are
shifting into the most-significant position. As all the other logic in the
random extension treats byte-strings as little-endian numbers this is
inconsistent.
By fixing the second issue, we can implicitly fix the first one: Instead of
shifting the existing bits by the number of "newly added" bits, we shift the
newly added bits by the number of existing bits. As we stop requesting new bits
once the total_size reached the size of the target integer we can be sure to
never invoke undefined behavior during shifting.
The get_int_user.phpt test was adjusted to verify the little-endian behavior.
It generates a single byte per call and we expect the first byte generated to
appear at the start of the resulting number.
see GH-9056 for a previous fix in the same area.
Fixes GH-9083 which reports the undefined behavior.
Resolves GH-9085 which was an alternative attempt to fix GH-9083.
* Fix shift in rand_range??()
The last generated size is in bytes, whereas the shift is in bits. Multiple the
generated size by 8 to correctly handle each byte once.
* Correctly handle user engines returning less than 4 bytes in rand_rangeXX()
We need to loop until we accumulate sufficient bytes, instead of just checking
once. The version in the rejection loop was already correct.
* Clean up some repetition in rand_rangeXX()
This fixes:
==374077== Use of uninitialised value of size 8
==374077== at 0x532B06: generate (engine_user.c:39)
==374077== by 0x533F71: zim_Random_Randomizer_getBytes (randomizer.c:152)
==374077== by 0x7F581D: ZEND_DO_FCALL_SPEC_RETVAL_USED_HANDLER (zend_vm_execute.h:1885)
==374077== by 0x8725BE: execute_ex (zend_vm_execute.h:55930)
==374077== by 0x877DB4: zend_execute (zend_vm_execute.h:60253)
==374077== by 0x7B0FD4: zend_execute_scripts (zend.c:1770)
==374077== by 0x6F1647: php_execute_script (main.c:2535)
==374077== by 0x937DA4: do_cli (php_cli.c:964)
==374077== by 0x938C3A: main (php_cli.c:1333)
==374077==
==374077== Invalid read of size 8
==374077== at 0x532B06: generate (engine_user.c:39)
==374077== by 0x533F71: zim_Random_Randomizer_getBytes (randomizer.c:152)
==374077== by 0x7F581D: ZEND_DO_FCALL_SPEC_RETVAL_USED_HANDLER (zend_vm_execute.h:1885)
==374077== by 0x8725BE: execute_ex (zend_vm_execute.h:55930)
==374077== by 0x877DB4: zend_execute (zend_vm_execute.h:60253)
==374077== by 0x7B0FD4: zend_execute_scripts (zend.c:1770)
==374077== by 0x6F1647: php_execute_script (main.c:2535)
==374077== by 0x937DA4: do_cli (php_cli.c:964)
==374077== by 0x938C3A: main (php_cli.c:1333)
==374077== Address 0x11 is not stack'd, malloc'd or (recently) free'd
Each section of `phpinfo` is titled with an `<h2><a name="module_NAME">NAME</a></h2>` tag. While the `name=module_NAME` attribute allows linking to that section using a URL fragment (e.g `info.php#module_NAME`), it lacks discoverability because the `<a>` tag does not contain an `href` attribute. This is also highlighted in accessibility scans (in Firefox for instance).
This adds a link to the `<a>` tag that links to the URL fragment, fixing the accessibility remark and improving the discoverability of the clickable section titles. Also contains minor CSS changes to account for the dark theme CSS.
Closes GH-9054.
Passing `null` to `$encodings` is supposed to behave like passing the
result of `mb_detect_order()`. Therefore, we need to remove the non-
encodings from the `elist` in this case as well. Thus, we duplicate
the global `elist`, so we can modify it.
Closes GH-9063.
The `--CGI--` section is supposed to be just a marker, and to be empty
as such. However, a previous refactoring[1] broke that.
[1] <9140c9038a>
Closes GH-9061.
