| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
To avoid that `parse_url()` returns an erroneous host, which would be
valid for `FILTER_VALIDATE_URL`, we make sure that only userinfo which
is valid according to RFC 3986 is treated as such.
For consistency with the existing url parsing code, we use ctype
functions, although that is not necessarily correct.
(cherry picked from commit b132da7f9df3)
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| | |
* PHP-7.4:
Fix #77322: PharData::addEmptyDir('/') Possible integer overflow
|
| |
| |
| |
| |
| |
| |
| | |
`phar_path_check()` already strips a leading slash, so we must not
attempt to strip the trailing slash from an now empty directory name.
Closes GH-6508.
|
|\ \
| |/
| |
| |
| | |
* PHP-7.4:
7.3.27 is next
|
| |\
| | |
| | |
| | |
| | | |
* PHP-7.3:
7.3.27 is next
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
"function" values
`opcache.jit` accepts `tracing` and `function` as aliases, but they were not mentioned in the start-up INI warning message.
This updates the error message to include all possible values.
Closes GH-6490.
|
|\ \ \
| |/ /
| | |
| | |
| | | |
* PHP-7.4:
IBM i PASE doesn't support ITIMER_PROF
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Like Cygwin, this platform needs to use a real-time timer.
This was based on a patch by @kadler, but it didn't handle unsetting
the timer, so the timeout would continue to be active, triggering
`hard_timeout` unexpectedly. The patch is fixed to handle unsetting.
Closes GH-6503.
|
| | |
| | |
| | |
| | | |
Closes GH-6514.
|
| | |
| | |
| | |
| | | |
As requested by Christopher Jones.
|
|\ \ \
| |/ /
| | |
| | |
| | | |
* PHP-7.4:
Drop pdo_mysql_prepare_load_data.phpt
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Like the test title and some comments in this test describe, this test
was supposed to have `::prepare()` failing because `LOAD DATA INFILE`
would not be supported as prepared statement, and then the test checks
whether follow-up queries would succeed. However, `LOAD DATA INFILE`
is supported for prepared statements at least on Windows with mysqlnd,
so the test does no longer test what it is supposed to do. Therefore,
we drop it.
Closes GH-6509.
|
| | | |
|
| | | |
|
| | | |
|
|\ \ \
| |/ / |
|
| | | |
|
| | |
| | |
| | |
| | | |
Closes GH-6506.
|
| | |
| | |
| | |
| | |
| | |
| | | |
Following cmb's suggestion and replacing the counter with a check
against the bound_params HT, which ensures that both cannot go
out of sync.
|
| | |
| | |
| | |
| | |
| | |
| | | |
The logic after next_result should match the one after execute.
This was the case for mysqlnd but not libmysqlclient, which used
the non-PS logic.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This test was always skipped (leftover debug statement?)
Contrary to the comments in the test and the test expectation,
this actually works fine.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Repeated execute() with native PS failed to release the previous
result set on libmysqlclient.
Move freeing the result set into a common location.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
libmysqlclient added this function in version 5.5, which happens
to be the minimum we support. If we have a prepared statement,
we should use it on both mysqlnd and libmysqlclient, even if the
handling afterwards is different.
This fixes error handling with native prepared statements.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The fact that getAttribute() fails for various libmysqlclient-only
options is a known issue, and the test was taking that into account.
However, the change of the default error mode broke the handling.
We need to handle the exceptions now.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Our minimum libmysqlclient version requirement is high enough
that we don't need to check for MYSQL_OPT_LOCAL_INFILE support.
However, the mysql_get_option() function seems to only be available
since 5.7 (though it's really hard to find any definitie information
on when MySQL introduced certain functions or changes...) so we
need to store the value of the flag locally to make it available
through getAttribute().
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
stmt->column_count gets reset before the next_rowset handler is
invoked, so we need to fetch the value from the result set instead.
Arguably PDO should be separating the destruction of the previous
result set and the switch to the next result set more cleanly...
|
| | |
| | |
| | |
| | |
| | |
| | | |
And remove unnecessary try-catch.
Closes GH-6505.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Generate a param count mismatch error even if the query contains
no placeholders.
Additionally we shouldn't HANDLE errors from pdo_parse_params,
which are always reported via raise_impl_error. Doing so results
in duplicate error messages.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
And thus generate error messages that match what PDO emulation
would generate.
This fixes the error message regression from the previous commit.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When a driver reports an error during EVT_ALLOC (and some over EVTs),
make sure we handle it as usual, i.e. warn or throw.
This requires some adjustments in PDO PgSQL to stop manually doing
this through an impl error.
Unfortunately the PDO PgSQL error messages regress because of this,
as they now include a completely arbitrary error code. There doesn't
seem to be an ability to skip it right now.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The actual behavior here is correct, but the previous error
message was misleading, as neither fetchAll() nor buffered queries
would help in this situation. Instead it is necessary to consume
all rowsets, which can be done by either unsetting the statement
or calling closeCursor().
|
|\ \ \
| |/ /
| | |
| | |
| | | |
* PHP-7.4:
Fixed bug #76815
|
| | |
| | |
| | |
| | |
| | |
| | | |
When we receive an error while reading a result set, we should
assume that no more result sets are available. libmysqlclient
implements the same behavior.
|
|\ \ \
| |/ /
| | |
| | |
| | | |
* PHP-7.4:
Fixed bug #71145
|
| | |
| | |
| | |
| | | |
Consume any additional result sets when running INIT_COMMAND.
|
| | |
| | |
| | |
| | | |
Closes GH-6502.
|
|\ \ \
| |/ /
| | |
| | |
| | | |
* PHP-7.4:
Backport fix for bug #70066
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Given the number of duplicates this bug report had, it seems
worthwhile to fix this on PHP-7.4 as well.
Cherry-pick of 106e7e4bca7c0fd975eb219b18e3c34957ba8657.
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
If we fall back to emulated prepared statements, destroy S->stmt,
so the code doesn't get confused about which mode we're in.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Keep track of whether we have fully consumed all result sets,
either using nextRowset() calls or closeCursor() and skip the
attempt to consume remaining results sets during destruction in
that case.
Especiall if closeCursor() has been used, we really shouldn't
have this sort of cross-statement inference.
|
| | |
| | |
| | |
| | | |
Just calling next_result() is sufficient.
|