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_de
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
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 hav
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_W
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.
re
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 p
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 PD
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 al
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 broug
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:
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:
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 Dev
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
-
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 so
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
addi
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 yo
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 r
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 de
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
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 t
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 issu
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 wan
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.
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.
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
>>> . i
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
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 functio
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
28 matches
Mail list logo
