[PHP-DEV] Re: json_encode() bug

[Gaetano Giunta]

Stanislav Malyshev wrote:

...
The question is - should we have an error there? If 
so, which one - E_WARNING, E_NOTICE? I'm for E_WARNING.


+1

Also please add at least a warning when errors are found in decoding process, 
so that it is somewhat feasible to distinguish a bad decode from 
json_decode('false')

Gaetano

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] CVS Account Request: jmessa

[Josie Messa]

Contributing test cases.I have sent some to the QA list already, found here: 
http://news.php.net/php.qa/62382, and have written some more that I could 
contribute.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] json_encode() bug

[Cristian Rodriguez]

2008/1/25, Stanislav Malyshev <[EMAIL PROTECTED]>:

> Now this is an easy fix but would lead to bad strings silently converted
> to empty strings. The question is - should we have an error there? If
> so, which one - E_WARNING, E_NOTICE? I'm for E_WARNING.

Yes , E_WARNING is the right thing to have IMHO.

-- 
http://www.cristianrodriguez.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] json_encode() bug

[Pierre Joye]

On Feb 1, 2008 8:13 PM, Cristian Rodriguez <[EMAIL PROTECTED]> wrote:
> 2008/1/25, Stanislav Malyshev <[EMAIL PROTECTED]>:
>
> > Now this is an easy fix but would lead to bad strings silently converted
> > to empty strings. The question is - should we have an error there? If
> > so, which one - E_WARNING, E_NOTICE? I'm for E_WARNING.
>
> Yes , E_WARNING is the right thing to have IMHO.

Stupid question, who actually checks for E_* in his code at runtime
after having called such functions? Not me and I would hate to. It
sounds to me like a perfect exception use case. As this function can
return nearly everything scalar we have (boolean, string, null,
integer,...) we can't use our normal "returns FALSE on failure".

Cheers,
-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] json_encode() bug

[Stanislav Malyshev]

Stupid question, who actually checks for E_* in his code at runtime
after having called such functions? Not me and I would hate to. It
sounds to me like a perfect exception use case. As this function can


General policy in PHP as far as I know is that non-OO functions do not 
do exceptions.



return nearly everything scalar we have (boolean, string, null,
integer,...) we can't use our normal "returns FALSE on failure".


This function can return only a string, but I'm not sure returning false 
if somewhere in some value deep down your data is some bad utf-8 is 
warranted. It is doable, though, but I'm afraid most of current code 
never check for return of json_encode() so they are in for big surprises 
 when json_encode won't produce valid JSON.

--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]   http://www.zend.com/
(408)253-8829   MSN: [EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] json_encode() bug

[Pierre Joye]

On Feb 1, 2008 9:06 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > Stupid question, who actually checks for E_* in his code at runtime
> > after having called such functions? Not me and I would hate to. It
> > sounds to me like a perfect exception use case. As this function can
>
> General policy in PHP as far as I know is that non-OO functions do not
> do exceptions.
>
> > return nearly everything scalar we have (boolean, string, null,
> > integer,...) we can't use our normal "returns FALSE on failure".
>
> This function can return only a string, but I'm not sure returning false
> if somewhere in some value deep down your data is some bad utf-8 is
> warranted. It is doable, though, but I'm afraid most of current code
> never check for return of json_encode() so they are in for big surprises
>   when json_encode won't produce valid JSON.

Oh right, I thought about/read json_decode. But the idea is the same
yes. Not checking return values is a very bad habit, I can't count how
many times I saw codes dying miserably only because they don't check
returns values. Would it make sense to use exception for such cases?
Aka to change our policy? I'm not an excpeption fan, but these cases
are good examples of exception usages. We can invent a meta type
"error" but it would be rather confusing  ;)

-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC] An Idea for PDO 2

[Marcus Boerger]

Hello all,

So after the initial uproar on last week's attempts to put parts
of PHP development under the terms of a CLA, a bunch of us actually
spent some time in finding solutions for one way or the other. I
don't want to bother you with more details on the why.

One thing for certain, we want PDO.

As the reasoning, this was discussed enough, so I'll jump directly
to my ideas for a solution.

* Develop a PECL CLA that can optionally be used for PECL projects.
* If necessary, adapt the PHP License, so that it works nicely
  together with the CLA.
* The projects that want a CLA can choose between the PHP License or
  LGPL.
* Change the PELC web site so that projects can opt-in to using the
  CLA.
* Arrange it so that projects cannot drop the CLA flag.
* Add a user/CLA/project table to the PHP user database, and use this
  in CVS ACLs.
* Create a new CVS module php-default.
* Move all extensions that can be disabled and are not required for
  others to PECL.
* Link everything under php-src plus a default selection of
  extensions to php-default.
* Let us once and for all ban CLAs from php-src aka PHP core.
* Start developing PDO as part of CVS module php-src.

