This patch adds missing newlines, trims multiple redundant final
newlines into a single one, and trims redundant leading newlines.
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.
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.
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 simplifies line endings tracked in the Git repository and
syncs them to all include the LF style instead of the CRLF files.
Newline characters:
- LF (\n) (*nix and Mac)
- CRLF (\r\n) (Windows)
- CR (\r) (old Mac, obsolete)
To see which line endings are in the index and in the working copy the
following command can be used:
`git ls-files --eol`
Git additionally provides `.gitattributes` file to specify if some files
need to have specific line endings on all platforms (either CRLF or LF).
Changed files shouldn't cause issues on modern Windows platforms because
also Git can do output conversion is core.autocrlf=true is set on
Windows and use CRLF newlines in all files in the working tree.
Unless CRLF files are tracked specifically, Git by default tracks all
files in the index using LF newlines.
This patch simplifies line endings tracked in the Git repository and
syncs them to all include the LF style instead of the CRLF files.
Newline characters:
- LF (\n) (*nix and Mac)
- CRLF (\r\n) (Windows)
- CR (\r) (old Mac, obsolete)
To see which line endings are in the index and in the working copy the
following command can be used:
`git ls-files --eol`
Git additionally provides `.gitattributes` file to specify if some files
need to have specific line endings on all platforms (either CRLF or LF).
Changed files shouldn't cause issues on modern Windows platforms because
also Git can do output conversion is core.autocrlf=true is set on
Windows and use CRLF newlines in all files in the working tree.
Unless CRLF files are tracked specifically, Git by default tracks all
files in the index using LF newlines.
This patch simplifies line endings tracked in the Git repository and
syncs them to all include the LF style instead of the CRLF files.
Newline characters:
- LF (\n) (*nix and Mac)
- CRLF (\r\n) (Windows)
- CR (\r) (old Mac, obsolete)
To see which line endings are in the index and in the working copy the
following command can be used:
`git ls-files --eol`
Git additionally provides `.gitattributes` file to specify if some files
need to have specific line endings on all platforms (either CRLF or LF).
Changed files shouldn't cause issues on modern Windows platforms because
also Git can do output conversion is core.autocrlf=true is set on
Windows and use CRLF newlines in all files in the working tree.
Unless CRLF files are tracked specifically, Git by default tracks all
files in the index using LF newlines.
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.
The C89 standard and later defines the `<string.h>` header as part of
the standard headers [1] and on current systems it is always present.
Code included also `<strings.h>` header as an alterinative in some
files. This kind of check was relevant on some older systems where the
`<strings.h>` file included definitions for the C89 compliant
`<string.h>`. Today such alternative check is not required anymore. The
`<strings.h>` file is part of the POSIX definition these days.
Also Autoconf suggests doing this and relying on C89 or above [2] and [3].
This patch also cleans few unused `<strings.h>` inclusions in the libmbfl.
[1]: https://port70.net/~nsz/c/c89/c89-draft.html#4.1.2
[2]: http://git.savannah.gnu.org/cgit/autoconf.git/tree/lib/autoconf/headers.m4
[3]: https://www.gnu.org/software/autoconf/manual/autoconf-2.69/autoconf.html
The `<assert.h>` header file is part of the standard C89 headers [1] and
on older systems there needed to be also a manual check if header is
present.
Since PHP requires at least C89 manual check and the `HAVE_ASSERT_H`
symbol defined by Autoconf in configure.ac can be both removed [2].
This patch also removes unused <assert.h> includes where c files don't
use the `assert()` macro.
Refs:
[1] https://port70.net/~nsz/c/c89/c89-draft.html#4.2
[2] https://git.savannah.gnu.org/cgit/autoconf.git/tree/lib/autoconf/headers.m4
Autoconf 2.59d (released in 2006) [1] started promoting several macros
as not relevant for newer systems, including the AC_FUNC_UTIME_NULL.
This macro checks if `utime(file, NULL)` sets file's timestamp to the
current time and defines the `HAVE_UTIME_NULL` symbol. This check was
relevant on very old systems (for example, 4.3BSD released in 1986) and
today can be omitted for systems with utime since it should be well
supported by now. [2]
Refs:
[1] http://git.savannah.gnu.org/cgit/autoconf.git/tree/NEWS
[2] https://www.gnu.org/software/autoconf/manual/autoconf-2.69/autoconf.html
Autoconf 2.59d (released in 2006) 1 started promoting several macros
as not relevant for newer systems anymore, including the AC_FUNC_VPRINTF.
This macro checks for presence of the vprint function otherwise checks
for presence of the _doprnt function. This check was relevant on very
old systems and today can be omitted since it should be well supported
by now. [2]
Also PHP doesn't use the HAVE_VPRINTF or HAVE_DOPRNT symbols.
Refs:
[1] http://git.savannah.gnu.org/cgit/autoconf.git/tree/NEWS
[2] https://www.gnu.org/software/autoconf/manual/autoconf-2.69/autoconf.html
Since Autoconf 2.50+ macro AC_STRUCT_ST_BLOCKS defines the new
HAVE_STRUCT_STAT_ST_BLOCKS symbol and has deprecated the previous
HAVE_ST_BLOCKS.
PHP 5.3 required Autoconf 2.13 (released in 1999) or newer, since PHP
5.4 the autoconf 2.59 (released in 2003) or newer was required, and
since PHP 7.2, autoconf 2.64 (released in 2008) or newer is required.
Autoconf 2.50 released in 2001 has made several macros obsolete. Instead
of the AC_STRUCT_ST_BLKSIZE and AC_STRUCT_ST_RDEV the new
AC_CHECK_MEMBERS should be used.
When checking for the presence of stat struct members st_blkzize and
st_rdev the new AC_CHECK_MEMBERS macro defines new constants
HAVE_STRUCT_STAT_ST_BLKSIZE and HAVE_STRUCT_STAT_ST_RDEV.
Old constants HAVE_ST_BLKSIZE and HAVE_ST_RDEV need to be replaced
respectively in PHP code (this patch) and in PHP extenstions if they use
them.
PHP 5.4 to 7.1 require Autoconf 2.59+ version, PHP 7.2 and above require
2.64+ version, and the PHP 7.2 phpize script requires 2.59+ version which
are all greater than above mentioned 2.50 version.
The $Id$ keywords were used in Subversion where they can be substituted
with filename, last revision number change, last changed date, and last
user who changed it.
In Git this functionality is different and can be done with Git attribute
ident. These need to be defined manually for each file in the
.gitattributes file and are afterwards replaced with 40-character
hexadecimal blob object name which is based only on the particular file
contents.
This patch simplifies handling of $Id$ keywords by removing them since
they are not used anymore.
When the PHP source code was versioned in Subversion, there was
possible to substitute certain keywords such as $Id$ with revision
number, last change time and author name. Such approach is not used
in Git so this patch removes these outdated artifacts from source
code files.
