Rasmus Lerdorf <[EMAIL PROTECTED]> writes:
> You need a php.ini file to reproduce the problem.
OK, thanks. With everybody's help I reproduced the problem.
It turns out to be a portability bug in Zend/zend_ini_parser.y.
That grammar uses the character constant '\0' as a token.
POSIX says that th
"Wez Furlong" <[EMAIL PROTECTED]> writes:
> The original response to this issue from the bison people was the
> not very encouraging "thou shalt not use the skeleton file".
> ... the bison team had made it apparent in the past
> that they were not interested in fixing the problem.
Sorry, I don't
Paul Eggert wrote:
> 2003-10-06 Paul Eggert <[EMAIL PROTECTED]>
>
> * Zend/zend_ini_parser.y:
> This fixes PHP bugs #25770 and #21159.
Seems fixed indeed, no longer segfaults on my GENTOO/Linux laptop with
bison 1.875.
Thanks Paul,
Sebastian
--
Sebastian Bergmann
http://se
Don't forget register_argv_argc php.ini directive. :)
--Jani
On Mon, 6 Oct 2003, Rasmus Lerdorf wrote:
>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 s
I want to maintain the Net_LDAP code in CVS.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RL>> Andrei and I discussed this change and at the conceptual level at least
RL>> $_SERVER should be populated with argc and argv if variables_order
RL>> includes "S". If you have specifically configured your system to not
RL>> create $_SERVER, then of course it shouldn't be there. The change
Hi internals.
[background]
I'm newbie here and with php extensions.
Working on php extension.
It should give access to librep.
I have very little experience with C.
[problem]
zval f1(some_args) {
zval r;
...
return r;
}
/* f1 can return many different types */
ZEND_FUNCTION(f2) {
/* working
At 05:18 07/10/2003, Rasmus Lerdorf wrote:
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 variable
Yeap - Tarjei is the maintainer
http://pear.php.net/package/Net_LDAP
Regards
Alan
Tarjei Huse wrote:
I want to maintain the Net_LDAP code in CVS.
--
Can you help out?
Need Consulting Services or Know of a Job?
http://www.akbkhome.com
--
PHP Internals - PHP Runtime Development Mailing List
To uns
Zitat von Jay Smith <[EMAIL PROTECTED]>:
> 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.
This might be true, but the str_* functions for exa
PHP_FUNCTION (or ZEND_FUNCTION - they are the same)
includes the function paramters; one of those is:
zval *return_value;
which already contains an allocated zval (set to NULL).
If you want to change this in one of your own functions, you could
do something like this:
int f1(zval *return_value,
Hi internals.
After looking at "Zend/zend_hash.h" e.t.c and haven't
realizing how should i do that,i'm asking for your help.
It should be really simple for you
Have the following function:
it should recursively convert data from rep_XXX to php data
It does that for string and numbers for now.
On Tue, Oct 07, 2003 at 02:40:19AM +0300, Jani Taskinen wrote:
>
> 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. :)
>
Wez Furlong wrote:
PHP_FUNCTION (or ZEND_FUNCTION - they are the same)
includes the function paramters; one of those is:
zval *return_value;
which already contains an allocated zval (set to NULL).
If you want to change this in one of your own functions, you could
do something like this:
int f1(z
Try something like this:
if (rep_CONSP(in)) {
array_init(return_value); /* sets it up as an array */
for (i = in; i != Qnil; i = rep_CDR(i)) {
zval *tmp;
MAKE_STD_ZVAL(tmp);
rep_data_converter(rep_CAR(i), tmp);
add_next_index_zval(return_value, tmp); /* equivalent
Wez Furlong wrote:
Try something like this:
if (rep_CONSP(in)) {
array_init(return_value); /* sets it up as an array */
for (i = in; i != Qnil; i = rep_CDR(i)) {
zval *tmp;
MAKE_STD_ZVAL(tmp);
rep_data_converter(rep_CAR(i), tmp);
add_next_index_zval(return_value, tmp); /*
That backtrace isn't useful (running windows?)
Try a debug build, under unix if you have access to it.
Chances are that it is your code that is at fault :-)
--Wez.
> Backtrace in `fatal_signal_handler':
> <(null)+1107463240>
>
>
>
>
>
>
On Tue, 7 Oct 2003, Stefan Walk wrote:
> On Tue, Oct 07, 2003 at 02:40:19AM +0300, Jani Taskinen wrote:
> >
> > 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 s
Wez Furlong wrote:
That backtrace isn't useful (running windows?)
Yuck... never... windows cannot (must not) live outside VmWare :)
Try a debug build, under unix if you have access to it.
Will look for that. How fast it became not nice to me
Chances are that it is your code that is at
On Tue, Oct 07, 2003 at 03:18:59PM +0200, Derick Rethans wrote:
> > What is the problem with array_* functions casting implicitely? The vast
> > majority of php functions does implicit casting, array_splice does it,
> > everyone is used to it, PHP is known for it... why go the other way now?
>
> B
I need some kind of engine hook to allow this kind of code in the COM
extension:
foreach ($container as $child) {
echo $child->name;
}
The way this works in COM is like this:
foreach fetches the magic iterator property from $container.
The magic iterator is an instance of IEnumXXX, where XXX
On Tue, 7 Oct 2003, Jani Taskinen wrote:
> Don't forget register_argv_argc php.ini directive. :)
Right, that is what this patch fixed basically. register_argv_argc didn't
works if variables_order didn't include "S" which to me makes no sense.
-Rasmus
--
PHP Internals - PHP Runtime Develop
On Tue, 7 Oct 2003, Zeev Suraski wrote:
> At 05:18 07/10/2003, Rasmus Lerdorf wrote:
> >My big problem with this approach is that when variables_order does not
> >include "S" then it seems inconsistent to have a partially populated
> >$_SERVER array. If $_SERVER['argc'] is there, why aren't other
On Tue, 7 Oct 2003, Rasmus Lerdorf wrote:
> On Tue, 7 Oct 2003, Jani Taskinen wrote:
> > Don't forget register_argv_argc php.ini directive. :)
>
> Right, that is what this patch fixed basically. register_argv_argc didn't
> works if variables_order didn't include "S" which to me makes no sen
Wez Furlong wrote:
That backtrace isn't useful (running windows?)
Try a debug build, under unix if you have access to it.
Chances are that it is your code that is at fault :-)
Yep. It looked strange to me adding items to zval without even mentioning
it's array. So I looked in other places
Perhaps, if PEAR developers wrote proper code & did not rely upon unsupported
& undocumented features we would not have this problem. While they do, these
problems will occur. If you do not write proper code, either don't turn on
warnings & notices (that supposed to help you write proper code) o
On Mon, Oct 06, 2003 at 07:10:20PM -0400, Ilia Alshanetsky wrote:
> > 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.
>
> Perhaps, i
Zitat von Ilia Alshanetsky <[EMAIL PROTECTED]>:
> Perhaps, if PEAR developers wrote proper code & did not rely upon
> unsupported
> & undocumented features we would not have this problem. While they do,
> these
> problems will occur. If you do not write proper code, either don't turn
> on
> warnin
On October 7, 2003 08:19 pm, Jon Parise wrote:
> By your definition, the code was "proper" (i.e. did not generate
> warnings) until the underlying rules were changed, and I'm sure we all
> agree that that's a silly definition of "proper code".
Well, you are claiming that a code that relies on an i
Majority (if not all) array function, will error out when they encounter a
variable that is not array when an array argument is expected. If anything
this patch add consistency that helps to make code clearer. Heck, Is suspect
a far number of people will be able to find bugs in their code beca
Zitat von Ilia Alshanetsky <[EMAIL PROTECTED]>:
>$a = null;
> sort($a);
> ?>
>
> Majority (if not all) array function, will error out when they encounter
> a
> variable that is not array when an array argument is expected. If
> anything
> this patch add consistency that helps to ma
On Tue, Oct 07, 2003 at 08:36:11PM -0400, Ilia Alshanetsky wrote:
> On October 7, 2003 08:19 pm, Jon Parise wrote:
> > By your definition, the code was "proper" (i.e. did not generate
> > warnings) until the underlying rules were changed, and I'm sure we all
> > agree that that's a silly definitio
On October 7, 2003 08:45 pm, Jan Schneider wrote:
> I never said that the current behaviour is in any way consistent. But which
> behaviour the more logical one is, is debateable. Many languages support
> context dependant implicit casting, and PHP even says so explicitely in the
> manual. Why shou
On October 7, 2003 08:47 pm, Jon Parise wrote:
> No, I'm not. I'm saying it used to run without producing any errors,
> and that status quo should be preserved in a bugfix release. Aside
> from being "illogical" and inconsistent, I don't see how changing this
> behavior qualifies as a bug fix.
T
34 matches
Mail list logo
