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
PHP requires boolean typehints to be written "bool" and disallows
"boolean" as an alias. This changes the error messages to match
the actual type name and avoids confusing messages like "must be
of type boolean, boolean given".
This a followup to ce1d69a1f6, which
implements the same change for integer->int.
PHP requires integer typehints to be written "int" and does not
allow "integer" as an alias. This changes type error messages to
match the actual type name and avoids confusing messages like
"must be of the type integer, integer given".
* PHP-5.6:
Fixed test
Added validation to parse_url() to prohibit restricted characters inside login/pass components based on RFC3986
Apparently negative wordwrap is a thing and should work as length = 0.
If a colon occurs in a query string or fragment of a partial URL without
scheme, parse_url() tries to regard it as port separator. If up to 5 digits
follow and then a slash or the end of the string, parse_url() fails.
We're fixing this by checking whether the colon is part of the query string or
the fragment, under the assumption that question marks and hash signs are only
allowed as separators of query string and fragments, respectively, what is
guarenteed for URIs (RFC 3986), but not necessarily for URLs (RFC 1738) where
question marks are allowed for usernames and passwords.
Anyhow, this constitutes a minor BC, so the fix is applied to master only.
Empty usernames and passwords are now treated differently from no username or password
For example, empty password:
ftp://user:@example.org
Empty username:
ftp://:password@example.org
Empty username and empty password
ftp://:@example.org
Peter Kokot