Sorry for not writing this earlier. So how does this idea sound?  

Best regards,
 Marcus

p.s.: Post comments as reply or here: 
http://blog.somabo.de/2008/02/we-want-pdo-don-we.html#links

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] An Idea for PDO 2

[Marco Tabini]

Hey Marcus—

On 1-Feb-08, at 3:26 PM, Marcus Boerger wrote:


* Develop a PECL CLA that can optionally be used for PECL projects.
* If necessary, adapt the PHP License, so that it works nicely
 together with the CLA.


IMO (and FWIW), CLAs do not belong in any official php.net project. I  
have already explained the reason why in the past, so I won't repeat  
myself, but a CLA violates the basic principle under which everything  
"officially" PHP is developed, and it should not be allowed to enter  
the project in any way.


Perhaps PDO2 can simply be an external project, maybe hosted at  
Sourceforge or some other such site?



Marco
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] An Idea for PDO 2

[Pierre Joye]

Hi,

Globally -1. I'm against any CLA in php.net. It was a mistake in the
first place to accept restricted modules. There is many repositories
out there, and the companies that need a CLA also have the resources
to create their own PECL channels. But they may not have the fantastic
advantages brought by being in php.net, like QA, visibility, etc.

Secondly it is not correct to mix the topics. PDO will have a future,
no matter if we accept a CLA or not. The same companies (I would like
to say, the company) will participate anyway. Their customers need it.

I think this quote fits well in this thread:

"Those who would give up Essential Liberty to purchase a little
Temporary Safety, deserve neither Liberty nor Safety."
   -- Benjamin Franklin, 1759

-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) / zend_API.c zend_API.h php-src/ext/standard type.c

[Marcus Boerger]

Crosspost, hopefully silencing this issue for 5.*

AND 6 will have an E_WARNING or even an E_ERROR on this.

helly   Fri Feb  1 21:27:55 2008 UTC

  Modified files:  (Branch: PHP_5_3)
/php-src/ext/standard   type.c 
/ZendEngine2zend_API.c zend_API.h 
  Log:
  [DOC]
  - Fix callable/static mess, the following will now all result in a E_STRICT
. binding a dynamic function as a static callback
. static call of a dynamic function
. is_callable() on a static binding to a dynamic function
  # [EMAIL PROTECTED] PHP_5_3]$ php -a -d error_reporting=8191
  # make: `sapi/cli/php' is up to date.
  # Interactive shell
  #
  # php > class t{ function f() { echo "Funny\n"; } }
  # php > $c = array("t","f");
  # php > call_user_func($c);
  #
  # Strict Standards: call_user_func() expects parameter 1 to be a valid 
callback, non-static method t::f() cannot be called statically in php shell 
code on line 1
  # Funny
  # php > var_dump(is_callable($c));
  #
  # Strict Standards: Non-static method t::f() cannot be called statically in 
php shell code on line 1
  # bool(true)
  # php > t::f();
  #
  # Strict Standards: Non-static method t::f() should not be called statically 
in php shell code on line 1
  # Funny
  # php >
  
  http://cvs.php.net/viewvc.cgi/php-src/ext/standard/type.c?r1=1.30.2.2.2.3.2.2&r2=1.30.2.2.2.3.2.3&diff_format=u
Index: php-src/ext/standard/type.c
diff -u php-src/ext/standard/type.c:1.30.2.2.2.3.2.2 
php-src/ext/standard/type.c:1.30.2.2.2.3.2.3
--- php-src/ext/standard/type.c:1.30.2.2.2.3.2.2Thu Jan 31 11:21:15 2008
+++ php-src/ext/standard/type.c Fri Feb  1 21:27:55 2008
@@ -16,7 +16,7 @@
+--+
 */
 
-/* $Id: type.c,v 1.30.2.2.2.3.2.2 2008/01/31 11:21:15 helly Exp $ */
+/* $Id: type.c,v 1.30.2.2.2.3.2.3 2008/02/01 21:27:55 helly Exp $ */
 
 #include "php.h"
 #include "php_incomplete_class.h"
@@ -374,7 +374,7 @@
syntax = Z_BVAL_PP(syntax_only);
}
 
