This patch removes the so called local variables defined per
file basis for certain editors to properly show tab width, and
similar settings. These are mainly used by Vim and Emacs editors
yet with recent changes the once working definitions don't work
anymore in Vim without custom plugins or additional configuration.
Neither are these settings synced across the PHP code base.
A simpler and better approach is EditorConfig and fixing code
using some code style fixing tools in the future instead.
This patch also removes the so called modelines for Vim. Modelines
allow Vim editor specifically to set some editor configuration such as
syntax highlighting, indentation style and tab width to be set in the
first line or the last 5 lines per file basis. Since the php test
files have syntax highlighting already set in most editors properly and
EditorConfig takes care of the indentation settings, this patch removes
these as well for the Vim 6.0 and newer versions.
With the removal of local variables for certain editors such as
Emacs and Vim, the footer is also probably not needed anymore when
creating extensions using ext_skel.php script.
Additionally, Vim modelines for setting php syntax and some editor
settings has been removed from some *.phpt files. All these are
mostly not relevant for phpt files neither work properly in the
middle of the file.
RFC: https://wiki.php.net/rfc/typed_properties_v2
This is a squash of PR #3734, which is a squash of PR #3313.
Co-authored-by: Bob Weinand <bobwei9@hotmail.com>
Co-authored-by: Joe Watkins <krakjoe@php.net>
Co-authored-by: Dmitry Stogov <dmitry@zend.com>
Albeit CSV is still a widespread data exchange format, it has never been
officially standardized. There exists, however, the “informational” RFC
4180[1] which has no notion of escape characters, but rather defines
`escaped` as strings enclosed in double-quotes where contained
double-quotes have to be doubled. While this concept is supported by
PHP's implementation (`$enclosure`), the `$escape` sometimes interferes,
so that `fgetcsv()` is unable to correctly parse externally generated
CSV, and `fputcsv()` is sometimes generating non-compliant CSV. Since
PHP's `$escape` concept is availble for many years, we cannot drop it
for BC reasons (even though many consider it as bug). Instead we allow
to pass an empty string as `$escape` parameter to the respective
functions, which results in ignoring/omitting any escaping, and as such
is more inline with RFC 4180. It is noteworthy that this is almost no
userland BC break, since formerly most functions did not accept an empty
string, and failed in this case. The only exception was `str_getcsv()`
which did accept an empty string, and used a backslash as escape
character then (which appears to be unintended behavior, anyway).
The changed functions are `fputcsv()`, `fgetcsv()` and `str_getcsv()`,
and also the `::setCsvControl()`, `::getCsvControl()`, `::fputcsv()`,
and `::fgetcsv()` methods of `SplFileObject`.
The implementation also changes the type of the escape parameter of the
PHP_APIs `php_fgetcsv()` and `php_fputcsv()` from `char` to `int`, where
`PHP_CSV_NO_ESCAPE` means to ignore/omit escaping. The parameter
accepts the same values as `isalpha()` and friends, i.e. “the value of
which shall be representable as an `unsigned char` or shall equal the
value of the macro `EOF`. If the argument has any other value, the
behavior is undefined.” This is a subtle BC break, since the character
`chr(128)` has the value `-1` if `char` is signed, and so likely would
be confused with `EOF` when converted to `int`. We consider this BC
break to be acceptable, since it's rather unlikely that anybody uses
`chr(128)` as escape character, and it easily can be fixed by casting
all `escape` arguments to `unsigned char`.
This patch implements the feature requests 38301[2] and 51496[3].
[1] <https://tools.ietf.org/html/rfc4180>
[2] <https://bugs.php.net/bug.php?id=38301>
[3] <https://bugs.php.net/bug.php?id=51496>
- move relevant parts into win32
- general cleanup
- use Windows API and fallback to POSIX
- improve filetime to timestamp conversion
- improve stat/fsat
- handle ino by using file index
- handle st_dev by using volume serial number
The inode implementation is based on file indexes from NTFS. On 32-bit,
fake inodes are shown, that may lead to unexpeted results. 64-bit
implementation is most reliable.
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.
zval_dtor() doesn't make a lot of sense in PHP-7.* and it's used incorrectly in some places.
Its occurances should be replaced by zval_ptr_dtor() or zval_ptr_dtor_nogc(), or even more specialized destructors.
The slower I/O as a traditional bottleneck on Windows which is
the target of this patch. The recursive path resolution, while being
an allround solution, is expensive when it comes to the common case.
Files with proper ACLs set can be resolved in one go by usage of specific
API. Those are available since Vista, so actually can be called old. Those
simpler api is used for the cases where no CWD_EXPAND is requested. For
the cases where ACLs are improper, the existing solution based on
FindFirstFile still does good job also partially providing quirks. Cases
involing reparse tags and other non local filesystems are also partially
server by new APIs.
The approach uses both APIs - the quick one for the common case still
integrating realpath cache, and the existing one as a fallback. The tests
show the I/O load drop on the realpath resolution part due to less
system calls for the sub part resolution of paths. In most case it is
justified, as the sub parts were otherwise cached or unused as well. The
realpath() implementation in ioutil is also closer to the POSIX.
This patch however does not drop support for the BeOS compatible variant, Haiku, see Github PR #2697 which is currently a WiP
I intentionally left out some fragments for BeOS in the build system for that seems to be bundles
If this does not break the Unix system somehow, I'll be amazed. This should get most of it out, apologies for any errors this may cause on non-Windows ends which I cannot test atm.
