Commit 6821b671 authored by Mark A. Hershberger's avatar Mark A. Hershberger

Imported Upstream version 5.3.0RC1

parent cd0b49c7

Too many changes to show.

To preserve performance only 1000 of 1000+ files are displayed.

......@@ -2,13 +2,16 @@ define ____executor_globals
if basic_functions_module.zts
set $tsrm_ls = ts_resource_ex(0, 0)
set $eg = ((zend_executor_globals) (*((void ***) $tsrm_ls))[executor_globals_id-1])
set $cg = ((zend_compiler_globals) (*((void ***) $tsrm_ls))[compiler_globals_id-1])
else
set $eg = executor_globals
set $cg = compiler_globals
end
end
document ____executor_globals
portable way of accessing executor_globals, set $eg
this also sets compiler_globals to $cg
ZTS detection is automatically based on ext/standard module struct
end
......@@ -46,8 +49,8 @@ define ____printzv_contents
set $zvalue = $arg0
set $type = $zvalue->type
printf "(refcount=%d", $zvalue->refcount
if $zvalue->is_ref
printf "(refcount=%d", $zvalue->refcount__gc
if $zvalue->is_ref__gc
printf ",is_ref"
end
printf ") "
......
<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
<name>php-5.2</name>
<name>php-5.3</name>
<comment></comment>
<projects>
</projects>
......
This diff is collapsed.
This diff is collapsed.
--------------------------------------------------------------------
The PHP License, version 3.01
Copyright (c) 1999 - 2006 The PHP Group. All rights reserved.
Copyright (c) 1999 - 2009 The PHP Group. All rights reserved.
--------------------------------------------------------------------
Redistribution and use in source and binary forms, with or without
......
......@@ -7,7 +7,7 @@ $(builddir)/zend_language_scanner.lo: $(srcdir)/zend_language_parser.h
$(builddir)/zend_ini_scanner.lo: $(srcdir)/zend_ini_parser.h
$(srcdir)/zend_language_scanner.c: $(srcdir)/zend_language_scanner.l
@$(LEX) -Pzend -S$(srcdir)/flex.skl -o$@ -i $(srcdir)/zend_language_scanner.l
@(cd $(top_srcdir); $(RE2C) $(RE2C_FLAGS) --case-inverted -cbdFt Zend/zend_language_scanner_defs.h -oZend/zend_language_scanner.c Zend/zend_language_scanner.l)
$(srcdir)/zend_language_parser.h: $(srcdir)/zend_language_parser.c
$(srcdir)/zend_language_parser.c: $(srcdir)/zend_language_parser.y
......@@ -18,6 +18,6 @@ $(srcdir)/zend_ini_parser.c: $(srcdir)/zend_ini_parser.y
@$(YACC) -p ini_ -v -d $(srcdir)/zend_ini_parser.y -o $@
$(srcdir)/zend_ini_scanner.c: $(srcdir)/zend_ini_scanner.l
@$(LEX) -Pini_ -S$(srcdir)/flex.skl -o$@ -i $(srcdir)/zend_ini_scanner.l
@(cd $(top_srcdir); $(RE2C) $(RE2C_FLAGS) --case-inverted -cbdFt Zend/zend_ini_scanner_defs.h -oZend/zend_ini_scanner.c Zend/zend_ini_scanner.l)
$(builddir)/zend_indent.lo $(builddir)/zend_highlight.lo $(builddir)/zend_compile.lo: $(srcdir)/zend_language_parser.h
......@@ -61,6 +61,9 @@ php_lcov.info: lcov-test
test -f "$$x.bb" && cp $$x.bb lcov_data/$$y.bb ; \
test -f "$$x.bbg" && cp $$x.bbg lcov_data/$$y.bbg ; \
done
for dir in ext/bcmath/libbcmath ext/date/lib ext/fileinfo/libmagic ext/gd/libgd ext/mbstring/libmbfl ext/mbstring/oniguruma ext/pcre/pcrelib ext/pdo_sqlite/libsqlite ext/sqlite/libsqlite ext/sqlite3/libsqlite ext/xmlrpc/libxmlrpc ext/zip/lib; do \
test -d lcov_data/$$dir && rm -rf lcov_data/$$dir ; \
done
@echo
@echo "Generating $@"
@$(LTP) --directory lcov_data/ --capture --base-directory=lcov_data --output-file $@
......
This diff is collapsed.
====================
CVS Commit Rules
====================
This is the first file you should be reading after you get your CVS account.
We'll assume you're basically familiar with CVS, but feel free to post
your questions on the mailing list. Please have a look at
your questions on the mailing list. Please have a look at
http://cvsbook.red-bean.com/ for more detailed information on CVS.
PHP is developed through the efforts of a large number of people.
Collaboration is a Good Thing(tm), and CVS lets us do this. Thus, following
some basic rules with regards to CVS usage will:
some basic rules with regards to CVS usage will::
a. Make everybody happier, especially those responsible for maintaining
the CVS itself.
b. Keep the changes consistently well documented and easily trackable.
c. Prevent some of those 'Oops' moments.
d. Increase the general level of good will on planet Earth.
d. Increase the general level of good will on planet Earth.
Having said that, here are the organizational rules:
Having said that, here are the organizational rules::
1. Respect other people working on the project.
2. Discuss any significant changes on the list before committing.
2. Discuss any significant changes on the list before committing and get
confirmation from the release manager for the given branch.
3. Look at EXTENSIONS file to see who is the primary maintainer of
the code you want to contribute to.
......@@ -30,45 +37,54 @@ Having said that, here are the organizational rules:
6. Test your changes before committing them. We mean it. Really.
To do so use "make test".
7. For development use the --enable-maintainer-zts switch to ensure your
code handles TSRM correctly and doesn't break for thos who need that.
Currently we have the following branches in use:
HEAD Will become PHP 6.0. This CVS branch is for active development.
PHP_5_2 Is used to release the PHP 5.2.x series. Only minor feature
enhancements may go in here, but please keep that as infrequent as
possible.
PHP_5_1 This branch is closed.
PHP_4_4 Is used to release the PHP 4.4.x series. Only bugfixes are permitted
on this branch (Consult the releasemaster prior to commit).
PHP_4_3 This branch is closed.
Currently we have the following branches in use::
HEAD Will become PHP 6.0. This CVS branch is for active development.
PHP_5_3 Is used to release the PHP 5.3.x series. It still allows for
larger enhancements.
The next few rules are more of a technical nature.
PHP_5_2 Is used to release the PHP 5.2.x series. Only bugfixes are permitted
on this branch (Consult the releasemaster prior to commit).
1. DO NOT TOUCH ChangeLog! It is automagically updated from the commit
PHP_5_1 This branch is closed.
PHP_4_4 This branch is closed.
The next few rules are more of a technical nature::
1. All changes should first go to HEAD and then get merged from HEAD
(aka MFH'ed) to all other relevant branches.
2. DO NOT TOUCH ChangeLog! It is automagically updated from the commit
messages every day. Woe be to those who attempt to mess with it.
2. All news updates intended for public viewing, such as new features,
bug fixes, improvements, etc., should go into the NEWS file.
3. All news updates intended for public viewing, such as new features,
bug fixes, improvements, etc., should go into the NEWS file of the
*first* to be released version with the given change. In other words
any NEWS file change only needs to done in one branch.
NB! Lines, starting with @ will go automagically into NEWS file, but
this is NOT recommended, though. Please, add news entries directly to
this is NOT recommended, though. Please, add news entries directly to
NEWS file and don't forget to keep them adjusted and sorted.
3. Do not commit multiple file and dump all messages in one commit. If you
4. Do not commit multiple file and dump all messages in one commit. If you
modified several unrelated files, commit each group separately and
provide a nice commit message for each one. See example below.
4. Do write your commit message in such a way that it makes sense even
5. Do write your commit message in such a way that it makes sense even
without the corresponding diff. One should be able to look at it, and
immediately know what was modified. Definitely include the function name
in the message as shown below.
5. In your commit messages, keep each line shorter than 80 characters. And
6. In your commit messages, keep each line shorter than 80 characters. And
try to align your lines vertically, if they wrap. It looks bad otherwise.
6. If you modified a function that is callable from PHP, prepend PHP to
7. If you modified a function that is callable from PHP, prepend PHP to
the function name as shown below.
......@@ -80,7 +96,7 @@ If a line begins with #, it is taken to be a comment and will not appear
in the ChangeLog. Everything else goes into the ChangeLog.
It is important to note that if your comment or news logline spans multiple
lines, you have to put # at the beginning of _every_ such line.
lines, you have to put # at the beginning of **every** such line.
Example. Say you modified two files, datetime.c and string.c. In datetime.c you
added a new format option for the date() function, and in string.c you fixed a
......@@ -88,13 +104,15 @@ memory leak in php_trim(). Don't commit both of these at once. Commit them
separately and try to make sure your commit messages look something like the
following.
For datetime.c:
- Added new 'K' format modifier to date() for printing out number of days until
New Year's Eve.
For datetime.c::
- Added new 'K' format modifier to date() for printing out number of days
until New Year's Eve.
For string.c:
- Fixed a memory leak in php_trim() resulting from improper use of zval_dtor().
#- Man, that thing was leaking all over the place!
For string.c::
- Fixed a memory leak in php_trim() resulting from improper use of zval_dtor().
#- Man, that thing was leaking all over the place!
The # lines will be omitted from the ChangeLog automagically.
......@@ -106,13 +124,16 @@ If you fix some bugs, you should note the bug ID numbers in your
commit message. Bug ID should be prefixed by "#" for easier access to
bug report when developers are browsing CVS via LXR or Bonsai.
Example:
Example::
Fixed bug #14016 (pgsql notice handler double free crash bug.)
Fixed bug #14016 (pgsql notice handler double free crash bug.)
If you don't see your messages in ChangeLog right away, don't worry!
These files are updated once a day, so your stuff will not show up until
somewhat later.
somewhat later.
When you change the NEWS file for a bug fix, then please keep the bugs
sorted in decreasing order under the fixed version.
You can use LXR (http://lxr.php.net/) and Bonsai (http://bonsai.php.net/)
to look at PHP CVS repository in various ways.
......
......@@ -96,29 +96,7 @@ OTHER OPTIONS
function entries and definitions at the end of the file, for copying and
pasting into an already existing module.
--assign-params
--string-lens
By default, function proto 'void foo(string bar)' creates the following:
...
zval **bar;
... (zend_get_parameters_ex() called in the middle...)
convert_to_string_ex(bar);
Specifying both of these options changes the generated code to:
...
zval **bar_arg;
int bar_len;
char *bar = NULL;
... (zend_get_parameters_ex() called in the middle...)
convert_to_string_ex(bar_arg);
bar = Z_STRVAL_PP(bar_arg);
bar_len = Z_STRLEN_PP(bar_arg);
You shouldn't have to ask what happens if you leave --string-lens out. If you
have to, it's questionable whether you should be reading this document.
--with-xml[=file]
--xml[=file]
Creates the basics for phpdoc .xml file.
......@@ -156,39 +134,32 @@ EXAMPLE
question marks to be replaced by you, and you must of course add your own
value definitions too):
/* {{{ proto bool my_drawtext(resource image, string text, resource font, int x, int y[, int color])
/* {{{ proto bool my_drawtext(resource image, string text, resource font, int x, int y [, int color])
*/
PHP_FUNCTION(my_drawtext)
{
zval **image, **text, **font, **x, **y, **color;
int argc;
int image_id = -1;
int font_id = -1;
argc = ZEND_NUM_ARGS();
if (argc < 5 || argc > 6 || zend_get_parameters_ex(argc, &image, &text, &font, &x, &y, &color) == FAILURE) {
WRONG_PARAM_COUNT;
}
ZEND_FETCH_RESOURCE(???, ???, image, image_id, "???", ???_rsrc_id);
ZEND_FETCH_RESOURCE(???, ???, font, font_id, "???", ???_rsrc_id);
switch (argc) {
case 6:
convert_to_long_ex(color);