-   syntax = syntax ? IS_CALLABLE_CHECK_SYNTAX_ONLY : IS_CALLABLE_STRICT;
+   syntax = syntax ? IS_CALLABLE_CHECK_SYNTAX_ONLY : 0;
if (argc > 2) {
retval = zend_is_callable(*var, syntax, &name);
zval_dtor(*callable_name);
http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_API.c?r1=1.296.2.27.2.34.2.17&r2=1.296.2.27.2.34.2.18&diff_format=u
Index: ZendEngine2/zend_API.c
diff -u ZendEngine2/zend_API.c:1.296.2.27.2.34.2.17 
ZendEngine2/zend_API.c:1.296.2.27.2.34.2.18
--- ZendEngine2/zend_API.c:1.296.2.27.2.34.2.17 Thu Jan 24 10:49:26 2008
+++ ZendEngine2/zend_API.c  Fri Feb  1 21:27:55 2008
@@ -18,13 +18,14 @@
+--+
 */
 
-/* $Id: zend_API.c,v 1.296.2.27.2.34.2.17 2008/01/24 10:49:26 dmitry Exp $ */
+/* $Id: zend_API.c,v 1.296.2.27.2.34.2.18 2008/02/01 21:27:55 helly Exp $ */
 
 #include "zend.h"
 #include "zend_execute.h"
 #include "zend_API.h"
 #include "zend_modules.h"
 #include "zend_constants.h"
+#include "zend_exceptions.h"
 
 #ifdef HAVE_STDARG_H
 #include 
@@ -311,7 +312,7 @@
 }
 /* }}} */
 
-static char *zend_parse_arg_impl(int arg_num, zval **arg, va_list *va, char 
**spec TSRMLS_DC) /* {{{ */
+static char *zend_parse_arg_impl(int arg_num, zval **arg, va_list *va, char 
**spec, char **error, int *severity TSRMLS_DC) /* {{{ */
 {
char *spec_walk = *spec;
char c = *spec_walk++;
@@ -556,21 +557,15 @@
}
if (ce_base) {
if ((!*pce || 
!instanceof_function(*pce, ce_base TSRMLS_CC))) {
-   char *space;
-   char *class_name = 
get_active_class_name(&space TSRMLS_CC);
-   zend_error(E_WARNING, "%s%s%s() 
expects parameter %d to be a class name derived from %s, '%s' given",
-   class_name, space, 
get_active_function_name(TSRMLS_C),
-   arg_num, ce_base->name, 
Z_STRVAL_PP(arg));
+   zend_spprintf(error, 0, "to be 
a class name derived from %s, '%s' given",
+   ce_base->name, 
Z_STRVAL_PP(arg));
*pce = NULL;
return "";
}
}
if (!*pce) {
-   char *space;
-   char *class_name = 
get_active_class_name(&space TSRMLS_CC);
-   zend_error(E_WARNING, "%s%s%s() expects 
parameter %d to be a valid class name, '%s' given",
- 

[PHP-DEV] ubuntu help, dl_open leaks?

[Gregory Beaver]

Hi all,

It's a tad tricky to do run-tests -m on my system, as every PHP call leaks:

==4570== Invalid read of size 8
==4570==at 0x4015B0A: (within /lib/ld-2.6.1.so)
==4570==by 0x400A8F7: (within /lib/ld-2.6.1.so)
==4570==by 0x4006174: (within /lib/ld-2.6.1.so)
==4570==by 0x40085F7: (within /lib/ld-2.6.1.so)
==4570==by 0x4011C98: (within /lib/ld-2.6.1.so)
==4570==by 0x400DA05: (within /lib/ld-2.6.1.so)
==4570==by 0x401155A: (within /lib/ld-2.6.1.so)
==4570==by 0x56F9F8A: (within /lib/libdl-2.6.1.so)
==4570==by 0x400DA05: (within /lib/ld-2.6.1.so)
==4570==by 0x56FA4EC: (within /lib/libdl-2.6.1.so)
==4570==by 0x56F9EF0: dlopen (in /lib/libdl-2.6.1.so)
==4570==by 0x610D67: php_load_extension (dl.c:142)
==4570==  Address 0x6BCFA30 is 40 bytes inside a block of size 44 alloc'd
==4570==at 0x4C21C16: malloc (vg_replace_malloc.c:149)
==4570==by 0x40077B3: (within /lib/ld-2.6.1.so)
==4570==by 0x400854E: (within /lib/ld-2.6.1.so)
==4570==by 0x4011C98: (within /lib/ld-2.6.1.so)
==4570==by 0x400DA05: (within /lib/ld-2.6.1.so)
==4570==by 0x401155A: (within /lib/ld-2.6.1.so)
==4570==by 0x56F9F8A: (within /lib/libdl-2.6.1.so)
==4570==by 0x400DA05: (within /lib/ld-2.6.1.so)
==4570==by 0x56FA4EC: (within /lib/libdl-2.6.1.so)
==4570==by 0x56F9EF0: dlopen (in /lib/libdl-2.6.1.so)
==4570==by 0x610D67: php_load_extension (dl.c:142)
==4570==by 0x6B5C4F: php_load_php_extension_cb (php_ini.c:319)
==4570==
==4570== Invalid read of size 8
==4570==at 0x4015B24: (within /lib/ld-2.6.1.so)
==4570==by 0x400A8F7: (within /lib/ld-2.6.1.so)
==4570==by 0x4006174: (within /lib/ld-2.6.1.so)
==4570==by 0x40085F7: (within /lib/ld-2.6.1.so)
==4570==by 0x400BB6C: (within /lib/ld-2.6.1.so)
==4570==by 0x400DA05: (within /lib/ld-2.6.1.so)
==4570==by 0x400C239: (within /lib/ld-2.6.1.so)
==4570==by 0x4011CF8: (within /lib/ld-2.6.1.so)
==4570==by 0x400DA05: (within /lib/ld-2.6.1.so)
==4570==by 0x401155A: (within /lib/ld-2.6.1.so)
==4570==by 0x56F9F8A: (within /lib/libdl-2.6.1.so)
==4570==by 0x400DA05: (within /lib/ld-2.6.1.so)
==4570==  Address 0x6BD0930 is 16 bytes inside a block of size 19 alloc'd
==4570==at 0x4C21C16: malloc (vg_replace_malloc.c:149)
==4570==by 0x4008AF5: (within /lib/ld-2.6.1.so)
==4570==by 0x400BB6C: (within /lib/ld-2.6.1.so)
==4570==by 0x400DA05: (within /lib/ld-2.6.1.so)
==4570==by 0x400C239: (within /lib/ld-2.6.1.so)
==4570==by 0x4011CF8: (within /lib/ld-2.6.1.so)
==4570==by 0x400DA05: (within /lib/ld-2.6.1.so)
==4570==by 0x401155A: (within /lib/ld-2.6.1.so)
==4570==by 0x56F9F8A: (within /lib/libdl-2.6.1.so)
==4570==by 0x400DA05: (within /lib/ld-2.6.1.so)
==4570==by 0x56FA4EC: (within /lib/libdl-2.6.1.so)
==4570==by 0x56F9EF0: dlopen (in /lib/libdl-2.6.1.so)

Anyone have experience with this and advice on what I need to upgrade?

Greg

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] ubuntu help, dl_open leaks?

[Rasmus Lerdorf]

Gregory Beaver wrote:

> Anyone have experience with this and advice on what I need to upgrade?

It's normal.  Create a suppression file and ignore those.

eg.

--gen-suppressions=yes

And it isn't PHP calls leaking.  It's just the way libdl does stuff.

-Rasmus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] An Idea for PDO 2

