[PHP-DEV] Can't report PHP bugs
I'm trying to report a bug at: http://bugs.php.net/report.php At the top of the page I always see: Authentication failed: incorrect username Authentication failed: incorrect username This is true even if I clear cookies (to remove any possible traces of an unsuccessful login attempt perhaps). On the first try I make it to the "are you sure this is a new bug?" page. When I attempt to confirm, I get this: Authentication failed: Incorrect username Authentication failed: Incorrect username Warning: Cannot modify header information - headers already sent by (output started at /home/Web/sites/php-bugs-web/include/auth.inc:30) in /home/Web/sites/php-bugs-web/report.php on line 201 Also, I'm attempting to follow previous advice to this list regarding submitting fixes for documentation bugs by preparing a diff. But it's not apparent whether I should be pasting diffs into the bug tracker, and my attempts to check out the documentation from the indicated place aren't working anyway: svn co http://svn.php.net/phpdoc/en/trunk/reference/session session svn: Repository moved temporarily to '/viewvc/phpdoc/en/trunk/reference/session'; please relocate Macintosh-4:tmp boutell$ svn ls http://svn.php.net/viewvc/phpdoc/en/trunk/reference/session svn: Repository moved permanently to '/viewvc/phpdoc/en/trunk/reference/session/'; please relocate ??? I give up (for now). This is more time than I have to report a simple documentation problem and provide a suggested replacement. The actual bug report follows, in case someone who maintains documentation is watching and may be able to take advantage of it. * * * The description of session.gc_max_lifetime (as well as its name) imply that it is the maximum lifetime of a session. In actuality it is just the session timeout. This problem exists in both php.ini-dist/php.ini- production and in the online reference manual. I considered sending a diff but it's not clear to me where to send it. * * * The current text: ; After this number of seconds, stored data will be seen as 'garbage' and ; cleaned up by the garbage collection process. session.gc_maxlifetime = 1440 Suggested replacement: ; Session idle timeout. If a session is idle for this number ; of seconds, and PHP's default session handling is in use, ; the session data will potentially be cleaned up by the ; garbage collection process. Note that custom session ; handlers can override this (see session_set_save_handler ). ; The default timeout is 1440 seconds (24 minutes). session.gc_maxlifetime = 1440 -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Update: the bug is in there (but who could tell?)
Turns out three bug submissions did go through. I went back and deleted two, leaving only bug #49335. The lack of any indication that it worked, and the mostly-whitescreen-and-an-error end result of the process, are still issues of course. -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mail() and header folding/line endings
Wietse: On Fri, Aug 21, 2009 at 04:41:31PM -0400, Wietse Venema wrote: > The Postfix sendmail command prefers input in native UNIX stream-lf > format. Postfix will jump some hoops for software that wants to > use the non-native CRLF format. It uses a switch (going from using > LF to using CRLF) and therefore it won't accept mixed line endings. Thanks. I can understand not accepting mixed line endings, I just wanted to understand what exactly I should tell people since the two answers seemed to conflict with each other. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] How to handle hand along data in PHP's parser?
Hi internals:
Currently, I try to port my Traits patch to the latest version of trunk.
Thought about giving you people the chance to play with it again.
Unfortunately, I have some trouble with the parser.
Think, there must have changed quite something in its internal working.
The last time I touched it, I had no problems handing around pointers
in $$.u.var,
but nowadays, it looks like it is overwritten before it can be used by
the other grammar rule.
The original idea was to construct as many data during the compilation
phase to avoid introducing a whole of a lot new opcodes.
But, I am grateful for all suggestion about alternative implementation
strategies.
For the problem at hand, here some code:
trait_adaptation_statement:
/* here I emit a opcode to add a new alias or precedence rule to a
class */
trait_precedence ';' { zend_add_trait_precedence(&$1 TSRMLS_CC); }
| trait_alias ';' { zend_add_trait_alias(&$1 TSRMLS_CC); }
;
trait_precedence:
/* This rule constructs a struct with the necessary data and should
return
a pointer to it in $$.u.var */
trait_method_reference_fully_qualified T_INSTEAD
trait_reference_list
{ zend_prepare_trait_precedence(&$$, &$1, &$3 TSRMLS_CC); }
;
trait_reference_list:
fully_qualified_class_name
{ zend_init_list(&$$.u.var, Z_STRVAL($1.u.constant) TSRMLS_CC); }
| trait_reference_list ',' fully_qualified_class_name
{ zend_add_to_list(&$1.u.var, Z_STRVAL($3.u.constant) TSRMLS_CC);
$$ = $1; }
;
trait_method_reference_fully_qualified:
fully_qualified_class_name T_PAAMAYIM_NEKUDOTAYIM T_STRING
{ zend_prepare_reference(&$$, &$1, &$3 TSRMLS_CC); }
;
The code is basically unchanged from
http://www.stefan-marr.de/traits/traits.patch
My problem starts already with trait_method_reference_fully_qualified.
I am not able to get the struct which I assigned to $$.u.var in
trait_precedence.
From what XCode tells me, the memory location of $$ gets overwritten
before.
Think, it is on the stack somewhere and does not survive long enough
to be
available in trait_precedence.
Any thoughts on that?
Many thanks and best regards
Stefan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] GD - imagecolorallocatealpha
First time suggesting a patch, please correct me if i do something wrong.
I was writing tests for imagecolorallocatealpha and noticed a change applied
in 5.3 is not in head, that is the validation of the first parameter,
delacred as 'r' in 5.3 and 'z' in HEAD (also in 5.2)
This is not a absolute problem since there is a resource type validation
right after looking for Image Resource. So i don't know how important this
fix is, but i wrote the patch below and it worked according to my tests.
I will also be commiting the tests in a few minutes.
PATCH:
Index: ext/gd/gd.c
===
--- ext/gd/gd.c(revision 287587)
+++ ext/gd/gd.c(working copy)
@@ -1729,7 +1729,7 @@
gdImagePtr im;
int ct = (-1);
-if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "z", &IM,
&red, &green, &blue, &alpha) == FAILURE) {
+if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "r", &IM,
&red, &green, &blue, &alpha) == FAILURE) {
RETURN_FALSE;
}
Cheers everyone!
--
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br
[PHP-DEV] unscribe mail
[PHP-DEV] Dead code
Hi list, Apparently, function _php_math_basetolong at http://lxr.php.net/source/php-src/ext/standard/math.c#802 isn't used anymore since Mon Sep 3 16:26:31 2001 UTC. It was previously used by bindec, hexdec, octdec and base_convert functions but has been replaced by _php_math_basetozval(). None of the PECL extension are using it either (at least in http://svn.php.net/repository/pecl/*/trunk/). Any objection I remove it? -- Patrick --- http://code.google.com/p/peclapm/ - Alternative PHP Monitor -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
