Hi
On 9/11/24 16:18, Derick Rethans wrote:
I had a look just now, and tried it out. But I can't reproduce the
error.
FWIW: I had the same issue today, when I updated the PHP 8.4 bulk
deprecation RFC to link the E_STRICT commit:
https://wiki.php.net/rfc/deprecations_php_8_4?do=revisions
I d
On Wed, 4 Sep 2024, Derick Rethans wrote:
> On 4 September 2024 21:32:10 BST, Rob Landers wrote:
> >On Wed, Sep 4, 2024, at 22:26, Derick Rethans wrote:
> >> On 4 September 2024 21:15:55 BST, Rob Landers wrote:
> >> >
> >> >I receive the following error when saving an RFC:
> >> >
> >> >There was
On 04.09.2024 at 22:15, Rob Landers wrote:
> I receive the following error when saving an RFC:
>
> There was an unexpected problem communicating with SMTP: Unexpected return
> code - Expected: 250, Got: 554 | 554 5.5.2 <[i:p:v:6::addr]>: Helo command
> rejected: invalid ip address
>
> From what
On 4 September 2024 21:32:10 BST, Rob Landers wrote:
>On Wed, Sep 4, 2024, at 22:26, Derick Rethans wrote:
>> On 4 September 2024 21:15:55 BST, Rob Landers wrote:
>> >Hello Internals,
>> >
>> >I receive the following error when saving an RFC:
>> >
>> >There was an unexpected problem communicating
On Wed, Sep 4, 2024, at 22:26, Derick Rethans wrote:
> On 4 September 2024 21:15:55 BST, Rob Landers wrote:
> >Hello Internals,
> >
> >I receive the following error when saving an RFC:
> >
> >There was an unexpected problem communicating with SMTP: Unexpected return
> >code - Expected: 250, Got:
On 4 September 2024 21:15:55 BST, Rob Landers wrote:
>Hello Internals,
>
>I receive the following error when saving an RFC:
>
>There was an unexpected problem communicating with SMTP: Unexpected return
>code - Expected: 250, Got: 554 | 554 5.5.2 <[i:p:v:6::addr]>: Helo command
>rejected: invalid
Hello Internals,
I receive the following error when saving an RFC:
There was an unexpected problem communicating with SMTP: Unexpected return code
- Expected: 250, Got: 554 | 554 5.5.2 <[i:p:v:6::addr]>: Helo command rejected:
invalid ip address
>From what I can gather, whatever SMTP server it
Hi!
> But I'm not sure how it's supposed to work. Is it correct that on GCC
> (and clang, presumably, since it defines __GNUC__) accept long bitshifts
> and do the right thing with argument like 138? Is it documented
> anywhere? Or is there a bug here?
>
>
> This is a bug, yes. O
On Wed, Mar 6, 2019 at 1:28 AM Stanislav Malyshev
wrote:
> Hi!
>
> I've been working on running PHP with undefined behavior sanitizer
> (http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html) and I've
> encountered a weird error while running PHP:
>
> /src/php-src/Zend/zend_alloc.c:585:9: ru
Hi!
I've been working on running PHP with undefined behavior sanitizer
(http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html) and I've
encountered a weird error while running PHP:
/src/php-src/Zend/zend_alloc.c:585:9: runtime error: shift exponent 138
is too large for 64-bit type 'zend_mm_b
Hello,
Am 22.03.2018 um 06:59 schrieb CHU Zhaowei:
> There is a related bug report: https://bugs.php.net/bug.php?id=75931
Thank you for pointing out this bug report. It is about stream filters
(extending the php_user_filter class) and not about stream wrappers
which seem to have similar issues.
There is a related bug report: https://bugs.php.net/bug.php?id=75931
It also point out that the construcor method has been ignored.
Best regards,
CHU Zhaowei
On 20/03/2018 22:13, Dennis Birkholz wrote:
P.s.:
In addition to the call order, in auto-close case autoloading with
registered autoloaders does not work inside stream_flush and
stream_close, it seems registered autoloaders (maybe all objects) have
been dispatched when the calls happen, see: http
Hello again,
Am 20.03.2018 um 23:13 schrieb Dennis Birkholz:
> (I also appended both example files as I don't know how long snippets at
> 3v4l.org persist)
the list does not allow attachments, so inline. If this does not work,
3v4l must suffice.
Greets,
Dennis
id = self::$counter++;
}
Hello together,
today I noticed that the order in which stream_flush/stream_close and
the destructor of a (userspace implemented) stream wrapper are called is
weird:
When a stream is closed with fclose(), the call order is as expected:
stream_flush, stream_close, finally the destructor.
But if th
kes sense (for array)
>
> e.g. $a[$n]++ should change the type of array.
>
I
>
> Thanks. Dmitry.
>
>
> --
> *From:* Xinchen Hui
> *Sent:* Monday, October 30, 2017 10:05:30 AM
> *To:* Derick Rethans
> *Cc:* Dmitry Stogov; Nikita Popov;
Thanks. Dmitry.
From: Xinchen Hui
Sent: Monday, October 30, 2017 10:05:30 AM
To: Derick Rethans
Cc: Dmitry Stogov; Nikita Popov; PHP Developers Mailing List
Subject: Re: [PHP-DEV] Weird PHP 7.2 bug
Hey:
On Mon, Oct 30, 2017 at 2:48 AM, Derick Rethans
mailto:der...@php.net>> wrote
Hey:
On Mon, Oct 30, 2017 at 2:48 AM, Derick Rethans wrote:
> Hi,
>
> running:
> https://raw.githubusercontent.com/xdebug/xdebug/master/tests/bug01263.inc
>
> with:
> $ php -n -dzend_extension=opcache.so -dopcache.enable_cli=1
> tests/bug01263.inc
>
> Produces the following output with PHP 7.2 b
Hi,
running:
https://raw.githubusercontent.com/xdebug/xdebug/master/tests/bug01263.inc
with:
$ php -n -dzend_extension=opcache.so -dopcache.enable_cli=1 tests/bug01263.inc
Produces the following output with PHP 7.2 build at Oct 29 2017 18:49:58:
In function PHP_CodeCoverage::addUncoveredFilesFr
Bob,
I see you already committed this into PHP-5.6.
I would agree that new behavior is more consistent and may be committed
into master, but I'm still afraid that it may bring as problems because of
last minute changes and lack of tests coverage.
Thanks. Dmitry.
On Sun, Jul 27, 2014 at 3:02 PM
Am 27.7.2014 um 10:55 schrieb Stas Malyshev :
> Hi!
>
>> Yes, I agree that this is not correct behavior - and I don't really
>> understand why it was introduced and why it isn't trivial to fix.
>> PHP-5.5 had a check for this case in place
>> (http://lxr.php.net/xref/PHP_5_5/Zend/zend_compile.c#70
Hi!
> Yes, I agree that this is not correct behavior - and I don't really
> understand why it was introduced and why it isn't trivial to fix.
> PHP-5.5 had a check for this case in place
> (http://lxr.php.net/xref/PHP_5_5/Zend/zend_compile.c#7071) and phpng
> contains an AST-compatible variant of
On Sun, Jul 27, 2014 at 12:02 AM, Stas Malyshev
wrote:
> Hi!
>
> > Could somebody please clarify what issues are still open here? From what
> > I understand, both the opcache issue and the recursion issue are fixed
> > now. What's the discussion about?
>
> As I understand, the issue is that if yo
Hi!
> Could somebody please clarify what issues are still open here? From what
> I understand, both the opcache issue and the recursion issue are fixed
> now. What's the discussion about?
As I understand, the issue is that if you define class constant like this:
class Foo { const Bar = [0]; }
e
On Sat, Jul 26, 2014 at 5:42 PM, Nikita Popov wrote:
> On Fri, Jul 25, 2014 at 11:03 PM, Julien Pauli wrote:
>
> > On Wed, Jul 23, 2014 at 8:12 PM, Dmitry Stogov wrote:
> >
> >> PHP-5.6 is frozen for new features for a long time.
> >> Adding new features after RC is not a good idea.
> >> And we
On Fri, Jul 25, 2014 at 11:03 PM, Julien Pauli wrote:
> On Wed, Jul 23, 2014 at 8:12 PM, Dmitry Stogov wrote:
>
>> PHP-5.6 is frozen for new features for a long time.
>> Adding new features after RC is not a good idea.
>> And we will need some kind of RFC and voting.
>>
>
> I agree here.
>
> Bob
On Wed, Jul 23, 2014 at 8:12 PM, Dmitry Stogov wrote:
> PHP-5.6 is frozen for new features for a long time.
> Adding new features after RC is not a good idea.
> And we will need some kind of RFC and voting.
>
I agree here.
Bob, if you've been late proposing an RFC and couldn't get it up in time
On Fri, Jul 25, 2014 at 4:36 PM, Ferenc Kovacs wrote:
>
>
>
> On Wed, Jul 23, 2014 at 10:45 PM, Bob Weinand wrote:
>
>> Am 23.7.2014 um 22:33 schrieb Stas Malyshev :
>> > Hi!
>> >
>> >> It was a restriction to not support arrays in constant context. It
>> seems
>> >> like nobody can remember why
On Wed, Jul 23, 2014 at 10:45 PM, Bob Weinand wrote:
> Am 23.7.2014 um 22:33 schrieb Stas Malyshev :
> > Hi!
> >
> >> It was a restriction to not support arrays in constant context. It seems
> >> like nobody can remember why it was introduced.
> >
> > My vague recollection is that it had some tro
On Wed, Jul 23, 2014 at 8:20 PM, Pierre Joye wrote:
> hi,
>
> On Wed, Jul 23, 2014 at 10:45 PM, Bob Weinand wrote:
>
> > Well, we still could fix it now, AFAIK, we will still have another RC
> now and when we fix it only for 5.6.1, there also will only be one RC in
> between.
> > That's no gain
hi,
On Wed, Jul 23, 2014 at 10:45 PM, Bob Weinand wrote:
> Well, we still could fix it now, AFAIK, we will still have another RC now and
> when we fix it only for 5.6.1, there also will only be one RC in between.
> That's no gain in testing time etc..
Also please keep in mind that we are alrea
Am 23.7.2014 um 22:33 schrieb Stas Malyshev :
> Hi!
>
>> It was a restriction to not support arrays in constant context. It seems
>> like nobody can remember why it was introduced.
>
> My vague recollection is that it had some troubles with keeping
> refcounts consistent, esp. withing bytecode ca
Hi!
> It was a restriction to not support arrays in constant context. It seems
> like nobody can remember why it was introduced.
My vague recollection is that it had some troubles with keeping
refcounts consistent, esp. withing bytecode caching context, but it may
be a false memory :)
> However,
PHP-5.6 is frozen for new features for a long time.
Adding new features after RC is not a good idea.
And we will need some kind of RFC and voting.
I help you technically, but you know my opinion about this feature..
anyway, lets fix bugs first, I got an idea that may work...
Thanks. Dmitry.
On
Am 23.7.2014 um 11:34 schrieb Dmitry Stogov :
> On Wed, Jul 23, 2014 at 1:20 PM, Bob Weinand wrote:
>
>> Yes. Did you see my thoughts before?
>>
>> I'm just wondering if we can't somehow deeply copy the asts for opcache
>>> between compile time and run time in pass_two() (If I'm not wrong
>>> pa
On Wed, Jul 23, 2014 at 1:20 PM, Bob Weinand wrote:
> Yes. Did you see my thoughts before?
>
> I'm just wondering if we can't somehow deeply copy the asts for opcache
>> between compile time and run time in pass_two() (If I'm not wrong
>> pass_two() has some hook for zend extensions?)
>>
>> Then
Yes. Did you see my thoughts before?
> I'm just wondering if we can't somehow deeply copy the asts for opcache
> between compile time and run time in pass_two() (If I'm not wrong pass_two()
> has some hook for zend extensions?)
>
> Then we can fix the ast and don't have to take care of opcache
On Wed, Jul 23, 2014 at 12:16 PM, Bob Weinand wrote:
> Hey, thank you for looking into it :-)
>
> Am 23.7.2014 um 00:23 schrieb Dmitry Stogov :
> > hi Bob,
> >
> > I still think that current array usage in constant expressions is not
> > consistent and dangerous. It "smells" to me, and I think it
Hi!
>> > class Foo {
>>const BAR = [0];
>>static $a = Foo::BAR; // constant array usage
>> }
>> var_dump(Foo::$a); // prints array
>> var_dump(Foo::BAR); // emits fatal error
>> ?>
>
> They can only be used in static scalar contexts.
>
> I wanted to introduce constants to be used an
Hey, thank you for looking into it :-)
Am 23.7.2014 um 00:23 schrieb Dmitry Stogov :
> hi Bob,
>
> I still think that current array usage in constant expressions is not
> consistent and dangerous. It "smells" to me, and I think it may bring
> troubles in the future even if the existing known bugs
hi Bob,
I still think that current array usage in constant expressions is not
consistent and dangerous. It "smells" to me, and I think it may bring
troubles in the future even if the existing known bugs are fixed.
I see few issues:
1) It is possible to declare array class constants however they
I can reproduce it. Seems to be off-by-one here:
Z_STRVAL_P(result) = target = safe_emalloc(char_count, to_len, len);
introduced by this patch:
http://cvs.php.net/viewvc.cgi/php-src/ext/standard/string.c?r1=1.445.2.14.2.36&r2=1.445.2.14.2.37
If I replace len with len+1, it seems to be OK.
On Sat, 12 Mar 2005, Wez Furlong wrote:
> Yesterday I saw some leaks with foreach() and custom zend_iterators.
> Today, the same binary doesn't have those leaks.
>
> I had another similar issue a few weeks back on a different machine,
> but with an overrun reported on shutdown. The next day, the
Thanks for the heads-up. Please keep us posted on any news...
At 09:17 AM 3/12/2005 -0500, Wez Furlong wrote:
Yesterday I saw some leaks with foreach() and custom zend_iterators.
Today, the same binary doesn't have those leaks.
I had another similar issue a few weeks back on a different machine,
bu
Yesterday I saw some leaks with foreach() and custom zend_iterators.
Today, the same binary doesn't have those leaks.
I had another similar issue a few weeks back on a different machine,
but with an overrun reported on shutdown. The next day, the same
binary was fine.
Unless the linux-fairy visi
Sebastian Bergmann wrote:
> Sorry for these lengthy mails but this issue is important to me as it
> hinders the development of PHPUnit2.
Since I was finally able to write a small reproducing script I opened a
bug report for this: http://bugs.php.net/bug.php?id=30209
--
Sebastian Bergmann
Sebastian Bergmann wrote:
> In PHPUnit2 I have the following code:
It seems that I have been at slightly the wrong code
try {
$class = new ReflectionClass($this);
var_dump($this);
$method = $class->getMethod($this->name);
var_dump($this);
exit;
}
obj
Hello Sebastian,
Wednesday, September 22, 2004, 9:52:18 PM, you wrote:
> For quite a while I have been fighting with what I believe to be a bug in
> the Zend Engine 2.
> In PHPUnit2 I have the following code:
>public function run(PHPUnit2_Framework_Test $test) {
>// $test->name:
For quite a while I have been fighting with what I believe to be a bug in
the Zend Engine 2.
In PHPUnit2 I have the following code:
public function run(PHPUnit2_Framework_Test $test) {
// $test->name: string(14) "testGetBalance"
$this->startTest($test);
try {
Antony Dovgal wrote:
It outputs 'bool(false)', while I expect it to print 'int(123)'.
Foo::id is private so Bar::setId() cannot use it. It uses an implicit
public Bar::id (different from Foo::id).
Foo::getId() correctly read the private attribute Foo::id (not the
public Bar::id) and return it.
Hi all!
What do you expect from this code?
id;
}
public function setId ($id) {
return $this->id = $id;
}
}
class Bar extends Foo {
public function setId ($id) {
return $this->id = $id;
}
}
$b = new Bar;
$b
> I don't see anything odd in here. All of the assignments, except for the
> first one ('A'), assign to $this->"" (because $myvar, ${'myvar'} (which is
> the same as $myvar) and ${'$myvar'} (which is basically $"") are all non
> existent variables which implicitly evaluate to "". Try to turn o
At 11:33 14/01/2004, John Coggeshall wrote:
I know that this issue to some extent or another has been brought up
before, but I just wanted to make sure that this is really how things
are supposed to work... Apparently the statements setting B C and D
are all equivalent.
This could be absolutely bog
On Wed, Jan 14, 2004 at 04:33:13AM -0500, John Coggeshall wrote:
> I know that this issue to some extent or another has been brought up
> before, but I just wanted to make sure that this is really how things
> are supposed to work... Apparently the statements setting B C and D
> are all equivalent.
I know that this issue to some extent or another has been brought up
before, but I just wanted to make sure that this is really how things
are supposed to work... Apparently the statements setting B C and D
are all equivalent.
This could be absolutely bogus, but I thought maybe someone could
expla
Something weird is going on in HEAD.
While running the PHPUnit testsuite I get a lot of these warnings
"Invokation of 's constructor failed in on line "
After that a "Debug Assertion Failed!" popup window opens. Backtrace is
as follows
_free_dbg_lk(void * 0x00ade2a0, int 1) line 10
Hello,
when playing around with ext/tokenizer, I found a weird behaviour with
the T_END_HEREDOC token. I got "FOO;;" instead of the expected "FOO"
as token. As a consequence I wrote a patch for the Zend Engine that
should fix ext/tokenizer and makes the special stuff for T_END_HEREDOC
in zend_high
in php4 $this gets passed in All static method calls ,as if they where
parent::sss() - so statically calling one object method from another
object instance will take '$this' with it..
Last word on this 'feature/bug' is that it will be removed in PHP5, (bit
of a bugger - I'm sure some of my old
Hello,
I'm getting a problem with $this being defined where it shouldn't be. The code
that I'm writing is a little weird in order to compensate for the lack of some
OO features in PHP4.
The PHP script at the bottom should give the behavior I'm referring to.
Is PHP5 in a more-or-less stable state
59 matches
Mail list logo