[Antony Dovgal]

On 01.02.2008 23:26, Marcus Boerger wrote:
> Sorry for not writing this earlier. So how does this idea sound?  

It sounds quite bad.

If you want to do something good for PHP - either respect its rules, or go away.
Changing the rules to fit your needs is not acceptable.

-- 
Wbr, 
Antony Dovgal

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] An Idea for PDO 2

[Pierre Joye]

On Feb 1, 2008 11:10 PM, Adam Maccabee Trachtenberg
<[EMAIL PROTECTED]> wrote:
> On Sat, 2 Feb 2008, Antony Dovgal wrote:
>
> > On 01.02.2008 23:26, Marcus Boerger wrote:
> > > Sorry for not writing this earlier. So how does this idea sound?
> >
> > It sounds quite bad.
> >
> > If you want to do something good for PHP - either respect its rules, or go 
> > away.
> > Changing the rules to fit your needs is not acceptable.
>
> I don't have a particular horse to back in this race, and I realize
> people are passionate on both sides, but can we please have a polite
> discussion on this topic?

There was nothing not polite in Tony's reply.

> Furthermore, I think Marcus has contributed enough to PHP that he does
> not deserve to hear that what would be good for PHP is for him to "go
> away." PDO opinions aside, I don't think any of us would actually
> think that would put PHP in a more healthy situation.

The targets were these/this companies(y) pushing CLA in php.net when
it is not necessary to contribute. It has been proven already since
months on a nearly daily basis.

For example:
http://blogs.oracle.com/opal/discuss/msgReader$268

and the numerous contributions from IBM people.

-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) / zend_API.c zend_API.h php-src/ext/standard type.c

[Lukas Kahwe Smith]

On 01.02.2008, at 23:05, Pierre Joye wrote:


2008/2/1 Marcus Boerger <[EMAIL PROTECTED]>:

Crosspost, hopefully silencing this issue for 5.*

AND 6 will have an E_WARNING or even an E_ERROR on this.


What are the gains?

What are the real reasons behing strictness? I really get annoying by
adding fatal errors all around for no technical reasons. A fatal error
means the engine is getting foo bared and can't do anything sane but
leaving.


Yes .. I think for PHP we should follow these rules:

1) No fatal errors that are not fatal for the engine
2) throw E_STRICT for anything that makes a CS prof commit suicide

