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.
- 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.
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.
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.
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.
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.
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.
php_mergesort() isn't being used for anything, and hasn't been for
a long time. Even if we wanted to use a stable sort, this isn't
the implementation we'd use...
This reverts commit edccf32f7f.
This was reported to cause issues for as yet unknown reasons in
bug #78769. As this was intended as code cleanup, revert this from
7.4 at least. May reapply it to master later.
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.
C99 no longer has implicit function declarations and implicit ints.
Current GCC versions enable them as an extension, but this will
change in a future GCC version.
When building PHP outside of the source tree:
mkdir custom-build-dir
cd custom-build-dir
../path/to/php-src/configure
The directories need to be manually created including the pear directory
so the pear installation PHAR file doesn't need to be downloaded from
the remote location.
Closes GH-4639
This was a left over for supporting old code in PHP extensions out there.
Check is not needed anymore since this is part of C89+ standard.
Closes GH-4445
- yp_get_default_domain was part of ext/yp
- functions checks produce HAVE_function_name symbols. These checks are
currently not used in php-src neither in the extensions out there.
- Removed symbols because they are not used in the code:
- HAVE_GCVT
- HAVE_PUTENV
- HAVE_PUTENV
- HAVE_SETVBUF
- HAVE_TEMPNAM
- HAVE_SIN (sin is also defined in C89 standard)
- HAVE_SETSOCKOPT
- HAVE_LOCKF
- HAVE_ISASCII
- HAVE_YP_GET_DEFAULT_DOMAIN (and other yp extension related unused checks)
- HAVE_LINK
- HAVE_USLEEP is already defined in Windows configuration header
- HAVE_LIBBIND has not been used in php-src for a while anymore
- HAVE_GETHOSTNAME is duplicated in Windows configuration header
Closes GH-4417
The undef PTHREADS converts to define if thread safety is configured.
This step is already done by pthreads m4 macros from TSRM so this now
removes duplicated PTHREADS defines from php_config.h.
Instead of patching configuration headers template generated by
the given tools - autoheader, this moves patching these symbols to
the configure step before creating and invoking the config.status
and before the configuration header file is generated from the
patched template.
Closes GH-4374
Changes:
- Coding style fixes
- ${1+"$@"} replaced with "$@" [1]
- EXTRA_MODULE_PTRS variable is not used anymore
- awk tool defined via environment variable
- srcdir determined automatically from the genif.sh location
[1] https://www.in-ulm.de/~mascheck/various/bourne_args/
Closes GH-4372
These are part of the C89 and on today's systems not needed to be
checked anymore. This removes symbols HAVE_SIGNAL and HAVE_STRERROR.
- http://port70.net/~nsz/c/c89/c89-draft.html
- locale.h is also part of C89 but will be removed per request in PHP 8
- Variables php_abs_top_srcdir php_abs_top_builddir are no longer used.
- ZEND_EXT_TYPE is always zend_extension and variable is no longer used.
Closes GH-4378
This simplifies TSRM build steps a bit and avoids doing unnecessary
steps:
- The `PTHREADS_CHECK_COMPILE` can called inside the for loops only
since this is only where the `$pthreads_checked` variable is used.
- Assigning variables can be then done only in the configure.ac
once.
- use `m4_include()` instead of the `sinclude()` in the middle of
the build steps.
- The `$threads_result` variable is not used in the code or in
extensions.
Instead of building a custom macro for checking configure options,
Autoconf 2.62+ already outputs a warning at the beginning and the end
of the output of configure script. It automatically detects correct
and wrong options better.
This is related also to bug #55634.
So now instead a better way is the default Autoconf approach:
This outputs a warning at the beginning and end of the configure output:
./configure --with-non-existing
This results in fatal error:
./configure --non-existing
configure: error: unrecognized option: `--non-existing'
Try `./configure --help' for more information
The `--enable-option-checking=fatal` results in fatal error for all non
existing options:
./configure --with-non-existing --enable-option-checking=fatal
configure: error: unrecognized options: --with-non-existing
Closes GH-4348
This macro is not needed anymore. The AC_PROG_CC is done in the main
configure.ac file and the ranlib check is done by the bundled libtool
macros.
Closes GH-4339
The following functions don't need to be checked anymore since the
they are not used across the code or the symbols aren't used anymore:
- cuserid (not used)
- lrand48 (not used and removed via
6d6ef7aacc)
- random (check is not used)
- srand48 (not used)
- srandom (not used)
- strdup (check is not used)
and the unused check symbols:
- HAVE_CUSERID
- HAVE_LRAND48
- HAVE_RANDOM
- HAVE_SRAND48
- HAVE_SRANDOM
- HAVE_STRDUP
Closes GH-4338
Removed unused checks:
- mbsinit check removed, HAVE_MBSINIT removed (not used in php-src)
- mempcpy check removed, HAVE_MEMPCPY removed (not used in php-src anymore since
560ed89bfb which uses PHP's own implementation)
- strpncpy check removed, added via a8c9e893b6 and
not used.
- setpgid check removed since HAVE_SETPGID is not used
Moved to a central configure.ac:
- fpclass
- mbrlen moved to configure.ac (since the HAVE_MBRLEN is used accross the php-src)
- sigprocmask
- getcwd
- getwd
- glob
- strfmon
- nice
Duplicated checks removed:
- gethostname
- getlogin
- getpwuid_r
- socketpair
- mprotect check simplified
The limits.h header is part of the C89 and is today available
everywhere. There is no need to check for presence of this header
anymore.
The timelib has already been patched upstream via
aae5907cb7
PHP extensions out there shouldn't rely on symbols defined during the
build anyway and neither they do on this particular symbol anymore.
The strcoll function is defined in the C89 standard and should be
on today's systems always available via the <string.h> header.
https://port70.net/~nsz/c/c89/c89-draft.html#4.11.4.3
- Remove also SKIPIF strcoll check in test
Some headers were checked multiple times in the main configure.ac file
and in the bundled extensions or SAPIs themselves. Also many of these
checks are then used accross other extensions or SAPIs so a central
configure.ac makes most sense for these checks.
For some reason, when using GCC with address sanitizer, dlopen
is available without -ldl, but dlsym still needs it. Explicitly check
dlsym so we add the library.
Normalization include:
- Use dnl for everything that can be ommitted when configure is built in
favor of the shell comment character # which is visible in the output.
- Line length normalized to 80 columns
- Dots for most of the one line sentences
- Macro definitions include similar pattern header comments now
TSRM configuration header file was once created by separate autoconf
build system for TSRM and is with the current code not directly needed
like this anymore.
Add --enable-werror configure option and use it on Travis. It's not
possible to directly use CFLAGS, because it also affects configure
checks which often throw warnings.
We can't enable something similar for Windows builds at this time,
because they throw a lot more warnings.
The acinclude.m4 file is in a usual Autotools build processed with
Automake's aclocal tool. Since PHP currently doesn't use Automake and
aclocal this file can be moved into the build directory. PHP build
system currently generates a combined aclocal.m4 file that Autoconf
can processes automatically.
However, a newer practice is writing all local macros in separate
dedicated files prefixed with package name, in PHP's case PHP_MACRO_NAME
and putting them in a common `m4` directory. PHP uses currently `build`
directory for this purpose.
Name `php.m4` probably most resembles such file for PHP's case.
PHP manually created the aclocal.m4 file from acinclude.m4 and
build/libtool.m4. Which is also not a particularly good practice [1], so
this patch also removes the generated alocal.m4 usage and uses
m4_include() calls manually in the configure.ac and phpize.m4 files
manually.
- sort order is not important but can be alphabetical
- list of *.m4 files prerequisites for configure script generation
updated
- Moving m4_include() before AC_INIT also removes all comments starting
with hash character (`#`) in the included files.
[1] https://autotools.io/autoconf/macros.html
There is now only a single M4 macro in the legacy acinclude.m4 file. A
separate acinclude file was once used with a standalone Zend engine
building but with current build system this can be simplified a bit.
The substitution is already done in the CLI's config.m4 file. Current
SAPIs only provide one PHP_EXECUTABLE variable, i.e. PHP CLI so the one
in the configure.ac can be removed.
