Hello.
There are two bugs that show when code is executed from an object destructor and
PHP is compiled in debug mode. Both bugs cause the zend_hash_find() to fail in the
IS_CONSISTENT() macro.
The first bug shows when the global symtable is destroyed and the destruction of
a symbol causes an
netcat wrote:
Hi, internals.
Please send me (post here i mean) a few links about
1. thread safety in general
2. thread saftey in php
3. I'm doing wrapper for librep wich is not thread
safe (so mailing archives say). Do I need to know
something special ?
After doing some googling i found thise
Hello.
I looked at your patch but why is it better than current code?
In both cases (current code and your code) the symtable and all objects are destroyed.
What is the difference?
-
http://www.Elmaz.com -
--
PHP Internals - PHP
Hi,
I would appreciate it if the database extensions would no longer return
false when no rows are left in the result set but instead return null.
The current way of returning false creates a level of ambiguity which can
lead to serious issue in error handling.
For example in mysql there is no
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I wouldn't mind such a change myself, however what about all the installations
where people do while (*fetch_row() !== false) ?
Ilia
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 22, 2003 7:18 PM
To: Lukas Smith; 'PHP Development'
Subject: Re: [PHP-DEV] database driver: no more rows
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I wouldn't mind such a change myself, however what about all
I wouldn't mind such a change myself, however what about all the
installations
where people do while (*fetch_row() !== false) ?
Wouldn't it be a lot easier to do it the other way around ?
I mean, the semantics of returning false when a fetch cannot be executed
because aren't any rows left is
From: Ard Biesheuvel [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 22, 2003 7:56 PM
To: [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] database driver: no more rows
I wouldn't mind such a change myself, however what about all the
installations
where people do while (*fetch_row() !== false)
Hello everybody,
just joined the internals list (after being absent from php developers
lists for a while) so excuse my ignorance if any topic I bring up has
been discussed already. I checked the archives but couldn't find anything...
Proposal: Allow dangling commas in function call parameters.
At 11:49 PM 10/22/2003 +0200, Ard Biesheuvel wrote:
Err .. I don't agree.
Null means no data
False means error.
Maybe historically (PHP-wise) it does.
But the way I see it, every fetch() can 'fail' for two reasons: an
expected well-defined reason (eof), and an unexpected undefined reason
From: Andi Gutmans [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 22, 2003 11:58 PM
At 11:49 PM 10/22/2003 +0200, Ard Biesheuvel wrote:
Err .. I don't agree.
Null means no data
False means error.
Maybe historically (PHP-wise) it does.
But the way I see it, every fetch() can 'fail'
At 12:00 AM 10/23/2003 +0200, Lukas Smith wrote:
From: Andi Gutmans [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 22, 2003 11:58 PM
At 11:49 PM 10/22/2003 +0200, Ard Biesheuvel wrote:
Err .. I don't agree.
Null means no data
False means error.
Maybe historically (PHP-wise) it does.
At 06:04 PM 10/22/2003 -0400, [EMAIL PROTECTED] wrote:
Well, this would be my first time contributing to any discussion on this
list since I joined, but I have a question.
It was suggested that this be implemented in PHP 5.0.0. Isn't PHP 5 so
much different than PHP 4 that scripts would have
From: Andi Gutmans [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 23, 2003 12:06 AM
I don't think I've had any experince with those functions returning FALSE
for me, but I think it's more logical that they differentiate between the
FALSE and the NULL for the reasons stated above.
How
The methods of an object that has been passed to the overload()
function lose their ability to have parameters passed by reference. For
example:
class Foo
{
function hello($array)
{
$array[] = hello;
}
}
$array = null;
$foo = new foo();
$foo-hello($array);
print_r($array)
/home/sarag/cvs/php5/Zend/zend_default_classes.c:508: undefined reference to
`zend_register_interfaces'
Looks like zend_interfaces.o isn't being bulit/linked. Does this belong in
an autoconf file somewhere?
Marcus Boerger [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
helly Wed Oct
Hi,
The methods of an object that has been passed to the overload()
function lose their ability to have parameters passed by
reference. For
example:
class Foo
{
function hello($array)
{
$array[] = hello;
}
}
$array = null;
$foo = new foo();
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Already fixed.
Ilia
On October 22, 2003 07:38 pm, Sara Golemon wrote:
/home/sarag/cvs/php5/Zend/zend_default_classes.c:508: undefined reference
to `zend_register_interfaces'
Looks like zend_interfaces.o isn't being bulit/linked. Does this
The fix is inside php-src/configure.in, the zend_interfaces.c was not being
compiled.
Ilia
On October 22, 2003 08:31 pm, Sara Golemon wrote:
Not to be pedantic about it, but where?
My checkout is still broken (despite a total scrubdown and rebuild), and
(while I'm not a makefile expert) I
There is already a bug report on it, however It sounds like it's
unlikely to be fixed in PHP4...
Regards
Alan
[EMAIL PROTECTED] wrote:
The methods of an object that has been passed to the overload() function
lose their ability to have parameters passed by reference. For example:
class Foo
{
20 matches
Mail list logo
