Update http->https in license (#6945)

1. Update: http://www.php.net/license/3_01.txt to https, as there is anyway server header "Location:" to https.
2. Update few license 3.0 to 3.01 as

Update http->https in license (#6945)

1. Update: http://www.php.net/license/3_01.txt to https, as there is anyway server header "Location:" to https.
2. Update few license 3.0 to 3.01 as 3.0 states "php 5.1.1, 4.1.1, and earlier".
3. In some license comments is "at through the world-wide-web" while most is without "at", so deleted.
4. fixed indentation in some files before |

show more ...

Fix a few comments

Remove proto comments from C files

Closes GH-5758

Generate method entries for ext/intl

Closes GH-5370

Use RETURN_THROWS() after zend_parse_method_parameters()

Cleanup return values for Intl when parameter parsing is unsuccessful

Closes GH-4871.

Remove mention of PHP major version in Copyright headers

Closes GH-4732.

Sync leading and final newlines in source code files

This patch adds missing newlines, trims multiple redundant final
newlines into a single one, and trims redundant leading newlines.

Sync leading and final newlines in source code files

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

show more ...

fix include order

Added ZEND_ATTRIBUTE_FORMAT to some middind functions.
"%p" replaced by ZEND_LONG_FMT to avoid compilation warnings.
Fixed most incorrect use cases of format specifiers.

trailing whitespace removal

first shot remove TSRMLS_* things

s/PHP 5/PHP 7/

master renames phase 1

fixes to %pd format usage

basic macro replacements, all at once

Refactoring ext/intl (incompleted)

Merge branch '5.4'

* 5.4:
Fix test title and limit it to ICU >= 4.8
Remove executable bit from files
Limit test to ICU 49
Remove executable bit from files

Remove executable bit from files

Leak caused by wrong and unreachable cleanup

Added IntlDateFormatter::formatObject(). Refactor

To better support IntlCalendar, added this function:

string IntlDateFormatter::formatObject(IntlCalendar|DateTime $obj [,

Added IntlDateFormatter::formatObject(). Refactor

To better support IntlCalendar, added this function:

string IntlDateFormatter::formatObject(IntlCalendar|DateTime $obj [,
array|int|string $format = null [, string $locale = null).

$format is either of the constants IntlDateFormatter::FULL, etc., in
which case this format applies to both the date and the time, an array
in the form array($dateFormat, $timeFormat), or a string with the
SimpleDateFormat pattern.

This uses both the Calendar type and the timezone of the passed object
to configure the formatter (a GregorianCalendar is forced for
DateTime).

Some stuff was moved around and slighlt modified to allow for more code
reuse.

show more ...

Refactored internal_get_timestamp()

Added bounds checking for 32-bit ints.

Do not fetch array elements that ::parse() generates but that
::format() does not actually care about.y

Unified zval -> UDate conversions

Now IntlDateFormatter::format() also accepts IntlCalendar objects.
Code is shared in MessageFormatter and IntlDateFormatter.

DateFormat plays nice with Calendar, TimeZone

The following changes were made:

* The IntlDateFormatter constructor now accepts the usual values
for its $timezone argument. Thi

DateFormat plays nice with Calendar, TimeZone

The following changes were made:

* The IntlDateFormatter constructor now accepts the usual values
for its $timezone argument. This includes timezone identifiers,
IntlTimeZone objects, DateTimeZone objects and NULL. An empty
string is not accepted. An invalid time zone is no longer accepted
(it used to use UTC in this case).
* When NULL is passed to IntlDateFormatter, the time zone specified in
date.timezone is used instead of the ICU default.
* The IntlDateFormatter $calendar argument now accepts also an
IntlCalendar. In this case, IntlDateFormatter::getCalendar() will
return false.
* The time zone passed to the IntlDateFormatter is ignored if it is
NULL and if the calendar passed is an IntlCalendar object -- in this
case, the IntlCalendar time zone will be used instead. Otherwise,
the time zone specified in the $timezone argument is used instead.
* Added IntlDateFormatter::getCalendarObject(), which always returns
the IntlCalendar object that backs the DateFormat, even if a
constant was passed to the constructor, i.e., if an IntlCalendar
was not passed to the constructor.
* Added IntlDateFormatter::setTimeZone(). It accepts the usual values
for time zone arguments. If NULL is passed, the time zone of the
IntlDateFormatter WILL be overridden with the default time zone,
even if an IntlCalendar object was passed to the constructor.
* Added IntlDateFormatter::getTimeZone(), which returns the time zone
that's associated with the DateFormat.
* Depreacated IntlDateFormatter::setTimeZoneId() and made it an alias
for IntlDateFormatter::setTimeZone(), as the new ::setTimeZone()
also accepts plain identifiers, besides other types.
IntlDateFormatter::getTimeZoneId() is not deprecated however.
* IntlDateFormatter::setCalendar() with a constant passed should now
work correctly. This requires saving the requested locale to the
constructor.
* Centralized the hacks required to avoid compilation disasters on
Windows due to some headers being included inside and outside of
extern "C" blocks.

show more ...

- Fixed ZTS build