PHP is about solving real world problems and not creating problems  
that are not there (making on fatal things fatal is creating a non  
existant problem). if people want to do the right thing in terms of CS  
they enable E_STRICT .. and if they want E_STRICT to be fatal they can  
create an error handler that does that for them.


regards,
Lukas

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] An Idea for PDO 2

[Adam Maccabee Trachtenberg]

On Sat, 2 Feb 2008, Antony Dovgal wrote:

> On 01.02.2008 23:26, Marcus Boerger wrote:
> > Sorry for not writing this earlier. So how does this idea sound?
>
> It sounds quite bad.
>
> If you want to do something good for PHP - either respect its rules, or go 
> away.
> Changing the rules to fit your needs is not acceptable.

I don't have a particular horse to back in this race, and I realize
people are passionate on both sides, but can we please have a polite
discussion on this topic?

We change the rules all the time to fit the needs of PHP. This may not
be one of those times, or this may not be the way to go, but I think
the concept of having better support from database companies is one
that at least deserves the benefit of a dialog.

Clearly, there is an attempt from some people to listen to the vocal
feedback on the original PDO CLA proposal and try to come up with an
alternative. You may not still like it, which is totally your right,
but it's not as if what he's saying is completely tone deaf to what's
going on.

Furthermore, I think Marcus has contributed enough to PHP that he does
not deserve to hear that what would be good for PHP is for him to "go
away." PDO opinions aside, I don't think any of us would actually
think that would put PHP in a more healthy situation.

Thanks.

-adam

-- 
[EMAIL PROTECTED] | http://www.trachtenberg.com
author of o'reilly's "upgrading to php 5" and "php cookbook"
avoid the holiday rush, buy your copies today!

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) / zend_API.c zend_API.h php-src/ext/standard type.c

[Pierre Joye]

2008/2/1 Marcus Boerger <[EMAIL PROTECTED]>:
> Crosspost, hopefully silencing this issue for 5.*
>
> AND 6 will have an E_WARNING or even an E_ERROR on this.

What are the gains?

What are the real reasons behing strictness? I really get annoying by
adding fatal errors all around for no technical reasons. A fatal error
means the engine is getting foo bared and can't do anything sane but
leaving.
-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] An Idea for PDO 2

[Antony Dovgal]

On 02.02.2008 01:10, Adam Maccabee Trachtenberg wrote:
> We change the rules all the time to fit the needs of PHP.

Do we?

> This may not be one of those times, or this may not be the way to go, but I 
> think
> the concept of having better support from database companies is one
> that at least deserves the benefit of a dialog.

Sure, that's what the "dialog" is - they asked if they could set their 
own rules and we said "no".

That's what the discussion is - they've asked a question and got an answer.
We've discussed it long enough to be sure, and the answer is "NO".

> Furthermore, I think Marcus has contributed enough to PHP that he does
> not deserve to hear that what would be good for PHP is for him to "go
> away."

Wait a second... "Somebody has contributed enough, so everybody should agree 
with him"?
Do I get it right?

I do respect Marcus (as well as everybody else, doesn't matter how big 
his/her contribution is), but this doesn't matter I agree.

And I really do think that such an attempt to add a half-closed-source module 
into PHP 
project MUST be rejected, as it violates all the rules and basically sets a new 
rule:
everybody can do anything he/she wants to do for no reason.

> PDO opinions aside, I don't think any of us would actually
> think that would put PHP in a more healthy situation.

Openness is healthy.
Adding new rules to make lawyers happy is not.

-- 
Wbr, 
Antony Dovgal

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) / zend_API.c zend_API.h php-src/ext/standard type.c

[Cristian Rodriguez]

2008/2/1, Marcus Boerger <[EMAIL PROTECTED]>:
>   - Fix callable/static mess, the following will now all result in a E_STRICT
> . binding a dynamic function as a static callback
> . static call of a dynamic function
> . is_callable() on a static binding to a dynamic function


Does not compile..

php5.3/ext/spl/php_spl.c: In function 'zif_spl_autoload_register':
php5.3/ext/spl/php_spl.c:423: error: too few arguments to function
'zend_is_callable_ex'
php5.3/ext/spl/php_spl.c: In function 'zif_spl_autoload_unregister':
php5.3/ext/spl/php_spl.c:515: error: too few arguments to function
'zend_is_callable_ex'
make: *** [ext/spl/php_spl.lo] Error 1


-- 
http://www.cristianrodriguez.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) / zend_API.c zend_API.h php-src/ext/standard type.c

[Rasmus Lerdorf]

