On Tue, Feb 28, 2012 at 10:38 AM, Xinchen Hui wrote:
> On Tue, Feb 28, 2012 at 1:10 AM, Anthony Ferrara wrote:
>> I initially looked at the final fix when I discovered the issue.
>> Follow me out on this. This is the current code as-implemented in
>> r323563:
>>
>> 265 zval *o
On Tue, Feb 28, 2012 at 1:10 AM, Anthony Ferrara wrote:
> I initially looked at the final fix when I discovered the issue.
> Follow me out on this. This is the current code as-implemented in
> r323563:
>
> 265 zval *obj;
> 266 MAKE_STD_ZVAL(obj);
> 267
I initially looked at the final fix when I discovered the issue.
Follow me out on this. This is the current code as-implemented in
r323563:
265 zval *obj;
266 MAKE_STD_ZVAL(obj);
267 if (Z_OBJ_HANDLER_P(*arg, cast_object)(*arg, obj, type
Sent from my iPad
在 2012-2-28，0:10，Anthony Ferrara 写道：
> Out of curiosity, why are you changing it to copy the object for the
> result of the cast operation? cast_object should init the result
> zval, so why go through the step of copying the starting object to
plz look at the final fix： r32356
Out of curiosity, why are you changing it to copy the object for the
result of the cast operation? cast_object should init the result
zval, so why go through the step of copying the starting object to it?
Wouldn't it be easier just to do:
if (Z_OBJ_HANDLER_PP(arg, cast_object)) {
On Mon, February 27, 2012 2:31 am, Laruence wrote:
> On Mon, Feb 27, 2012 at 4:00 PM, Dmitry Stogov
> wrote:
>> Hi Laruence,
>>
>> The attached patch looks wired. The patch on top of it (r323563)
>> makes it
>> better. However, in my opinion it fixes a common problem just in a
>> single
>> place.
On 02/27/2012 12:53 PM, Stas Malyshev wrote:
Hi!
so I think, maybe it's okey for a temporary fix :)
what I mean temporary is, apply this fix to 5.3 and 5.4
Don't apply anything to 5.4 now, please.
No, we are thinking about the trunk, and "temporary" fix for 5.4 is
delayed.
Thanks. Dmitr
On Mon, Feb 27, 2012 at 4:53 PM, Stas Malyshev wrote:
> Hi!
>
>
>>> so I think, maybe it's okey for a temporary fix :)
>>
>> what I mean temporary is, apply this fix to 5.3 and 5.4
>
>
> Don't apply anything to 5.4 now, please.
Sure, won't do it without your permission. :)
thanks
>
> --
> Stan
Hi!
so I think, maybe it's okey for a temporary fix :)
what I mean temporary is, apply this fix to 5.3 and 5.4
Don't apply anything to 5.4 now, please.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Deve
OK. As I said I don't have strong opinion about this.
So fell free to remove the warning.
Thanks. Dmitry.
On 07/11/2011 12:18 PM, Stas Malyshev wrote:
Hi!
That warning might be only emitted if the first operand is a name of non
existing class.
is_a("NonExistingClass", "MyClass");
I think y
Hi Stas,
On 07/11/2011 11:25 AM, Stas Malyshev wrote:
Hi!
On 7/11/11 12:18 AM, Dmitry Stogov wrote:
Hi Ralph,
I don't have strong opinion about your suggestion.
In some cases this warning might help to find a typo, in others it may
be useless, but anyway, I think that usage of undefined clas
Hi!
That warning might be only emitted if the first operand is a name of non
existing class.
is_a("NonExistingClass", "MyClass");
I think you've missed my point. The point was people use this to check
if first argument is an instance of a certain class or something else -
and "something els
On Mon, Jul 11, 2011 at 09:25, Stas Malyshev wrote:
> Hi!
>
> On 7/11/11 12:18 AM, Dmitry Stogov wrote:
>>
>> Hi Ralph,
>>
>> I don't have strong opinion about your suggestion.
>>
>> In some cases this warning might help to find a typo, in others it may
>> be useless, but anyway, I think that usag
Hi!
On 7/11/11 12:18 AM, Dmitry Stogov wrote:
Hi Ralph,
I don't have strong opinion about your suggestion.
In some cases this warning might help to find a typo, in others it may
be useless, but anyway, I think that usage of undefined class name is a
quite rare situation. I would prefer to keep
Hi Ralph,
I don't have strong opinion about your suggestion.
In some cases this warning might help to find a typo, in others it may
be useless, but anyway, I think that usage of undefined class name is a
quite rare situation. I would prefer to keep it as is.
Thanks. Dmitry.
On 07/08/2011 06
Oh by all means, kill the warning. The behavior is sound though (the fix
for the issue reported in #53727 where a missing parent *ce would affect
the is_a_impl()'s ability to correctly determine it's subtype.
The question is, should we keep the warning in 5.4? I'd say no, I think
false should
Hi Folks:
On Thu, Jul 07, 2011 at 02:20:50PM -0700, Stas Malyshev wrote:
>
> In fact, I'm not sure why would we need such warning at all. Unknown
> class - return false, who cares?
+1
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intens
Hi!
On 7/7/11 2:08 PM, Johannes Schlüter wrote:
On Thu, 2011-07-07 at 20:27 +0200, Pierre Joye wrote:
what kind of troubles do they see?
https://pear.php.net/bugs/bug.php?id=18656
Even if the Warning is good it's questionable for 5.3, especially during
RC.
Yes, I had problem with it too in
On Thu, 2011-07-07 at 20:27 +0200, Pierre Joye wrote:
> what kind of troubles do they see?
https://pear.php.net/bugs/bug.php?id=18656
Even if the Warning is good it's questionable for 5.3, especially during
RC.
(note that warnings not only cause the error being reported, which can
be switched off
what kind of troubles do they see?
2011/7/7 Johannes Schlüter :
> Hi,
>
> I was told (didn't verify) that this causes lots of trouble with PEAR
> and other applications. We're in final RC phase of 5.3.7. I don't think
> it is critical for 5.3.7 and I wonder whether we need it for 5.3 at all.
>
> j
On Sat, 30 Oct 2010 16:56:36 +0100, Pierre Joye
wrote:
This directive is documented only to be used with FTP.
The documentation was wrong, and has also been fixed. According to the bug
report, this directive has been used for http for the last 8 years.
Yes it would be nice to fully su
hi,
On Sat, Oct 30, 2010 at 3:43 PM, Gustavo Lopes wrote:
> The From: header is actually valid in http (see section 14.21 of RFC 2616)
> and is appropriately used in PHP, as it is.
>
> Yes, this should arguably be a context option for http/ftp wrappers, though
> one could argue it's a global se
The From: header is actually valid in http (see section 14.21 of RFC 2616) and
is appropriately used in PHP, as it is.
Yes, this should arguably be a context option for http/ftp wrappers, though one
could argue it's a global setting that happens to reflect on those wrappers.
In any case, that i
> Here you are changing a structure which is allocated and initialized in
> a driver and then read from the PDO core. PDO core will therefore read
> invalid memory when a driver compiled against 5.3.2 is used in 5.3.3
> while we usually guarantee binary compatibility in bug fix releases.
>
> This f
On Tue, May 18, 2010 at 10:24, Michael Wallner wrote:
> On 05/18/2010 10:12 AM, Hannes Magnusson wrote:
>>
>> Where is that commit?
>> Most context options are quite well documented, so I'd appreciate more
>> info about this.
>
> http://news.php.net/php.doc.cvs/6187
>
Hah! Kudos.
-Hannes
--
PH
-
> From: Garrett Serack [mailto:garre...@microsoft.com]
> Sent: Thursday, August 20, 2009 7:24 AM
> To: Stas Malyshev; Pierre
> Cc: 'PHP Internals'
> Subject: RE: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/
branches/PHP_5_3/NEWS
> branches/PHP_5_3/TSRM/tsrm_win32.c trunk/T
it is reverted already.
On Thu, Aug 20, 2009 at 4:24 PM, Garrett Serack wrote:
> Dammit.
>
> I am indeed wrong in this. I was pretty sure that popen on Unix
> *didn't* go via 'sh', but after digging deeper, you are completely
> correct.
>
> We should revert that patch, and I'll write a new separat
Dammit.
I am indeed wrong in this. I was pretty sure that popen on Unix
*didn't* go via 'sh', but after digging deeper, you are completely
correct.
We should revert that patch, and I'll write a new separate routine
that doesn't use cmd.exe as a gateway.
My Apologies.
G
-Original Message---
2009/8/19 Stanislav Malyshev :
> Hi!
>
>> Initially, this prevents popen_ex from failing when the actual
>> executable doesn't exist, since "cmd.exe /c c:\foo\bar\xxx.exe" will
>> *always* successfully start a process. This can be seen in bug
>> #43327.
>>
>> Second, is that by having the intermedi
29 matches
Mail list logo
