On Wed, June 7, 2006 8:56 am, Ilia Alshanetsky wrote:
> When it comes to "empty" clone statements, should they be executed
> and then free the result (current behavior) or avoid clone all
> together.
> For example when class x { function __clone() { echo "hello"; } }
> clone new x(); code is execut
Hello Hannes,
Monday, May 29, 2006, 8:52:51 PM, you wrote:
> Hi all
> I've created a patch[1] that welcomes new friend into the
> zend_arg_info family, resource, and a new flag for ZEND_ME_MAPPING and
> pals, ZEND_ACC_INFO_MAP_TO_FUNCTION.
> The idea is to make it easier to define argument info
On 08.06.2006 01:13, Mark Spruiell wrote:
On 08.06.2006 01:56, Antony Dovgal wrote:
Do you have a patch?
I was a bit concerned about the fact that these are
bison-generated files. Doesn't that imply a bug in
whatever version of bison was used to generate these
files? And wouldn't the bug inst
On 08.06.2006 01:56, Antony Dovgal wrote:
> Do you have a patch?
I was a bit concerned about the fact that these are
bison-generated files. Doesn't that imply a bug in
whatever version of bison was used to generate these
files? And wouldn't the bug instantly reappear as soon
as these files are re
On 08.06.2006 01:56, Antony Dovgal wrote:
On 07.06.2006 22:53, Mark Spruiell wrote:
Building PHP 5.1.4 on AIX fails in two places with a syntax error:
Zend/zend_language_parser.c:2585
Zend/zend_ini_parser.c:1081
The offending code is the same in both cases, which is not surprising
since they a
On 07.06.2006 22:53, Mark Spruiell wrote:
Building PHP 5.1.4 on AIX fails in two places with a syntax error:
Zend/zend_language_parser.c:2585
Zend/zend_ini_parser.c:1081
The offending code is the same in both cases, which is not surprising
since they are both bison-generated files:
#if defined
Building PHP 5.1.4 on AIX fails in two places with a syntax error:
Zend/zend_language_parser.c:2585
Zend/zend_ini_parser.c:1081
The offending code is the same in both cases, which is not surprising
since they are both bison-generated files:
#if defined (__STDC__) || defined (__cplusplus)
int
yyp
Hello Ilia,
hello should be printed. As in you cannot outsmart what some people
might do in their code. For example in C++ such stuff gets optimized
out but only as long as the compiler detects that doing so does not
result in a different bahvior. This is something you need to know
for particula
I think that "hello" should be printed. Even if the result of clone()ing
isn't going to be used, the side-effects should always occur (at least to be
consistence). I would bet that other languages would do the same.
Nuno
- Original Message -
When it comes to "empty" clone statements,
When it comes to "empty" clone statements, should they be executed
and then free the result (current behavior) or avoid clone all together.
For example when class x { function __clone() { echo "hello"; } }
clone new x(); code is executed, should it print hello or not print
anything at all, tr
Yesterday some my colleagues were precisely discussing that issue..
I recommend you to submit the patches upstream (to both pcre and libxmlrpc
authors) instead, as we prefer not to change bundled libraries (for
maintenance sake).
Nuno
- Original Message -
Attached is a patch which
Antony Dovgal wrote:
> Please elaborate.
> What exactly are you fixing and how to reproduce it?
http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4
On 07.06.2006 03:06, john wrote:
Attached is a patch which addresses array indices being out of bounds in
pcre and libxmlrpc binary searches.
Please elaborate.
What exactly are you fixing and how to reproduce it?
Index:
13 matches
Mail list logo