Cristian Rodriguez wrote:
> 2008/2/1, Marcus Boerger <[EMAIL PROTECTED]>:
>>   - Fix callable/static mess, the following will now all result in a E_STRICT
>> . binding a dynamic function as a static callback
>> . static call of a dynamic function
>> . is_callable() on a static binding to a dynamic function
> 
> 
> Does not compile..
> 
> php5.3/ext/spl/php_spl.c: In function 'zif_spl_autoload_register':
> php5.3/ext/spl/php_spl.c:423: error: too few arguments to function
> 'zend_is_callable_ex'
> php5.3/ext/spl/php_spl.c: In function 'zif_spl_autoload_unregister':
> php5.3/ext/spl/php_spl.c:515: error: too few arguments to function
> 'zend_is_callable_ex'
> make: *** [ext/spl/php_spl.lo] Error 1

Did you update your Zend/ directory?  It compiles fine here.

I've been working through this one with Marcus a bit, and even though he
fundamentally disagrees with the concept, he still wrote the code.  I
can't say I would have done the same in his place.  So thanks, Marcus.

-Rasmus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) / zend_API.c zend_API.h php-src/ext/standard type.c

[Marcus Boerger]

Hello Lukas,

  only E_ERROR is fatal and reserved for when the engine cannot continue
  execution.

marcus

Friday, February 1, 2008, 11:15:08 PM, you wrote:

> On 01.02.2008, at 23:05, Pierre Joye wrote:

>> 2008/2/1 Marcus Boerger <[EMAIL PROTECTED]>:
>>> Crosspost, hopefully silencing this issue for 5.*
>>>
>>> AND 6 will have an E_WARNING or even an E_ERROR on this.
>>
>> What are the gains?
>>
>> What are the real reasons behing strictness? I really get annoying by
>> adding fatal errors all around for no technical reasons. A fatal error
>> means the engine is getting foo bared and can't do anything sane but
>> leaving.

> Yes .. I think for PHP we should follow these rules:

> 1) No fatal errors that are not fatal for the engine
> 2) throw E_STRICT for anything that makes a CS prof commit suicide

> PHP is about solving real world problems and not creating problems  
> that are not there (making on fatal things fatal is creating a non  
> existant problem). if people want to do the right thing in terms of CS  
> they enable E_STRICT .. and if they want E_STRICT to be fatal they can  
> create an error handler that does that for them.

> regards,
> Lukas



Best regards,
 Marcus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) / zend_API.c zend_API.h php-src/ext/standard type.c

[Marcus Boerger]

Hello Rasmus,

  well, I can compromise. In this case I rather get the messages right than
none at all. What I disagree to, is the severity level. Thus I might come up
with something that turns warnings into exceptions better than how we can do
it today, since that in place would give me what I want too.

marcus

Saturday, February 2, 2008, 12:11:07 AM, you wrote:

> Cristian Rodriguez wrote:
>> 2008/2/1, Marcus Boerger <[EMAIL PROTECTED]>:
>>>   - Fix callable/static mess, the following will now all result in a 
>>> E_STRICT
>>> . binding a dynamic function as a static callback
>>> . static call of a dynamic function
>>> . is_callable() on a static binding to a dynamic function
>> 
>> 
>> Does not compile..
>> 
>> php5.3/ext/spl/php_spl.c: In function 'zif_spl_autoload_register':
>> php5.3/ext/spl/php_spl.c:423: error: too few arguments to function
>> 'zend_is_callable_ex'
>> php5.3/ext/spl/php_spl.c: In function 'zif_spl_autoload_unregister':
>> php5.3/ext/spl/php_spl.c:515: error: too few arguments to function
>> 'zend_is_callable_ex'
>> make: *** [ext/spl/php_spl.lo] Error 1

> Did you update your Zend/ directory?  It compiles fine here.

> I've been working through this one with Marcus a bit, and even though he
> fundamentally disagrees with the concept, he still wrote the code.  I
> can't say I would have done the same in his place.  So thanks, Marcus.

> -Rasmus




Best regards,
 Marcus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] An Idea for PDO 2

[Marcus Boerger]

Hello Pierre,

  in some places of the world what he wrote might be ok in the way he
wrote it. In some this wouldn't be acceptable at all. Contributing to PHP
for a long time now and knowing Tony I a) couldn't care less and b) guess I
know what he wanted to say and prefer to understand it as such.

Either way, this is a polictical & strategical move. One that has a bunch of
implications for which most peolple would need to read three times at least
to understand them all.
marcus

Friday, February 1, 2008, 11:20:33 PM, you wrote:

> On Feb 1, 2008 11:10 PM, Adam Maccabee Trachtenberg
> <[EMAIL PROTECTED]> wrote:
>> On Sat, 2 Feb 2008, Antony Dovgal wrote:
>>
>> > On 01.02.2008 23:26, Marcus Boerger wrote:
>> > > Sorry for not writing this earlier. So how does this idea sound?
>> >
>> > It sounds quite bad.
>> >
>> > If you want to do something good for PHP - either respect its rules, or go 
>> > away.
>> > Changing the rules to fit your needs is not acceptable.
>>
>> I don't have a particular horse to back in this race, and I realize
>> people are passionate on both sides, but can we please have a polite
>> discussion on this topic?

