The hash is used to check whether the arginfo file needs to be
regenerated. PHP-Parser will only be downloaded if this is actually
necessary.
This ensures that release artifacts will never try to regenerate
stubs and thus fetch PHP-Parser, as long as you do not modify any
files.
Closes GH-5739.
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.
`atol()` returns a `long` which is not the same as `zend_long` on
LLP64; we use `ZEND_ATOL()` instead.
There is no need for a new test case, since filesize_large.phpt already
tests for that behavior; unfortunately, the FTP test suite relies on
`pcntl_fork()` and therefore cannot be run on Windows.
Before this commit, the result produced by a joaat hash depended
on how the input data was chunked. A hash produced by multiple
`hash_update` operations was incorrect. For example, this code,
which should produce three identical lines:
var_dump(hash("joaat", "abcd"));
$hash = hash_init("joaat");
hash_update($hash, "ab");
hash_update($hash, "cd");
var_dump(hash_final($hash));
$hash = hash_init("joaat");
hash_update($hash, "abc");
hash_update($hash, "d");
var_dump(hash_final($hash));
instead produced:
string(8) "cd8b6206"
string(8) "e590d137"
string(8) "2d59d087"
This is because the finalization step, involving shift operations
and adds, was applied on every chunk, rather than once at the end
as is required by the hash definition.
After this commit, the code above produces:
string(8) "cd8b6206"
string(8) "cd8b6206"
string(8) "cd8b6206"
as expected.
Some tests encoded the wrong behavior and were corrected.
Closes GH-5749
Check if data would overlap and also add an assert. Previous
implementations didn't have this issue, as the direct assignment was
used.
Signed-off-by: Anatol Belski <ab@php.net>
The existing AC_FPM_APPARMOR macro (which is always run when FPM is
enabled) checks for the existence of libapparmor, and adds it to $LIBS
if found. The result is an "automagic" dependency on libapparmor that
depends not only on the user's configuration, but also on the build
host's environment.
In particular, this can cause problems if the user just happens to
have libapparmor installed (for testing or development) when he builds
PHP. Later, he may remove libapparmor, not realizing that PHP depends
on it. At that point, FPM will cease to work due to the missing library.
This commit adds a new configure flag called "--with-fpm-apparmor",
defaulting to "no", that enables or disables the feature. The new flag
is used to signal the user's intent; whether or not he wants to use
AppArmor. If he does, then we still check for the existence and
usability of libapparmor; however, it is now an error for the library
to be missing when --with-fpm-apparmor is requested.
Gentoo-bug: https://bugs.gentoo.org/637402
PHP-bug: https://bugs.php.net/bug.php?id=75519
Nikita Popov