Martin Schlemmer <[EMAIL PROTECTED]> writes:
> > #0 0x0823c5e8 in zend_stream_read (file_handle=0x0, buf=0x83c4e10 "",
> > len=8192) at /usr/src/php/php5/Zend/zend_stream.c:95
> > #1 0x0820ebbf in yy_get_next_buffer () at Zend/zend_ini_scanner.c:1242
> > ...
>
> I am still trying to track this
Just don't use bison 1.875
--Wez.
- Original Message -
From: "Paul Eggert" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, October 06, 2003 6:24 AM
Subject: [PHP-DEV] Re: Segfault with PHP and bison 1.875(a)
> Martin Schlemmer
I want to contribute to and maintain PEAR packages Auth/LDAP and Net/LDAP where I have
already submitted some patches in the past. Access would be needed to pear.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
"Wez Furlong" <[EMAIL PROTECTED]> writes:
> Just don't use bison 1.875
We're trying to get the Bison bug (if there is one) fixed.
Possibly the bug is in flex, or is in PHP itself.
I understand that the PHP folks prefer to use older version of
software tools if they happen to work, and that's
Do you experience this bug with PHP 4.3.2?
Zeev
At 18:29 06/10/2003, Paul Eggert wrote:
"Wez Furlong" <[EMAIL PROTECTED]> writes:
> Just don't use bison 1.875
We're trying to get the Bison bug (if there is one) fixed.
Possibly the bug is in flex, or is in PHP itself.
I understand that the P
The bug is there with the current PHP4_3 HEAD. Haven't tried compiling
4.3.2 with 1.875.
-Rasmus
On Mon, 6 Oct 2003, Zeev Suraski wrote:
> Do you experience this bug with PHP 4.3.2?
>
> Zeev
>
> At 18:29 06/10/2003, Paul Eggert wrote:
> >"Wez Furlong" <[EMAIL PROTECTED]> writes:
> >
> > > Ju
> > Just don't use bison 1.875
> If you can't help us solve the problem, fine; but please don't
> discourage other people from helping.
Step back a moment and consider...
The original response to this issue from the bison people was the
not very encouraging "thou shalt not use the skeleton fi
At 18:50 06/10/2003, Rasmus Lerdorf wrote:
The bug is there with the current PHP4_3 HEAD. Haven't tried compiling
4.3.2 with 1.875.
Well, judging by the suggested patch at the report for bug #22215, it
appears it might be somehow related to the fd patch, so it's interesting to
see whether 4.3.2
Jan Schneider wrote:
>
> Will this be fixed before the 4.3.4 release?
This is Ilia's release, and he's made it clear he'd rather see it in there
(as would I, given that there probably won't be a 4.4 release between 4.3
and 5.0) so as far as I know, the current code is remaining.
J
--
PHP Inte
Zeev Suraski <[EMAIL PROTECTED]> writes:
> Do you experience this bug with PHP 4.3.2?
Here's how I tried to reproduce the problem. I am running Debian
GNU/Linux 3.0r1 (stable) with Bison 1.875.
wget http://downloads.php.net/ilia/php-4.3.4RC1.tar.bz2
tar xjf php-4.3.4RC1.tar.bz2
cd php-4.3
On 6 Oct 2003, Paul Eggert wrote:
> Here's how I tried to reproduce the problem. I am running Debian
> GNU/Linux 3.0r1 (stable) with Bison 1.875.
You need a php.ini file to reproduce the problem. Here is how to figure
out where it wants it:
% php -i | grep ini
Configuration File (php.ini) Path
Have you tried running "pear list" recently?
We REALLY should remove the E_NOTICE part as Jan very sensibly
pointed out it would cause problems. Well, the first of these is in our
very own distro.
--Wez.
- Original Message -
From: "Jay Smith" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Passing array_merge*() anything else but arrays is undocumented.
These functions were meant to be used on arrays and this change
(very, VERY minor change, if I may say so) just "fixes" this.
RTFM. :)
--Jani
On Mon, 6 Oct 2003, Wez Furlong wrote:
>Have you tried
Zitat von Jani Taskinen <[EMAIL PROTECTED]>:
> Passing array_merge*() anything else but arrays is undocumented.
> These functions were meant to be used on arrays and this change
> (very, VERY minor change, if I may say so) just "fixes" this.
The only case I really care about are NULLs
Most of the other array functions are more stringent -- they don't throw
E_NOTICEs, they throw E_WARNINGs. array_intersect(), array_diff() and
array_sum() being the ones that I can think of offhand.
J
Jan Schneider wrote:
> Zitat von Jani Taskinen <[EMAIL PROTECTED]>:
>
>> Passing array_m
MRS. EKI OMORODION
#8 Queens Drive
Ikoyi Lagos.
Email:[EMAIL PROTECTED]
INTRODUCTION: l am Mrs. Eki Omorodion l know this proposal will come to
you as a surprise because we have not met before either Physically or
through correspondence.
I have no doubt in your ability to handle this proposal inv
Can you tell us which version of PHP is causing the bug and include a
backtrace of the following problem?
Oliver
MRS EKI OMORODION wrote:
MRS. EKI OMORODION
#8 Queens Drive
Ikoyi Lagos.
Email:[EMAIL PROTECTED]
INTRODUCTION: l am Mrs. Eki Omorodion l know this proposal will come to
you as a
> > > You're not breaking code (since it can always use $_SERVER) and you're
> > > not introducing any globals (which goes along with the
register_globals
> > > setting).
> >
> >Sure you are, you are creating the global $_SERVER which was specifically
> >not enabled in your scenario.
>
> I may be m
On Mon, 6 Oct 2003, Greg MacLellan wrote:
> That was my argument. I was saying that instead of ALWAYS creating $argv and
> $argc, regardless of register_global status, it should ALWAYS create
> $_SERVER['argv'] and $_SERVER['argc'], regardless of variables_order
> setting.
>
> This has the double-
> > That was my argument. I was saying that instead of ALWAYS creating $argv
and
> > $argc, regardless of register_global status, it should ALWAYS create
> > $_SERVER['argv'] and $_SERVER['argc'], regardless of variables_order
> > setting.
>
> My big problem with this approach is that when variable
On Mon, 6 Oct 2003, Greg MacLellan wrote:
> > > That was my argument. I was saying that instead of ALWAYS creating $argv
> and
> > > $argc, regardless of register_global status, it should ALWAYS create
> > > $_SERVER['argv'] and $_SERVER['argc'], regardless of variables_order
> > > setting.
> >
> >
Need to learn more about cvs
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
22 matches
Mail list logo