> There was nothing not polite in Tony's reply.

>> Furthermore, I think Marcus has contributed enough to PHP that he does
>> not deserve to hear that what would be good for PHP is for him to "go
>> away." PDO opinions aside, I don't think any of us would actually
>> think that would put PHP in a more healthy situation.

> The targets were these/this companies(y) pushing CLA in php.net when
> it is not necessary to contribute. It has been proven already since
> months on a nearly daily basis.

> For example:
> http://blogs.oracle.com/opal/discuss/msgReader$268

> and the numerous contributions from IBM people.

> -- 
> Pierre
> http://blog.thepimp.net | http://www.libgd.org




Best regards,
 Marcus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] An Idea for PDO 2

[Pierre Joye]

On Feb 2, 2008 12:51 AM, Marcus Boerger <[EMAIL PROTECTED]> wrote:
> Hello Pierre,
>
>   in some places of the world what he wrote might be ok in the way he
> wrote it.

In every places in the world you have to respect the existing rules
and usages or you better have to leave if you don't want to. That does
not mean that you can't have an influence on them once you are in.

> In some this wouldn't be acceptable at all. Contributing to PHP
> for a long time now and knowing Tony I a) couldn't care less and b) guess I
> know what he wanted to say and prefer to understand it as such.

c) you know exactly what he meant and who are (is) the target.

> Either way, this is a polictical & strategical move. One that has a bunch of
> implications for which most peolple would need to read three times at least
> to understand them all.

Exactly and I see absolutely nothing that can change my view or
opinion on this topic. There is other very large projects out there
where major or leading companies contribute, there is no CLA, there is
no restriction. In some cases, they are even kept outside as long as
they don't want to follow the usages and rules of the given projects.

That being said, where are the complains? Who is actually pushing the
CLA in? I mean outside Zend and related? Why did they not post
something to actually explain their views? Or are they afraid to say
that they can't support PHP if there is no CLA? Well, I would be
afraid too, especially when I know that I have to support PHP anyway.
At least if I want to keep my piece of the web cake .

Cheers,
-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) / zend_API.czend_API.h php-src/ext/standard type.c

[Gregory Beaver]

Rasmus Lerdorf wrote:
> Cristian Rodriguez wrote:
>> 2008/2/1, Marcus Boerger <[EMAIL PROTECTED]>:
>>>   - Fix callable/static mess, the following will now all result in a 
>>> E_STRICT
>>> . binding a dynamic function as a static callback
>>> . static call of a dynamic function
>>> . is_callable() on a static binding to a dynamic function
>>
>> Does not compile..
>>
>> php5.3/ext/spl/php_spl.c: In function 'zif_spl_autoload_register':
>> php5.3/ext/spl/php_spl.c:423: error: too few arguments to function
>> 'zend_is_callable_ex'
>> php5.3/ext/spl/php_spl.c: In function 'zif_spl_autoload_unregister':
>> php5.3/ext/spl/php_spl.c:515: error: too few arguments to function
>> 'zend_is_callable_ex'
>> make: *** [ext/spl/php_spl.lo] Error 1
> 
> Did you update your Zend/ directory?  It compiles fine here.
> 
> I've been working through this one with Marcus a bit, and even though he
> fundamentally disagrees with the concept, he still wrote the code.  I
> can't say I would have done the same in his place.  So thanks, Marcus.

I and everyone in PEAR agrees, this was a very gallant move.  For those
who are similarly grateful, Marcus does have a wishlist at
http://pecl.php.net/wishlist.php/helly :)

Greg

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] An Idea for PDO 2

[Adam Maccabee Trachtenberg]

On Sat, 2 Feb 2008, Antony Dovgal wrote:

> On 02.02.2008 01:10, Adam Maccabee Trachtenberg wrote:
> > We change the rules all the time to fit the needs of PHP.
>
> Do we?

Sure. PHP 3 was dual licensed under the GPL. We introduced the Zend
License. We moved the PHP Manual under an Open Publication License,
which is not was it was originally licensed under. We introduced cvs
karma to restrict who could modify which parts of the code without
explicit permission from others.

And that's just about licensing and access to source commits.

We change technical things all the time. For example, when I started
using PHP, there were no OO concepts and register_globals was
On. Those changes to the essential nature of PHP also affect the
community and were done based on the needs of PHP.

Again, I am not saying we should change this here. I am just saying
that PHP has changed over the years. Like many projects, it becomes
more calcified over time, but there are changes.

