Re: [PHP-DEV] Coverity Scan
On Sat, Aug 06, 2011 at 08:07:01PM -0700, Rasmus Lerdorf wrote: Coverity has run a new scan of trunk and there are a lot of valid issues. You have probably noticed that I have started to fix some of them, but there are 500+ to go, so I could use some help. The following people already have Coverity accounts: andi, antony, colder, derick, dmitry, helly, iliaa, jcogg, joey, kmori, mike, nickpj, nlopess, phoddie, rui, sas, scottmac, sean, sesser, slif, steph, tgoldstein, thiago, wez and zeev If you would like to help out and you don't have an account, please send me an email or catch me on irc and I will get you set up. Once you have an account, go to: http://scan.coverity.com/rung2.html And click on the Sign in link next to PHP If you start working on fixing one of these, please assign it to yourself first within the Coverity UI so others will know. -Rasmus A lot of the 'STACK_USE' ones seem to be false positives; it's reporting when the stack exceeds the maximum single use of 1024 bytes - that 1024 is a Coverity-configurable value which defaults to 1024. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Coverity Scan
On Tue, Aug 09, 2011 at 12:19:53AM -0700, Rasmus Lerdorf wrote: On 08/08/2011 11:45 PM, Joey Smith wrote A lot of the 'STACK_USE' ones seem to be false positives; it's reporting when the stack exceeds the maximum single use of 1024 bytes - that 1024 is a Coverity-configurable value which defaults to 1024. Yup, we can simply mark those as intentional/ignore although it wouldn't be a bad idea to have a quick look at each one to see if we really need to chew up 1k of stack on each of those occasions. People using PHP in embedded systems would appreciate that, I bet. -Rasmus Quite a few of the ones I looked at were reporting it due to MAXPATHLEN, which I imagine we probably want to leave untouched - I'll just mark those as intentional/ignore. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reflection, Traits, Aliasing
On Mon, Aug 08, 2011 at 03:52:37PM +0100, Keloran wrote: There seems to be a bug in traits that if you use any of the GLOBAL vars it segfaults snip I'm not sure it's clear from Keloran's code example here, so I thought I'd point out that the problem only seems to happen if you include the trait definition from an external file. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Choosing a distributed version control system for PHP (or not). Call for Participation.
On Sun, Aug 07, 2011 at 04:50:55PM -0400, David Soria Parra wrote: Hi Internals, NOTE: this is not the place for any religiouise discussion about git vs mercurial whatsover. if you have nothing else to add than hg is $*** anyway or think hosting platform XY will solve all our problems without reading the RFC carefully, please post to alt.relgion.* and not here. - David I feel like maybe the RFC throws in the towel too early on the idea of using SSH keys to manage access control. On the git side, there's a tool called gitolite which makes management of access controls via SSH keys incredibly trivial. While I've never looked at the code behind the online Manager Users tool we have, I can't imagine it would be terribly hard to expand that to allow people to add their public SSH keys for plugging into gitolite [1]. [1] https://github.com/sitaramc/gitolite -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] BUG 55240 - wrong date creation
On Thu, Aug 04, 2011 at 01:06:38AM +0800, Laruence wrote: Hi: I read the ext/date/lib/parse_date.c, and I think this could not be a bug , since 800 will be think as 80h 0min(timelib_get_nr is common function, to get number from data description string with fixed max length), than 11 + (80 / 24) ~= 14 thanks 2011/8/4 Nicolai Scheer sc...@planetavent.de: Hi! Did anyone had the time to review bug 55240 (https://bugs.php.net/bug.php?id=55240), yet? So far it just has been adjusted to reflect the right package. Any pointers are welcome! Grettings, Nico -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php It definitely appears to be unexpected behaviour - the 'G' format for hours is 24-hour format without leading zeroes - so the expectation would be that 'Gi' parses '800' as '8 hours and 0 minutes'. (Also, I thought I would point out here that the comments on 'G' and 'H', in timelib_parse_from_format are backwards here - same with 'g' and 'h'.) It's an ambiguous format...you would have the same issue with 'g' or 'n', here...timelib_get_nr() is going to consume as many numbers as it can (2) unless it hits a non-number first. Just some examples: DateTime::createFromFormat(dn, 118) -- Did you mean August 11th, November 8th, or June 1st? DateTime::createFromFormat(gi, 800) -- This is an actual error, as 'g' rejects values higher than 12 The simplest fix here is probably to have 'G' throw the same error as 'g' when the hours component is greater than 24 - however, I don't think it would be that much harder to have both 'g' and 'G' do the expected thing, here: push the pointer back two characters and try again with a max_length of 1 to see if they can parse it that way. The question, I suppose, is whether that's something we WANT to do - I had written about half of the required patch before I thought I should probably ask the question first. :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] BUG 55240 - wrong date creation
On Wed, Aug 03, 2011 at 01:29:54PM -0600, Joey Smith wrote: DateTime::createFromFormat(dn, 118) -- Did you mean August 11th, November 8th, or June 1st? Pardon my idiocy, here - it's quite clear that November 8th wouldn't be a possible meaning here - I collapsed a couple of examples together and failed to fix the commentary. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] c and php operations
On Fri, Jul 29, 2011 at 02:20:17PM -0300, Adir Kuhn wrote:
Hello guys,
while I'm studing some c codes i found this page:
http://www.nicksays.co.uk/2009/05/awesome-c-exam-question/
and this code:
#include stdio.h
int func (int a, int b) {
static int c = 1;
return a + b * (c *= -1);}
int main () {
int a = 2, b = 3;
int c = func(a, b);
a *= a++;
b *= ++b;
I'm no expert in C, but my understanding is that the two expressions immediately
above are UNDEFINED because there is only one sequence point, but the objects
are
modified twice (*= and ++). See http://c-faq.com/expr/seqpoints.html
gcc appears to agree with me via the -Wsequence-point flag:
joey@banshee:0$cat a.c
#include stdio.h
int func (int a, int b) {
static int c = 1;
return a + b * (c *= -1);
}
int main () {
int a = 2, b = 3;
int c = func(a, b);
a *= a++;
b *= ++b;
printf(%d %d %d %d\n, a, b, c, func(a, b));
}
joey@banshee:0$gcc -Wsequence-point a.c
a.c: In function ‘main’:
a.c:12:4: warning: operation on ‘a’ may be undefined
a.c:13:4: warning: operation on ‘b’ may be undefined
If my interpretation is correct, I'm not sure how much time we need to spend
around the question.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] crypt_blowfish 1.2
On Sun, Jul 17, 2011 at 10:26:16PM +0400, Solar Designer wrote: + * For actual implementation, we set an array index in the variable bug + * (0 means no bug, 1 means sign extension bug emulation) and a flag in the + * variable safety (bit 16 is set when the safety measure is requested). + * Valid combinations of settings are: + * + * Prefix $2a$: bug = 0, safety = 0x1 + * Prefix $2x$: bug = 1, safety = 0 + * Prefix $2y$: bug = 0, safety = 0 If I'm understanding the change correctly, we should now be advising users to transition their code to '$2y$' rather than '$2a$', with perhaps a note mentioning the '$2x$' prefix for transitioning users with passwords that contain non-ASCII characters with the 8th bit set. Obviously, any documentation change in this regard will need to be pending on the version these patches get rolled into... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Req #51295: busyTimeout method for SQLite3
On Sun, Mar 14, 2010 at 09:15:37AM -0400, Wez Furlong wrote: I'm sure that the docs team will add this to the manual if you ask them politely. Specifically, PDO_SQLITE defaults to a 60 second busy timeout. This can be changed by setting PDO::ATTR_TIMEOUT. The value is specified in seconds. ISTR that this option can also be specified for some of the other database drivers to affect the network timeout when processing a query. A nod's as good as a wink. :) This has been committed. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On closures and lamdba
Oh, yes, the question:
Wouldn't you agree that it is better for PHP to use the word closure as
it is being used in the JavaScript community?
There's a pretty big difference between how PHP implements closures and how
JavaScript implements them - in PHP, you have to explicitly request which
variables will be bound to the closure. Here's an example I've been using
on Freenode's ##PHP to demonstrate how a PHP closure might work.
=
$array = array(
array('foo' = 17, 'bar'='last'),
array('foo' = 1, 'bar'='first'),
array('foo' = 3, 'bar'='middle'),
);
function buildSorter($key) {
return function ($a, $b) use ($key) {
if ($a[$key] == $b[$key]) return 0; return ($a[$key]
$b[$key]) ? -1:1;
};
}
$sort = buildSorter('foo');
usort($array, $sort);
var_dump($array);
=
Not an example that's going to rock anyone's world, obviously, but I think
it's illustrative.
However, because of an implementation detail (all anonymous functions are
now implemented as instance of class 'Closure'), it might be hard to enforce a
strict use of the word 'closure' here - although, it *is* kind of interesting
to look at a var_dump() of $sort:
object(Closure)#1 (2) {
[static]=
array(1) {
[key]=
string(3) foo
}
[parameter]=
array(2) {
[$a]=
string(10) required
[$b]=
string(10) required
}
}
Unfortunately, we're not allowed to query for that 'static' property
(Catchable fatal error: Closure object cannot have properties) and are
are explicitly discouraged from relying on this detail of implementation
(Anonymous functions are currently implemented using the Closure class.
This is an implementation detail and should not be relied upon.)
So to answer your question, for my money, since I can't currently tell the
difference in a programmatic way between an 'anonymous function' and a full
'closure', I don't find it that worrisome that the PHP world somewhat
conflates the two terms.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PATCH for bug #47199
If anyone ever needs me to host a patch, there's more than enough room at patch.joeysmith.com, just email me the patch as an attachment off-list. It'd probably be better than relying on a pastebin. On Tue, Feb 09, 2010 at 04:38:44PM +0100, Johannes Schlüter wrote: Hi, On Tue, 2010-02-09 at 20:11 +0500, Sokolov Evgeniy wrote: did you really run this test and was it successful? - doesn't looklike for me. I just run php tests/27_bug47199.phpt and check the result output. Is this correct way? The easy way to run it using the test Framework is by executing make test TESTS=tests/27_bug47199.phpt from your build directory which will prepare some environment things and then run run-tests.php from PHP's source directory which has the implementation of our test system, you can also run it directly to have more ocntrol. See README.TESTING in the php-src root folder and http://qa.php.net/write-test.php for more details on the test system. If you run your test it will tell you it failed as you're tests EXPECTF section has to look something like this: --EXPECTF-- DELETE FROM %s WHERE null_field IS NULL AND not_null_field=2; Done Mind the %s place holder there! And please also add a link to the patch to the bug report Can it be link on pastebin.org? For example http://pastebin.org/0 I don't know how persistent these pastebins are, http://news.php.net/php.internals/46965 might be an alternative link though :-) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] imap4 search criteria
There's an open bug on this, #15238 (http://bugs.php.net/bug.php?id=15238;). I'm sure patches would be welcomed. On Fri, Jan 29, 2010 at 03:49:18PM -0500, Dominik Gehl wrote: Hi, I noticed that the imap extension seems to support only IMAP2 search criteria. This is caused by the fact that in ext/imap/php_imap.c, the imap_search function uses a call to mail_criteria. And the University of Washington IMAP toolkit mentions in docs/internal.txt: SEARCHPGM *mail_criteria (char *criteria); criteria IMAP2-format search criteria string This function accepts an IMAP2-format search criteria string and parses it. If the parse is successful, it returns a search program suitable for use in mail_search_full(). WARNING: This function does not accept IMAP4 search criteria. Is there any specific reason why PHP uses this mail_criteria call ? It really would be nice to be able to use IMAP4 search criteria ! Thanks, Dominik -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Subscribe to PDO list (was Re: [PHP-DEV] [PATCH] PDO DBLIB)
On Fri, Jan 22, 2010 at 04:32:55AM +, Niel Archer wrote: Well whaddya-know! This time it worked for me, although 45 minutes wait seems long. I'd given up 20 minutes after the other requests had been answered. I had the same problem and waited several weeks between attempts, checking my inbox for the email to no avail. Finally, I realized Well, it's an ezmlm list, I can just send it commands, and this worked just fine - so if you want to subscribe to the PDO list, instead of trying to use the web interface (which appears to be broken for that list at least), you can just send an email to pdo-subscr...@lists.php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dots and spaces in variable names are converted to underscores.
On Wed, Jan 20, 2010 at 02:29:27PM -0800, Rasmus Lerdorf wrote: Well, that conversion still needs to happen somewhere, since plenty of apps call extract() on those superglobals, but with register_globals entirely gone in PHP 6, I suppose that conversion can be moved to the extract() call. -Rasmus I'm definitely +1 on moving that logic into extract() for PHP6. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] any solution about array_walk with pass-by-reference UseData?
This might be better served by taking it to php-general, because I don't
think you need to pin your question so hard to the behaviour of
array_walk(). Here's a quick example of (if I understood your question
correctly) how you might solve it using array_udiff_uassoc and 5.3's new
'closure' syntax (not required for this, but I do so enjoy using them!)
?php
$return=array();
$disable_full=array('a','b','c');
$disable_start=array('_','!','HTTP'/*,'ddd','ddd','ddd','ddd','ddd'*/);
$check_array=array(a=1,_POST='c',HTTP=f,ddd=array('fefe'));
function buildFilter($keys, $starts_with) {
return function ($a, $b) use ($keys, $starts_with) {
if (in_array($a, $keys)) return 0;
foreach($starts_with as $value) if (strpos($a, $value)===0) return 0;
return 1;
};
}
$foo = buildFilter($disable_full, $disable_start);
var_dump(array_udiff_uassoc($check_array, $disable_full, $disable_start,
function () { return 0; }, $foo));
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Passing error codes through to PDOException
Maybe I'm up in the night, but I've just opened 50728 because I discovered that
all
the PDO drivers had a hardcoded 0 where I would expect to see the
driver-specific
error - a user reported this in ##PHP on Freenode and I take a stab at writing
the
patches that would let the individual drivers pass their error code on to the
user.
They're attached to the bug as comments (the first against the tip of 5.3.2
[svn #293440] and the second against HEAD [svn #293440]) - but I'm also
attaching
them as udiffs to this email.
If there's a reason that the PDOExceptions don't contain their driver-specific
error codes, feel free to ignore this.
Index: ext/pdo_oci/oci_driver.c
===
--- ext/pdo_oci/oci_driver.c (revision 293440)
+++ ext/pdo_oci/oci_driver.c (working copy)
@@ -173,7 +173,7 @@
/* little mini hack so that we can use this code from the dbh ctor */
if (!dbh-methods) {
- zend_throw_exception_ex(php_pdo_get_exception(), 0 TSRMLS_CC, SQLSTATE[%s]: %s, *pdo_err, einfo-errmsg);
+ zend_throw_exception_ex(php_pdo_get_exception(), einfo-errcode TSRMLS_CC, SQLSTATE[%s]: %s, *pdo_err, einfo-errmsg);
}
return einfo-errcode;
Index: ext/pdo_dblib/dblib_driver.c
===
--- ext/pdo_dblib/dblib_driver.c (revision 293440)
+++ ext/pdo_dblib/dblib_driver.c (working copy)
@@ -255,7 +255,7 @@
dbh-driver_data = H;
if (!ret) {
- zend_throw_exception_ex(php_pdo_get_exception(), 0 TSRMLS_CC,
+ zend_throw_exception_ex(php_pdo_get_exception(), DBLIB_G(err).dberr TSRMLS_CC,
SQLSTATE[%s] %s (severity %d),
DBLIB_G(err).sqlstate,
DBLIB_G(err).dberrstr,
Index: ext/pdo_sqlite/sqlite_driver.c
===
--- ext/pdo_sqlite/sqlite_driver.c (revision 293440)
+++ ext/pdo_sqlite/sqlite_driver.c (working copy)
@@ -78,7 +78,7 @@
}
if (!dbh-methods) {
- zend_throw_exception_ex(php_pdo_get_exception(), 0 TSRMLS_CC, SQLSTATE[%s] [%d] %s,
+ zend_throw_exception_ex(php_pdo_get_exception(), einfo-errcode TSRMLS_CC, SQLSTATE[%s] [%d] %s,
*pdo_err, einfo-errcode, einfo-errmsg);
}
Index: ext/pdo_mysql/mysql_driver.c
===
--- ext/pdo_mysql/mysql_driver.c (revision 293440)
+++ ext/pdo_mysql/mysql_driver.c (working copy)
@@ -127,7 +127,7 @@
if (!dbh-methods) {
PDO_DBG_INF(Throwing exception);
- zend_throw_exception_ex(php_pdo_get_exception(), 0 TSRMLS_CC, SQLSTATE[%s] [%d] %s,
+ zend_throw_exception_ex(php_pdo_get_exception(), einfo-errcode TSRMLS_CC, SQLSTATE[%s] [%d] %s,
*pdo_err, einfo-errcode, einfo-errmsg);
}
Index: ext/pdo_firebird/firebird_driver.c
===
--- ext/pdo_firebird/firebird_driver.c (revision 293440)
+++ ext/pdo_firebird/firebird_driver.c (working copy)
@@ -691,7 +691,7 @@
char errmsg[512];
ISC_STATUS *s = H-isc_status;
isc_interprete(errmsg, s);
- zend_throw_exception_ex(php_pdo_get_exception(), 0 TSRMLS_CC, SQLSTATE[%s] [%d] %s,
+ zend_throw_exception_ex(php_pdo_get_exception(), H-isc_status[1] TSRMLS_CC, SQLSTATE[%s] [%d] %s,
HY000, H-isc_status[1], errmsg);
}
Index: ext/pdo_pgsql/pgsql_driver.c
===
--- ext/pdo_pgsql/pgsql_driver.c (revision 293440)
+++ ext/pdo_pgsql/pgsql_driver.c (working copy)
@@ -87,7 +87,7 @@
}
if (!dbh-methods) {
- zend_throw_exception_ex(php_pdo_get_exception(), 0 TSRMLS_CC, SQLSTATE[%s] [%d] %s,
+ zend_throw_exception_ex(php_pdo_get_exception(), einfo-errcode TSRMLS_CC, SQLSTATE[%s] [%d] %s,
*pdo_err, einfo-errcode, einfo-errmsg);
}
Index: ext/pdo_odbc/odbc_driver.c
===
--- ext/pdo_odbc/odbc_driver.c (revision 293440)
+++ ext/pdo_odbc/odbc_driver.c (working copy)
@@ -104,7 +104,7 @@
strcpy(*pdo_err, einfo-last_state);
/* printf(@@ SQLSTATE[%s] %s\n, *pdo_err, einfo-last_err_msg); */
if (!dbh-methods) {
- zend_throw_exception_ex(php_pdo_get_exception(), 0 TSRMLS_CC, SQLSTATE[%s] %s: %d %s,
+ zend_throw_exception_ex(php_pdo_get_exception(), einfo-last_error TSRMLS_CC, SQLSTATE[%s] %s: %d %s,
*pdo_err, what, einfo-last_error, einfo-last_err_msg);
}
Index: ext/pdo_oci/oci_driver.c
===
--- ext/pdo_oci/oci_driver.c (revision 293440)
+++ ext/pdo_oci/oci_driver.c (working copy)
@@ -173,7 +173,7 @@
/* little mini hack so that we can use this code from the dbh ctor */
if (!dbh-methods) {
- zend_throw_exception_ex(php_pdo_get_exception(), 0 TSRMLS_CC, SQLSTATE[%s]: %s, *pdo_err, einfo-errmsg);
+ zend_throw_exception_ex(php_pdo_get_exception(), einfo-errcode TSRMLS_CC, SQLSTATE[%s]: %s, *pdo_err, einfo-errmsg);
}
return einfo-errcode;
Index: ext/pdo_dblib/dblib_driver.c
Re: [PHP-DEV] Passing error codes through to PDOException
I also just attached the following to the bug - it's a test that checks this
fix in
the sqlite driver - I can write tests for all the others if need be, but I
figured
there are others who might already be more familiar with the individual PDO
drivers
that would write them more quickly than I.
--TEST--
Bug #50728 (All PDOExceptions hardcode 'code' property to 0) (crash on
PDO::FETCH_CLASS + __set())
--SKIPIF--
?php # vim:ft=php
if (!extension_loaded('pdo_sqlite')) print 'skip not loaded';
?
--FILE--
?php
try {
$a = new PDO(sqlite:/this/path/should/not/exist.db);
} catch (PDOException $e) {
var_dump($e-getCode());
}
?
--EXPECTF--
int(14)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Closures and $this: Please vote!
On Tue, Dec 15, 2009 at 08:46:44PM +0100, Christian Seiler wrote: (A+): (A) + Closure::bind Closure-bindTo for rebinding if this is wanted the possibility to call a closure as an object method. (See last section of RFC for details) +1 for A+ with class scope option 2 I'm a bit torn on how clone should be addressed - there's already some things that (IMO) have a fairly high WTF factor on cloning, and I'd hate to see more of that introduced. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] fpm/typo: change some log about dynamic + homogenize log message about pool
On Tue, Dec 15, 2009 at 02:27:30PM -0800, Michael Shadle wrote: However if people have ideas on how this will help or be useful (i.e. you -are- planning on running logfiles or logwatch or something) then it might be smart to bring it back to the table again. Jérôme and I were talking about some way to grab statistics in real-time (as close as they can be, obviously the connection counts can change rapidly) and I thought it might make sense to have a PHP function which can access that information. Originally he had mentioned a /url-prefix but that seems a bit complex, having to configure it in the webserver and such. I don't use FPM, but I certainly am a heavy user of PostgreSQL's 'log_line_prefix' configuration setting. For those who aren't familiar with it, check out the table at http://www.postgresql.org/docs/8.4/static/runtime-config-logging.html for some ideas on the kinds of information you can add (or exclude) from logfile lines. In production enviroments, I don't use many of these, as any analysis done on them will likely come hours (if not days) after the issue occurred; however, in a development or staging environment, knowing something like the PID can be very useful. It strikes me that these kind of rules might also apply in the FPM case - but, again, I'm not actually *using* FPM, so maybe I'm wrong. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
Write yourself a bit of code that replaces ereg which could be installed in an
auto_prepend location server-wide. Here's an example you could start with,
although I should point out that I spent all of about 30 seconds thinking about
it, so you might want to give it more thought than that - I'm sure there are
some
funny edge cases in the way people have relied on ereg behaviour, but you'd be
more likely to know that than I since I haven't used ereg() since the day PCRE
support was added to PHP.
if (! function_exists('ereg')) {
function ereg($pattern, $string, $regs = array()) {
$matches = array();
$delimiters =
array(chr(1),chr(1),chr(1),chr(1),chr(1),chr(1),'/', '@', '#', '%', '_');
foreach($delimiters as $c) { if (strpos($string, $c) !== FALSE)
continue; $d = $c; }
if (preg_match_all($d.$pattern.$d, $string, $matches)) return
strlen($string);
return false;
}
}
Much the same could be done for split(), ereg_replace(), and so on.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
Ooops: On Mon, Oct 12, 2009 at 01:48:28PM -0600, Joey Smith wrote: $delimiters = array(chr(1),chr(1),chr(1),chr(1),chr(1),chr(1),'/', '@', '#', '%', '_'); should have been $delimiters = array(chr(1),chr(2),chr(3),chr(4),chr(5),chr(6),'/', '@', '#', '%', '_'); I used these because given the feature-set of ereg, it seems unlikely that people were passing binary strings into ereg() today, but again - the people who *use* ereg should give it some thought. I'm confident there's a simple path forward for you just by providing the function in userland if you do so. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
Feel free to collaborate with the authors of PHP_Compat [1]. regards, Lukas Kahwe Smith m...@pooteeweet.org [1] http://pear.php.net/package/PHP_Compat An excellent pointer, Lukas, thank you. I had forgotten PHP_Compat existed. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] shebang skipping in 5.3.0
I can understand not having the 'shebang skipping' code in both the SAPI *and* the scanner, but we probably need to have it in at least ONE of them. :) Per his email[1] almost a year ago, Dmitry removed the shebang line check from sapi/cgi/cgi_main.c in changeset 264153, saying: Removed shebang line check from CGI sapi (it is checked by scanner) In http://tinyurl.com/me8528 (changeset 262275), nlopess removed the code from the scanner. Oops? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] shebang skipping in 5.3.0
On Fri, Sep 04, 2009 at 02:16:40AM -0600, Joey Smith wrote: Per his email[1] almost a year ago, Dmitry removed the [1] should have been: http://tinyurl.com/kwne3v -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] shebang skipping in 5.3.0
I definitely had the wrong changeset - sorry, Nuno. :) Looks like maybe 273177 is the problem child. http://tinyurl.com/lewcft On Fri, Sep 04, 2009 at 09:25:52AM +0100, Scott MacVicar wrote: On 4 Sep 2009, at 09:16, Joey Smith j...@joeysmith.com wrote: I can understand not having the 'shebang skipping' code in both the SAPI *and* the scanner, but we probably need to have it in at least ONE of them. :) Per his email[1] almost a year ago, Dmitry removed the shebang line check from sapi/cgi/cgi_main.c in changeset 264153, saying: Removed shebang line check from CGI sapi (it is checked by scanner) In http://tinyurl.com/me8528 (changeset 262275), nlopess removed the code from the scanner. Oops? What's the problem your having? The skip code is still there just in a different bit. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- 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
Re: [PHP-DEV] mail() and header folding/line endings
On Fri, Aug 21, 2009 at 04:55:31PM +0100, Chris Smith wrote: I've encountered difficulties utilising the mail() function properly under a NIX environments while conforming to RFC 2822. There two specific issues, one is a code problem the other a documentation issue they are intertwined so I thought best run it by here and see that people understand the issue before I head to the bug tracker. As you are no doubt aware mail() operates using the system sendmail interface under NIX environments, and under Windows it either utilises a sendmail binary or more commonly the SMTP feature. The problem stems from confusion and inappropriate application of the SMTP standards to the sendmail interface. Under a NIX environment the sendmail interface operates taking an e-mail message constructed using the system line ending, LF. I've confirmed this applies to the Postfix sendmail interface [1], and could ask other vendors. 1) Maybe you could go back to Wietse and ask him to justify the seemingly contradictory assertions that text is expected to be in native UNIX stream-LF format [1] but Postfix receives local submissions in (LF or CRLF) format [2] and Postfix looks at the first input line [to determine what format you are using] [3]? It's hard to know what to tell PHP developers when we get mixed messages from someone like Wietse... As for other vendors, I can tell you first-hand that sendmail and exim both handle mixed line-endings just fine. However, I agree that not sending them in the first place is the ideal scenario... Under Windows either the sendmail binary or SMTP is utilised. The correct line endings for SMTP are certainly CR-LF, sendmail I guess could be either. 2) Perhaps this has changed, but last time I looked, the built-in SMTP client is the ONLY method available for mail() on Win32. The documentation mentions to use CR-LF as the line endings for the $additional_headers parameters whilst the function implementation utilises LFs [2] which results in a mix of line endings, which is worse than incorrect line endings. There is a 7 year old bug open about this inconsistency [3] and as of yet nobody has fixed it, I hope this can be rectified. 3) I don't have an Apple platform for testing, what will happen on Mac if PHP_EOL is used as the separator for $additional_headers? I would like to change the documentation to say Multiple extra headers should be separated with the PHP_EOL constant, but I'm not the least bit certain this is going to work correctly on Mac. I can tell you that on my machines (Linux, using a mix exim and sendmail as MTAs), it will not see the \r as a separator, but mixing \r\n and \n within the same message works just fine (another case of the ever-prevalent SMTP mantra of Be permissive in what you accept, and strict in what you send). If PHP_EOL can't be safely used, I imagine we'll have to document it as 'Use \r\n on Win32, and \n everywhere else', which I'd really rather not do - it seems hackish. The second issue I have is quite a show stopper with regards to properly formatted emails under the NIX environment; email headers maybe no longer than 998 characters but the advised cut off is 78, a long header should be folded over two lines with some white space indentation. [4] As the To and Subject headers are populated from the function arguments of the same name they pass through additional checks over the other headers. The problem arises with the SKIP_LONG_HEADER_SEP macro [5] which only skips over the SMTP standard of CR-LF-WSP and not LF-WSP required for NIX sendmail as a consequence the LF is replace with a space effectively unfolding the folded line. It is therefore impossible to correctly create an email using mail() with a large number of recipients or a long subject, the effective limit of text shrinks when encoding is used for non ASCII characters as well. 4) I don't write/maintain an MTA, but it seems like you're conflating SMTP and the local pipe to a sendmail binary conversation where it should not be. If you're sending your emails to a local pipe, I don't think you should be wrapping your headers in the PHP code with a LF-WSP. The section of RFC2822 on folding long headers quite clearly states [4]: The general rule is that wherever this standard allows for folding white space (not simply WSP characters), a *CRLF* may be inserted before any WSP. [emphasis mine] Since PHP's mail() doesn't know if it's sending over SMTP or a local pipe, I honestly feel that SKIP_LONG_HEADER_SEP is doing the correct thing here - your MTA should be able to accept long headers via a local pipe and make sure it formats them appropriately before sending them on to their SMTP destination - PHP should only be concerned with SKIP_LONG_HEADER_SEP in a *pure* SMTP situation. Note: I just fed exim a 12000 character long subject from PHP and exim wrapped it before sending it to the other end of the SMTP conversation. Are you
[PHP-DEV] dbase extension
I know - dbase. Why is anyone still trying to use this? However, I thought it worth noting tha tthe extension is documented as moved to PECL, but it doesn't appear to be there - at least, I couldn't find it at pecl.php.net/dbase or via the search form at pecl.php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC: Replacing errors with Exceptions
On Thu, Jul 30, 2009 at 10:48:49AM +0200, Hannes Magnusson wrote: No PHP warnings at all. Again. The examples you are looking for are network issues with fopen(), file_get_contents() and such things. -Hannes Hannes, these are actually the ones I had in mind when I sent my last email - unfortunately, it's been so long since I ran into one, I can't remember how to trigger it, which is why I suggested we get bugs filed. Conceptually, it doesn't seem like it should be that hard to fix them. However, now that it's come up, I'm wondering what the costs/risks are of setting libxml_use_internal_errors() on by default? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC: Replacing errors with Exceptions
On Wed, Jul 29, 2009 at 05:33:18PM -0400, Alban wrote: The result is it's impossible to use this function without @ statement. SimpleXML is hardly alone here, but I would imagine that if we could identify these and get bugs opened on them, there'd be very little resistance to fixing that aspect. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] crypt() post 5.3.0
ext/standard/crypt.c contains a whole bunch of #if's which, as I read it, won't be very meaningful after 5.3.0, where we provide our own implementations of any missing crypt() algorithms. Most notably, automatic salt generation, which I think will always use MD5 from now on? Also, since blowfish is available everywhere now, is it worth maybe updating the automatic salt generator to generate blowfish salts? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
