The php_stream_read() and php_stream_write() functions now return
an ssize_t value, with negative results indicating failure. Functions
like fread() and fwrite() will return false in that case.
As a special case, EWOULDBLOCK and EAGAIN on non-blocking streams
should not be regarded as error conditions, and be reported as
successful zero-length reads/writes instead. The handling of EINTR
remains unclear and is internally inconsistent (e.g. some code-paths
will automatically retry on EINTR, while some won't).
I'm landing this now to make sure the stream wrapper ops API changes
make it into 7.4 -- however, if the user-facing changes turn out to
be problematic we have the option of clamping negative returns to
zero in php_stream_read() and php_stream_write() to restore the
old behavior in a relatively non-intrusive manner.
RFC: https://wiki.php.net/rfc/tostring_exceptions
And convert some object to string conversion related recoverable
fatal errors into Error exceptions.
Improve exception safety of internal code performing string
conversions.
Besides the common `:param` notation to designate named parameters in
prepared statements, SQLite3 also supports `@param` and `$param`.
While the latter is mostly to support the Tcl programming language, and
would be confusing for PHP's sqlite3 binding due to the similarity with
string interpolation, the former is common under .NET and raises no
such issue. Therefore we add support for it.
This patch has been developed in cooperation with @BohwaZ.
This patch adds missing newlines, trims multiple redundant final
newlines into a single one, and trims redundant leading newlines in all
*.phpt sections.
According to POSIX, a line is a sequence of zero or more non-' <newline>'
characters plus a terminating '<newline>' character. [1] Files should
normally have at least one final newline character.
C89 [2] and later standards [3] mention a final newline:
"A source file that is not empty shall end in a new-line character,
which shall not be immediately preceded by a backslash character."
Although it is not mandatory for all files to have a final newline
fixed, a more consistent and homogeneous approach brings less of commit
differences issues and a better development experience in certain text
editors and IDEs.
[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
[2] https://port70.net/~nsz/c/c89/c89-draft.html#2.1.1.2
[3] https://port70.net/~nsz/c/c99/n1256.html#5.1.1.2
This patch adds missing newlines, trims multiple redundant final
newlines into a single one, and trims redundant leading newlines in all
*.phpt sections.
According to POSIX, a line is a sequence of zero or more non-' <newline>'
characters plus a terminating '<newline>' character. [1] Files should
normally have at least one final newline character.
C89 [2] and later standards [3] mention a final newline:
"A source file that is not empty shall end in a new-line character,
which shall not be immediately preceded by a backslash character."
Although it is not mandatory for all files to have a final newline
fixed, a more consistent and homogeneous approach brings less of commit
differences issues and a better development experience in certain text
editors and IDEs.
[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
[2] https://port70.net/~nsz/c/c89/c89-draft.html#2.1.1.2
[3] https://port70.net/~nsz/c/c99/n1256.html#5.1.1.2
This patch adds missing newlines, trims multiple redundant final
newlines into a single one, and trims redundant leading newlines in all
*.phpt sections.
According to POSIX, a line is a sequence of zero or more non-' <newline>'
characters plus a terminating '<newline>' character. [1] Files should
normally have at least one final newline character.
C89 [2] and later standards [3] mention a final newline:
"A source file that is not empty shall end in a new-line character,
which shall not be immediately preceded by a backslash character."
Although it is not mandatory for all files to have a final newline
fixed, a more consistent and homogeneous approach brings less of commit
differences issues and a better development experience in certain text
editors and IDEs.
[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
[2] https://port70.net/~nsz/c/c89/c89-draft.html#2.1.1.2
[3] https://port70.net/~nsz/c/c99/n1256.html#5.1.1.2
Since there is no need to patch libsqlite3 for our purposes, and since
libsqlite3 ≥ 3.3.9 (which is our current requirement) is widely
available on distros, there is no reason anymore to bundle the library.
Besides removing the bundled libsqlite, and adapting the configuration
respectively, we also fix the use of the SQLITE_ENABLE_COLUMN_METADATA
compile time constant to detect whether sqlite3_column_table_name() is
available by a working feature detection (otherwise bug_42589.phpt
would fail). We also skip bug73068.phpt for libsqlite 3.11.0 to
3.14.1 which have a bug (<https://sqlite.org/src/info/ef360601>).
We also completely drop support for the obscure pdo_sqlite_external
extension (which could have been enabled on Windows only by passing
`--pdo-sqlite-external` to configure), since it is not needed anymore.
Furthermore, we remove references to the bundled libsqlite from
Makefile.gcov, CONTRIBUTING.md and README.REDIST.BINS.
SQLITE_DETERMINISTIC only exists in recent version
e.g. missing on 3.7 which is the default on RHEL/CentOS-7
and probably others (wheezy have 3.7, jessie 3.8...)
Calling sqlite3_reset() when a result set object is freed can cause
undesired and maybe even hard to track interference with other result
sets. Furthermore, there is no need to call sqlite3_reset(), because
that is implicitly called on SQLite3Stmt::execute(), and users are
encouraged to explicitly call either SQLite3Result::finalize() or
SQLite3Stmt::reset() anyway.
Fabien Villepinte