#
7d05bc86 |
| 24-Jun-2020 |
Nikita Popov |
Fix crypt_r detection And force use of our own php_crypt_r implementation to keep previous behavior despite that.
|
Revision tags: php-8.0.0alpha1, php-7.4.8RC1, php-7.3.20RC1, php-7.4.7, php-7.3.19 |
|
#
7a9f0cc3 |
| 27-May-2020 |
Alex Dowad |
Simplify `_crypt_extended_init_r`, and fix redundant initialization on Win32/Solaris Looking at the history of this function, the original implementation had a bug where it would return
Simplify `_crypt_extended_init_r`, and fix redundant initialization on Win32/Solaris Looking at the history of this function, the original implementation had a bug where it would return from the middle of the function without unlocking the mutex first. The author attempted to fix this by incrementing the `initialized` flag atomically, which is not necessary, since the section which modifies the flag is protected by a mutex. Coincidentally, at the same time that all this unnecessary 'atomic' machinery was introduced, the code was also changed so that it didn't return without unlocking the mutex. So it looks like the bug was fixed by accident. It's not necessary to declare the flag as `volatile` either, since it is protected by a mutex. Further, the 'fixed' implementation was also wrong in another respect: on Windows and Solaris, the `initialized` flag was not even declared as `static`!! So the initialization of the static tables for S-boxes, P-boxes, etc. was repeated on each call to `php_crypt`, completely defeating the purpose of this function.
show more ...
|
#
91982bad |
| 23-Jun-2020 |
Christoph M. Becker |
7.3 is now 7.3.21-dev
|
#
13f9f874 |
| 23-Jun-2020 |
Derick Rethans |
PHP-7.4 is now 7.4.9-dev
|
#
7e2147be |
| 26-May-2020 |
Alex Dowad |
Clean up some unused code (and fix some comments) in build scripts - Fix typo in build/php.m4 - Nothing uses HAVE_INTTYPES_H; so remove check for header file - Nothing defi
Clean up some unused code (and fix some comments) in build scripts - Fix typo in build/php.m4 - Nothing uses HAVE_INTTYPES_H; so remove check for header file - Nothing defines ZEND_ACCONFIG_H_NO_C_PROTOS; so remove #ifndef - `format_money` was removed in 2019, so <monetary.h> no longer needed - Nothing uses HAVE_NETDB_H; so remove check for header file - Nothing checks HAVE_TERMIOS_H; so remove check for header file (This was actually added when Wez Furlong was adding the original implementation of PTY support in `proc_open`, since replaced.) - Nothing checks HAVE_SYS_AUXV_H; so remove check for header file - PHP_BUILD_DATE variable is not used for anything, so remove it This variable was added to the Makefile, but from there, was not used for anything. The comments suggest it was intended to allow 'reproducible builds'. Presumably, this means that if a bug is found in a PHP binary somewhere, one could look at the Makefile which it was built from, see the date, and then could check the same code version out from source control. But... there can easily be multiple commits to the repo in the same day. Also, what makes us think that the Makefile which a binary was built from will be easily available? Besides, ext/standard/info.c already embeds the build date and time in each binary... but it does it using `__DATE__` and `__TIME__` (see `php_print_info`). - Nothing checks HAVE_FINITE; so don't check for function - Grammar fix to comment in build/php.m4 - Nothing sets $php_ldflags_add_usr_lib variable in configure, so remove conditional This was added in 2002, when Rasmus was having difficulty building PHP on some host and needed to have /usr/lib in the rpath. It was never documented and probably has never been used by anyone else.
show more ...
|
#
bb613465 |
| 17-Jun-2020 |
David Carlier |
Fix Haiku build getrusage supports only two fields. The network api sits in the network lib. Closes GH-5732.
|
#
3a19726b |
| 27-May-2020 |
Alex Dowad |
Remove unneeded --disable-inline-optimization build parameter In 1999, inline optimization was turned off by default. The commit log indicates this was done because GCC was running out o
Remove unneeded --disable-inline-optimization build parameter In 1999, inline optimization was turned off by default. The commit log indicates this was done because GCC was running out of memory on some hosts when building the Zend executor. In 2003, inline optimization was re-enabled by default, but a build option was added to turn it off if one runs out of memory when building. Computing hardware has come a long way since 2003 and I doubt that anyone is running out of memory when building PHP now. Interestingly, this code set an unused variable called `INLINE_CFLAGS`. It actually disabled inline optimization by adding -O0 to the build command, not using `INLINE_CFLAGS`. Just to see how much memory GCC/Make are using when building PHP, I tried building with successively higher values of `ulimit -v` until it succeeded. Interestingly, while most of the codebase can be built with about 400MB of memory, ext/fileinfo/libmagic/apprentice.c requires 1.2GB, doubtless because it includes ext/fileinfo/data_file.c, which is more than 350,000 lines long. That is with GCC 7.5.0. Most users get PHP as a binary package anyways, so the question is, are *packagers* of PHP trying to build on machines with just 1GB RAM? And would they want to package a PHP interpreter built with *no optimizations*? I can't imagine either being true.
show more ...
|
#
d21b1c56 |
| 05-Jun-2020 |
Jelle van der Waa |
Allow defining of uname value for reproducible builds Extend configure.ac to accept PHP_UNAME as env variable to set the value of the PHP_UNAME define in a reproducible manner. This allo
Allow defining of uname value for reproducible builds Extend configure.ac to accept PHP_UNAME as env variable to set the value of the PHP_UNAME define in a reproducible manner. This allows distributions to set a fixed value for php_uname and keep the default behaviour if PHP_UNAME is not set. Motivation: https://reproducible-builds.org/ Closes GH-5671.
show more ...
|
Revision tags: php-7.4.7RC1, php-7.3.19RC1 |
|
#
a7908c2d |
| 24-May-2020 |
Benjamin Eberlei |
Add Attributes Co-authored-by: Martin Schröder <m.schroeder2007@gmail.com>
|
#
c249f593 |
| 26-May-2020 |
Christoph M. Becker |
7.3.20 will be next
|
#
e852944f |
| 20-May-2020 |
Nikita Popov |
Add --enable-memory-sanitizer flag This flag enabled msan late in the pipeline, so that it does not affect configure checks. Otherwise we get a false positive report for openpty
Add --enable-memory-sanitizer flag This flag enabled msan late in the pipeline, so that it does not affect configure checks. Otherwise we get a false positive report for openpty availability without -lutil, which will then result in infinite recursion if actually called. This also sets origin tracking to 2, so bump the timeout to 90 minutes.
show more ...
|
#
c4badcbe |
| 19-May-2020 |
Christoph M. Becker |
Bump version Seems that has been forgotten.
|
Revision tags: php-7.4.6, php-7.2.31 |
|
#
a84cd96e |
| 03-May-2020 |
Alex Dowad |
Add PTY support to proc_open (again after 16 long years) Back in 2004, a feature was added to proc_open which allowed it to open a PTY, connecting specific FDs in the child process to th
Add PTY support to proc_open (again after 16 long years) Back in 2004, a feature was added to proc_open which allowed it to open a PTY, connecting specific FDs in the child process to the slave end of the PTY and returning the master end of the PTY (wrapped as a PHP stream) in the `$pipes` array. However, this feature was disabled just about a month later. Little information is available about why this was done, but from talking to the original implementer, it seems there were portability problems with some rare flavors of Unix. Re-enable this feature with a simplified implementation which uses openpty(). No attempt is made to support PTYs if the platform does not have openpty(). The configure script checks if linking with -lutil is necessary to use openpty(), but if anything else is required, like including some special header or linking with some other library, PTY support will be disabled. The original PTY support for proc_open automatically daemonized the child process (disassociating it from the TTY session and process group of the parent). However, I don't think this is a good idea. Just because a user opens a child process in a PTY, it doesn't mean they want it to continue running even when the parent process is killed. Of course, if the child process is some kind of server, it will likely daemonize itself; but we have no reason to preempt that decision. It turns out that since 2015, there has been one test case for PTY support in proc_open() in the test suite. This test was added in GitHub PR #1588 (https://github.com/php/php-src/pull/1588). That PR mentioned that the PHP binary in the Debian/Ubuntu repositories is patched to *enable* PTY support. Checking the Debian PHP repository (https://salsa.debian.org/php-team/php.git) shows that this is still true. Debian's patch does not modify the implementation from 2004 in any way; it just removes the #if 0 line which disables it. Naturally, the test case is skipped if PTY support is not enabled. This means that ever since it was added, every test run against the 'vanilla' PHP codebase has skipped it. Interestingly, the test case which was added in 2015 fails on my Linux Mint PC... both with this simplified implementation *and* when enabling the original implementation. Investigation reveals the reason: when the child process using the slave end of the PTY exits and its FDs are all closed, and all buffered data is read from the master end of the PTY, any further attempt to read from the master end fails with EIO. The test case seems to expect that reading from the master end will always return an empty string if no data is available. Likely this is because PHP's fread() was updated to report errors from the underlying system calls only recently. One way out of this dilemma: IF at least one FD referring to the slave end of the PTY is kept open *in the parent process*, the failure with EIO will not occur even after the child process exits. However, that would raise another issue: we would need a way to ensure the FD will be closed eventually in long-running programs. Another discovery made while testing this code is that fread() does not always return all the data written to the slave end of the PTY in a single call, even if the data was written with a single syscall and it is only a few bytes long. Specifically, when the child process in the test case writes "foo\n" to the PTY, the parent sometimes receives "foo" (3 bytes) and sometimes "foo\r\n" (5 bytes). (The "\r" is from the TTY line discipline converting "\n" to "\r\n".) A second call to fread() does return the remaining bytes, though sometimes all the data is read in the first call, and by the time the second call is made, the child process has already exited. It seems that liberal use of the @ operator is needed when using fread() on pipes. Thanks to Nikita Popov for suggesting that we should just use openpty() rather than grantpt(), unlockpt(), etc.
show more ...
|
#
d4bebc87 |
| 13-May-2020 |
Ondřej Surý |
Properly detect CRC32 APIs on aarch64 from configure The CRC32 APIs are optional for armv8-a. They became mandatory since armv8.1-a. Closes GH-5564.
|
#
4cf8be71 |
| 12-May-2020 |
Remi Collet |
bump version to 7.2.32-dev
|
Revision tags: php-7.4.6RC1, php-7.3.18RC1, php-7.2.30, php-7.4.5, php-7.3.17, php-7.4.5RC1, php-7.3.17RC1, php-7.3.18, php-7.4.4, php-7.2.29, php-7.3.16, php-7.4.4RC1, php-7.3.16RC1, php-7.4.3, php-7.2.28, php-7.3.15RC1, php-7.4.3RC1, php-7.3.15, php-7.2.27, php-7.4.2, php-7.3.14, php-7.3.14RC1, php-7.4.2RC1, php-7.4.1, php-7.2.26, php-7.3.13, php-7.4.1RC1, php-7.3.13RC1, php-7.2.26RC1, php-7.4.0, php-7.2.25, php-7.3.12, php-7.4.0RC6, php-7.3.12RC1, php-7.2.25RC1 |
|
#
5dc9418a |
| 31-Oct-2019 |
Nikita Popov |
Reapply "Remove configure checks for supported instruction sets" I reverted this previously for 7.4 because of bug #78769. Relanding it now for master, because I still believe that this
Reapply "Remove configure checks for supported instruction sets" I reverted this previously for 7.4 because of bug #78769. Relanding it now for master, because I still believe that this change is right, and if it causes complications, those indicate a bug elsewhere. --- These were checking whether the instruction set is supported by the host CPU, however they were only used to condition on whether this instruction set is targeted at all. It would still use dynamic dispatch (e.g. based on ifunc resolvers) to select the actual implementation. Whether the target is guaranteed to support the instruction set without dispatch is determined based on pre-defined macros like __SSE2__. This removes the configure-time builtin cpu checks to remove confusion. Additionally this allows targeting an architecture that is newer than the host architecture.
show more ...
|
#
6998cc50 |
| 28-Apr-2020 |
Christoph M. Becker |
Bump version
|
#
77ee4e63 |
| 22-Apr-2020 |
Alex Dowad |
Nothing in codebase cares whether platform has fpclass() Therefore, don't bother checking for it in 'configure' script. Closes GH-5453
|
#
01634f84 |
| 31-Mar-2020 |
Derick Rethans |
The 7.4 branch is now for 7.4.6
|
#
33226c3a |
| 31-Mar-2020 |
Christoph M. Becker |
Next is 7.3.18
|
#
457380ca |
| 29-Mar-2020 |
George Peter Banyard |
Drop wchar header check as always defined since C95
|
#
e8e09b60 |
| 26-Mar-2020 |
Nikita Popov |
Remove rand_r implementation We already use our own mt13397 implementation nowadays, so we no longer need this shim.
|
#
97cb81ea |
| 23-Mar-2020 |
Nikita Popov |
Remove HAVE_REALPATH checks We do not actually use realpath(), but a custom implementation. Make sure the realpath() function is always available. Closes GH-5290.
|
#
3072b77c |
| 17-Mar-2020 |
Remi Collet |
bump verison to 7.2.30-dev
|
#
f73528f0 |
| 09-Mar-2020 |
Peter Seiderer |
Check for sys/auxv.h before using it. Fixes aarch64 compile with uclibc-ng (does not provide sys/auxv.h header file). Closes GH-5248. Signed-off-by: Peter Seiderer <ps.
Check for sys/auxv.h before using it. Fixes aarch64 compile with uclibc-ng (does not provide sys/auxv.h header file). Closes GH-5248. Signed-off-by: Peter Seiderer <ps.report@gmx.net>
show more ...
|