> > This may not be one of those times, or this may not be the way to go, but I 
> > think
> > the concept of having better support from database companies is one
> > that at least deserves the benefit of a dialog.
>
> Sure, that's what the "dialog" is - they asked if they could set their
> own rules and we said "no".
>
> That's what the discussion is - they've asked a question and got an
> answer.  We've discussed it long enough to be sure, and the answer
> is "NO".

Based on my readings, I know where your position is, but I don't think
there is universal agreement on this. Heavens, we've spent more time
discussing the name of ifsetor, and I know that's not as important as
PDO in any aspect.

> > Furthermore, I think Marcus has contributed enough to PHP that he does
> > not deserve to hear that what would be good for PHP is for him to "go
> > away."
>
> Wait a second... "Somebody has contributed enough, so everybody
> should agree with him"?  Do I get it right?

I must have explain myself poorly, as you get it wrong. What I am
saying is that I felt your reply was rude because you told him that
because he presented a different opinion to you with respect to PDO
and a CLA, that it would be better off it he leaves PHP. That may not
be what you meant, but I don't think we should be telling people that
we want them to go.

What we should be telling people is that we think this is not the most
productive way to move PHP forward, which is what I would like to
presume is the goal of everyone in the conversation. We may differ on
how we should get there, but we would like to keep everyone involved
if possible.

> And I really do think that such an attempt to add a
> half-closed-source module into PHP project MUST be rejected, as it
> violates all the rules and basically sets a new rule: everybody can
> do anything he/she wants to do for no reason.

That's totally fine. I don't have problems with that. What I am saying
is that I have a problem with *how* you are saying this. This may be
cultural, or even personal, but I felt it was important to express my
opinion.

> > PDO opinions aside, I don't think any of us would actually
> > think that would put PHP in a more healthy situation.
>
> Openness is healthy.
> Adding new rules to make lawyers happy is not.

We have rules to make lawyers happy already -- we call this the PHP
License. You just happen to like those rules.

We could bring in RMS and he could tell that that your rules are evil,
just as you feel that a CLA is evil. (I know I am putting words in
people's mouths here, forgive me.)

So, we're not discussing whether we should have rules to make lawyers
happy, we're discussing which rules we should have, and whether the
rules we currently use and the best rules for going forward.

Again, I am not saying whether we should or should not have a CLA for
PDO, and where PDO should live. I have an opinion, but, frankly, that
is not what I am trying to comment on here.

What I am trying to do is keep the level of the dialog on a
constructive basis.

-adam

-- 
[EMAIL PROTECTED] | http://www.trachtenberg.com
author of o'reilly's "upgrading to php 5" and "php cookbook"
avoid the holiday rush, buy your copies today!

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) / zend_API.czend_API.h php-src/ext/standard type.c

[Pierre Joye]

On Feb 2, 2008 1:52 AM, Gregory Beaver <[EMAIL PROTECTED]> wrote:
> Rasmus Lerdorf wrote:
> > Cristian Rodriguez wrote:
> >> 2008/2/1, Marcus Boerger <[EMAIL PROTECTED]>:
> >>>   - Fix callable/static mess, the following will now all result in a 
> >>> E_STRICT
> >>> . binding a dynamic function as a static callback
> >>> . static call of a dynamic function
> >>> . is_callable() on a static binding to a dynamic function
> >>
> >> Does not compile..
> >>
> >> php5.3/ext/spl/php_spl.c: In function 'zif_spl_autoload_register':
> >> php5.3/ext/spl/php_spl.c:423: error: too few arguments to function
> >> 'zend_is_callable_ex'
> >> php5.3/ext/spl/php_spl.c: In function 'zif_spl_autoload_unregister':
> >> php5.3/ext/spl/php_spl.c:515: error: too few arguments to function
> >> 'zend_is_callable_ex'
> >> make: *** [ext/spl/php_spl.lo] Error 1
> >
> > Did you update your Zend/ directory?  It compiles fine here.
> >
> > I've been working through this one with Marcus a bit, and even though he
> > fundamentally disagrees with the concept, he still wrote the code.  I
> > can't say I would have done the same in his place.  So thanks, Marcus.
>
> I and everyone in PEAR agrees, this was a very gallant move.  For those
> who are similarly grateful, Marcus does have a wishlist at
> http://pecl.php.net/wishlist.php/helly :)

To rectify a bit the shot, everyone agrees, but that's not the point :)

The initial move was actually wrong, that does not mean that Marcus is
the evil or does nothing good for PHP. That only means that it was a
bad move and should be corrected. We all do such moves once or two.
The problem is fixed now, thanks you.

However that does not answer my questions, what's the gain to make
such errors fatal?

--
Pierre
http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] build failure on windows PHP_5_2

[Gregory Beaver]

Hi all,

I'm getting unresolved external symbol xmlXPathCompiledEvalToBoolean
with the latest zip.zip, any plans to update libxml2 to .31 soon in zip.zip?

Greg

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php