Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)

[Ilia Alshanetsky]

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.

The real fix (E_WARNING) is in PHP 5.0, in order to inform developers that a 
certain (incorrect in this case) behavior will no longer be supported an 
E_NOTICE is issued to inform them of the situation. The longer we wait the 
more people will rely upon invalid functionality and 24 month down the road 
we will have no choice but to keep brokenness in PHP due to BC issues as was 
the case in similar situations.

> Which just goes to show that the authors of the PEAR library (who are
> not ignorant of the PHP language and its constraints) were under the
> assumption that the code was correct at the time that is was written.

Just because something works does not mean it is correct. You can write code 
with only E_ERROR reporting level and have it work. But, not everyone runs 
with such an insanely low error reporting level. Many things work in PHP, but 
it does not mean using that functionality is correct.

Ilia

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)

[Ilia Alshanetsky]

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 should this now be incorrect, not logical or not "proper"?

Incosistent behaviour is a problem, whether it is a serious problem or a 
trivial one depends on a situation, however it does not change the fact it is 
a problem. IMO when a function expects an array it should error out when the 
argument it recieves is not array, with a possible exception of object's who 
in ZE1 are nearly identical to arrays. Further more there is already an 
fairly large number of functions of a similar function that operate in a 
similar manner. It only makes sense to fix the one or two that do not.

Ilia

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)

[Jon Parise]

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 definition of "proper code".
> 
> Well, you are claiming that a code that relies on an illogical and 
> undocumented 'feature' is proper?

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.

Fix it in a major revision, and we'll all be happen in 24 months or so
when everyone upgrades.

> PEAR is the official PHP library, which many people will undoubtedly use to 
> learn by example. IMHO that means that PEAR libraries especially the ones 
> part of the 'core' (automatically distributed) packages contain exemplary 
> code other people can safely learn from?

Which just goes to show that the authors of the PEAR library (who are
not ignorant of the PHP language and its constraints) were under the
assumption that the code was correct at the time that is was written.

-- 
Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/)

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)

[Jan Schneider]

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 make code clearer. Heck, Is
> suspect
> a far number of people will be able to find bugs in their code because
> they
> will now be warned that a function is getting a string/null/etc...
> instead
> silently accepting any argument.

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 should this now be incorrect, not logical or not "proper"?

You can safely argue the opposite, namely that no array function should
raise a warning but instead cast the value to an array.

Jan.

--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)

[Ilia Alshanetsky]

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 because they 
will now be warned that a function is getting a string/null/etc... instead 
silently accepting any argument.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)

[Ilia Alshanetsky]

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 illogical and 
undocumented 'feature' is proper? The function documentation both in the 
manual & the php source comments clearly stated the the only acceptable 
arguments for the function are arrays. Had someone for whatever reasons 
converted the function to use new argument parsing API the same thing 
would've happened. So, unless you would like to argue that PHP's argument 
parsing is wrong this is not a bug.
Even if we were to take other array functions into consideration, you'd notice 
that they would return E_WARNING let a lone a harmless E_NOTICE (blocked by 
most people) when passed a variable of an incorrect type.

PEAR is the official PHP library, which many people will undoubtedly use to 
learn by example. IMHO that means that PEAR libraries especially the ones 
part of the 'core' (automatically distributed) packages contain exemplary 
code other people can safely learn from?

Ilia

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)

[Jan Schneider]

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
> warnings & notices (that supposed to help you write proper code) or take
> the
> time to fix the problem. This by no means is a problem in PHP.

As Stefan pointed out with his link to the PHP manual, this acutally *is*
documented, because it's an implicit cast from a simple type to an array.

>From the manual:

 For any of the types: integer, float, string, boolean and resource, if you
convert a value to an array, you get an array with one element (with index
0), which is the scalar value you started with.

If you convert an object to an array, you get the properties (member
variables) of that object as the array's elements. The keys are the member
variable names.

If you convert a NULL value to an array, you get an empty array.

[...]

 PHP does not require (or support) explicit type definition in variable
declaration; a variable's type is determined by the context in which that
variable is used.

Jan.

--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)

[Jon Parise]

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, 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) or take the 
> time to fix the problem.

That's an elitist and unprofessional stance.

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".

> This by no means is a problem in PHP.

Sorry, I forgot that PHP and PEAR must be playing on separate teams.

-- 
Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/)

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)

[Ilia Alshanetsky]

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) or take the 
time to fix the problem. This by no means is a problem in PHP.

Ilia

On October 6, 2003 06:42 pm, Wez Furlong 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.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] help request: php array

[netcat]

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 
array_init(return_value);
solved the problem.
Than i looked back into your letter.
I just missed this one in your letter,sorry
Thanks again.
--Wez.

 

Backtrace in `fatal_signal_handler':
   <(null)+1107463240>
   
   
   
   
   
   
   
Lisp backtrace:

Segmentation fault
---8<---
Is that rep's or php's problem?
May be t should be duplicated?
If yes, how?
   

 



--
NetCat


---
FREE 10MB Email + AntiSpam + POP3 + more.
Get it at http://www.doal.co.il:81/free/?c=antispam
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] argv and argc on cliphp

[Derick Rethans]

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 sense.

Neither it makes sense to me.

Derick

-- 
"Interpreting what the GPL actually means is a job best left to those
that read the future by examining animal entrails."
-
 Derick Rethans http://derickrethans.nl/ 
 International PHP Magazine  http://php-mag.net/
-

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] argv and argc on cliphp

[Rasmus Lerdorf]

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 normal
> >$_SERVER variables available?  The wtf factor is a little too high for my
> >tastes.
> 
> I think that making $_SERVER dependant on the settings of variables_order 
> was wrong to begin with (I may have caused it to be that way in the first 
> place, I don't remember, but all the same, it appears wrong).  All the 
> tricks with variables_order/gpc_order were there to allow people to work 
> around problems with register_globals.  Linking them with the auto globals 
> doesn't make any sense to me, and is the source of the wtf factor here to 
> begin with.
> 
> The only reason one may want not to populate the auto-globals is 
> performance.  I think that the cases where you would really like to disable 
> one of those are rare.  I think that our best bet is to always populate the 
> auto globals, regardless of variables_order, and possibly provide means to 
> explicitly turn them off for performance reasons.

But the means to turn them off is variables_order.  Being able to disable 
populating E and S can give a decent performance boost and for the most 
part you never need these.  Having register_argc_argv being dependant on 
the variables_order setting is very confusing.  If you specifically say 
you want to register argc/argv, then that is what should happen.

-Rasmus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] argv and argc on cliphp

[Rasmus Lerdorf]

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 Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PHP 5 foreach iterators for COM

[Wez Furlong]

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 is
most likely Variant, but could be anything.

It then repeatedly calls $iterator->Next() to fetch the next item.

When done, it releases the $iterator.

I know Marcus implemented iterators for spl, but the concept
there is that the $container itself needs to implement spl interfaces.
The just doesn't fit with the way COM stuff works, and pollutes
the COM object with magic (some COM objects want to handle
method and property accesses by magic themselves).

Can we have a extra handler in the object handlers struct that
returns an object that implements an engine-supported iterator?

--Wez.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)

[Stefan Walk]

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?
> 
> Because it's plain wrong? Array functions should not cast any scalar to 
> an array, not even array_splace IMO because a scalar is NOT a non-scalar 
> as an array or object.

The same argument works for numbers and strings, imo. They aren't the
same, but there are rules for converting them. Same with Arrays and
non-arrays.

http://de2.php.net/manual/en/language.types.array.php#language.types.array.casting

What is a problem with being able to merge a single element into an
array without having to create an array around it explicitely? What is
wrong with versatility?


> > Btw, this `very, VERY minor change' broke pear.
> 
> That has nothing to do with this change, just by a bad design choice.

If a change breaks something in the distribution, i wouldn't call it
minor, no matter what circumstances...

> Once more the description in the manual:
> 
>   array_merge() merges the elements of two or more arrays together
>   so that the values of one are appended to the end of the
>   previous one. It returns the resulting array.

I know the description. What does it tell me? String functions tell that
they work on strings, but they accept numbers nonetheless.

This fix does nothing but make PHP more inconsistent.

-- 
Regards,
Stefan Walk
<[EMAIL PROTECTED]>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] help request: php array

[netcat]

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 fault :-)
 

It's 99.9%. The question should be rephrased:
I work wrong with PHP code or
I work wrong with REP code ?
Thanks a lot.

--Wez.

 

Backtrace in `fatal_signal_handler':
   <(null)+1107463240>
   
   
   
   
   
   
   
Lisp backtrace:

Segmentation fault
---8<---
Is that rep's or php's problem?
May be t should be duplicated?
If yes, how?
   

 



--
NetCat


---
FREE 10MB Email + AntiSpam + POP3 + more.
Get it at http://www.doal.co.il:81/free/?c=antispam
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)

[Derick Rethans]

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 say so) just "fixes" this.
> > 
> > RTFM. :)
> > 
> > --Jani
> 
> Do you want me to fix the str* functions, since it seems those are
> accepting numbers?

Trying being sarcastic? Tip: it doesn't work on a mailinglist to reach 
some goal.

> 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?

Because it's plain wrong? Array functions should not cast any scalar to 
an array, not even array_splace IMO because a scalar is NOT a non-scalar 
as an array or object.

> Btw, this `very, VERY minor change' broke pear.

That has nothing to do with this change, just by a bad design choice.
Once more the description in the manual:

array_merge() merges the elements of two or more arrays together
so that the values of one are appended to the end of the
previous one. It returns the resulting array.

regards,
Derick

-- 
"Interpreting what the GPL actually means is a job best left to those
that read the future by examining animal entrails."
-
 Derick Rethans http://derickrethans.nl/ 
 International PHP Magazine  http://php-mag.net/
-

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] help request: php array

[Wez Furlong]

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>
> 
> 
> 
> 
> 
> 
> 
>  
> Lisp backtrace:
>  
> Segmentation fault
> ---8<---
> 
> Is that rep's or php's problem?
> May be t should be duplicated?
> If yes, how?

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] help request: php array

[netcat]

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); /* equivalent to $ret[] = $tmp
*/
  }
}
 

   if(rep_CONSP(in)) {
   zval php_array;
   //zend_hash_init(&php_array,100,
   repv i,t;
   for(i=in;i!=Qnil;i=rep_CDR(i)) {
   printf("REP FWD to next element\n");
   rep_data_converter(rep_CAR(i),&t);
   /* ??? add t to array php_array */
   }
   }
   



 

I guess it almost works :

   if(rep_CONSP(in)) {
   repv i;
   for(i=in;i!=Qnil;i=rep_CDR(i)) {
   zval *t;
   MAKE_STD_ZVAL(t);
   printf("REP FWD to next element PT1\n");
   rep_data_converter(rep_CAR(i),t);
   printf("REP FWD to next element PT2\n");
   add_next_index_zval(return_value, t);
   printf("REP FWD to next element PT3\n");
   /* ??? add t to array() */
   }
   }
---8<--- 
 

REP FWD to next element PT1
REP FWD to next element PT2
rep: received fatal signal: Segmentation fault
struct debug_buf common:

Backtrace in `fatal_signal_handler':
   <(null)+1107463240>
   
   
   
   
   
   
   
Lisp backtrace:

Segmentation fault
---8<---
Is that rep's or php's problem?
May be t should be duplicated?
If yes, how?
--
NetCat


--
SPAM-Free 10mb Free email + Antivirus + POP3 + more...
Get it at http://www.doal.co.il:81/free/?c=all-spam
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] help request: php array

[Wez Furlong]

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 to $ret[] = $tmp
*/
   }
}


> if(rep_CONSP(in)) {
> zval php_array;
> //zend_hash_init(&php_array,100,
> repv i,t;
> for(i=in;i!=Qnil;i=rep_CDR(i)) {
> printf("REP FWD to next element\n");
> rep_data_converter(rep_CAR(i),&t);
> /* ??? add t to array php_array */
> }
> }

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] help request: passing return value

[netcat]

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(zval *return_value, ...)
{
   ... change the return_value here ...
  return SUCCESS;
}
PHP_FUNCTION(my_func)
{
   if (f1(return_value) == SUCCESS) {
   /* it worked */
   return;
   } else {
   /* it didn't work */
   php_error()
   }
}
 

Thanks a lot, it seems to work.

Also take a look in Zend/zend.h at the definitions for
INTERNAL_FUNCTION_PARAMETERS and
INTERNAL_FUNCTION_PARAM_PASSTHRU
 

I will. Thanks again.

which can be used in you own function declarations to handle
the php function paramters.
Hope that helps,

--Wez.

PS: You're welcome to join the PHP Extension Community Library,
or PECL, on [EMAIL PROTECTED]
- Original Message - 
From: "netcat" <[EMAIL PROTECTED]>
To: "PHP Development" <[EMAIL PROTECTED]>
Sent: Tuesday, October 07, 2003 9:43 AM
Subject: [PHP-DEV] help request: passing return value

 

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 on some_args here */
 ...
 ...
 /* here i need to return what
 f1(some_args) returns */
}
What's the best way to pass the result ?
Any macro that would ?
[tried]
To look at another modules.

Make f1 be (zval *) and
"*return_value=*rep_data_converter(result);"
in f2.
Since zval is not very simple structure - it doesn't work.
   

 



--
NetCat


--
SPAM-Free 10mb Free email + Antivirus + POP3 + more...
Get it at http://www.doal.co.il:81/free/?c=all-spam
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)

[Stefan Walk]

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. :)
> 
> --Jani

Do you want me to fix the str* functions, since it seems those are
accepting numbers?

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?

Btw, this `very, VERY minor change' broke pear.

-- 
Regards,
Stefan Walk
<[EMAIL PROTECTED]>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] help request: php array

[netcat]

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.
It's time to ad an array and hash.
The question is near "???".
(and another one - how this would look like for
adding hash elements (excluding the rep_XXX stuff of course))
int rep_data_converter(repv in,zval *return_value) {
   if(rep_STRINGP(in)) {
   //printf("REP Will return string\n");
   RETVAL_STRING (rep_STR(in),1);
   return 1;
   }
   if(rep_INTP(in)) {
   RETURN_LONG (rep_INT(in));
   return 1;
   }
   if(rep_LONG_INTP(in)) {
   RETURN_LONG (rep_LONG_INT(in));
   return 1;
   }
   // hadle array
   if(rep_CONSP(in)) {
   zval php_array;
   //zend_hash_init(&php_array,100,
   repv i,t;
   for(i=in;i!=Qnil;i=rep_CDR(i)) {
   printf("REP FWD to next element\n");
   rep_data_converter(rep_CAR(i),&t);
   /* ??? add t to array php_array */
   }
   }
   

   RETVAL_STRING("REP: Unsupported type yet\n",1);
   return 0;
}
Thanks in advance.

--
NetCat


--
FREE 10MB Email + Antivirus + POP3 + more...
Get it at http://www.doal.co.il:81/free/?c=antivirus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] help request: passing return value

[Wez Furlong]

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, ...)
{
... change the return_value here ...
   return SUCCESS;
}

PHP_FUNCTION(my_func)
{
if (f1(return_value) == SUCCESS) {
/* it worked */
return;
} else {
/* it didn't work */
php_error()
}
}

Also take a look in Zend/zend.h at the definitions for
INTERNAL_FUNCTION_PARAMETERS and
INTERNAL_FUNCTION_PARAM_PASSTHRU
which can be used in you own function declarations to handle
the php function paramters.

Hope that helps,

--Wez.

PS: You're welcome to join the PHP Extension Community Library,
or PECL, on [EMAIL PROTECTED]

- Original Message - 
From: "netcat" <[EMAIL PROTECTED]>
To: "PHP Development" <[EMAIL PROTECTED]>
Sent: Tuesday, October 07, 2003 9:43 AM
Subject: [PHP-DEV] help request: passing return value


> 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 on some_args here */
>   ...
>   ...
>   /* here i need to return what
>   f1(some_args) returns */
> }
> 
> What's the best way to pass the result ?
> Any macro that would ?
> [tried]
> 
> To look at another modules.
> 
> Make f1 be (zval *) and
> "*return_value=*rep_data_converter(result);"
> in f2.
> Since zval is not very simple structure - it doesn't work.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)

[Jan Schneider]

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 example don't throw anything
at all if you pass them a NULL. So we're inconsistent no matter what we do,
it's a bogus argument.

The point is that the behaviour changes in a minor release an that is A Bad
Thing IMO. I'm selfish admittedly, but Horde's default configuration is to
report E_ALL and we are indeed writing E_NOTICE-safe code. In the end we
will be flooded with complaints on error messages from code that worked
flawlessly for months or even years and still does, just because people
upgraded to a *bug fix* PHP release.

I'm fine with this notice to be added to the PHP_4 and HEAD branch, but
PHP_4_3 is the wrong place.

> Jan Schneider wrote:
>
> > 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 being passed to that
> function.
> > And we don't throw E_NOTICEs if using NULLs with any type specific
> > function AFAIK.

Jan.

--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] CVS Account Request: tarjei

[Alan Knowles]

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 unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] argv and argc on cliphp

[Zeev Suraski]

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 variables_order
> setting.
>
> This has the double-edged effect of making it a standard to always use
> $_SERVER['argv'] for cli, and to discourage people from removing S from
> variables_order and using $_SERVER as their own variable name for something
> else.
>
> Making globals $argv and $argc always created is just cluttering the
> namespace even more, and (I think) breaks the idea of always putting
> variables into the superglobal $_* arrays.

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 normal
$_SERVER variables available?  The wtf factor is a little too high for my
tastes.
I think that making $_SERVER dependant on the settings of variables_order 
was wrong to begin with (I may have caused it to be that way in the first 
place, I don't remember, but all the same, it appears wrong).  All the 
tricks with variables_order/gpc_order were there to allow people to work 
around problems with register_globals.  Linking them with the auto globals 
doesn't make any sense to me, and is the source of the wtf factor here to 
begin with.

The only reason one may want not to populate the auto-globals is 
performance.  I think that the cases where you would really like to disable 
one of those are rare.  I think that our best bet is to always populate the 
auto globals, regardless of variables_order, and possibly provide means to 
explicitly turn them off for performance reasons.

Zeev

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] help request: passing return value

[netcat]

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 on some_args here */
 ...
 ...
 /* here i need to return what
 f1(some_args) returns */
}
What's the best way to pass the result ?
Any macro that would ?
[tried]
To look at another modules.

Make f1 be (zval *) and
"*return_value=*rep_data_converter(result);"
in f2.
Since zval is not very simple structure - it doesn't work.
P.S.
 Posting this message to php.internals seems to fail.
--
NetCat
---
FREE 10MB Email + AntiSpam + POP3 + more.
Get it at http://www.doal.co.il:81/free/?c=antispam
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] argv and argc on cliphp

[Stanislav Malyshev]

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 was to 
RL>> always make argc and argv available in the CLI version regardless of the 
RL>> variables_order setting.  As in, the CLI version will now always populate 
RL>> the global $argc and $argv variables. 

What I see just now is that argc/argv is never getting into the _SERVER. 
No wonder, since the code in php_variables.c looks like:

if (PG(register_globals) || SG(request_info).argc) {
/* register argc/argv into EG(symbol_table) */
} else if (!SG(request_info).argc) {
/* register argc/argv into track_vars_array */
}

Either I am missing something or this code is meaningless - why should 
track_vars_array be populated only when argc equals to 0? Maybe non-zero 
argc was the intent?

-- 
Stanislav Malyshev, Zend Products Engineer   
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.109

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] CVS Account Request: tarjei

[Tarjei Huse]

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

Re: [PHP-DEV] argv and argc on cliphp

[Jani Taskinen]

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 status, it should ALWAYS create
>> > > $_SERVER['argv'] and $_SERVER['argc'], regardless of variables_order
>> > > setting.
>> >
>> > 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 normal
>> > $_SERVER variables available?  The wtf factor is a little too high for my
>> > tastes.
>> 
>> Hmm. I think that's my problem with the $argv/$argc method too. If
>> register_globals is off, why are globals getting created? If nothing else,
>> $_SERVER is one variable, $argv and $argc are two.
>
>I think you have the wrong idea of what register_globals means.  Turning 
>off register_globals does not mean that your global symbol table will 
>suddenly be empty.  There are plenty of variables registered in the global 
>symbol table.  register_globals guides whether user-defined variables are 
>allowed to be created in the global symbol table.  Having $argc/$argv in 
>the global symbol table has nothing to do with register_globals.  These 
>variables are not named by the user.  It also provides a nice symmetry 
>with other languages that make argc/argv available this way.
>
>> Maybe this situation (where register_globals = off, and variables_order
>> doesn't contain 'S') should just generate a warning (though I'm not sure
>> where, in this context. Are there any other warnings at startup?)?
>
>Why?  This is a perfectly valid config.
>
>> Another option would be to introduce a new superglobal, $_ARGV, only for
>> cli. IMO, argc is a bit antiquated anyways, as you can always use count(),
>> or even just foreach to go through. What may be an issue with this is that
>> $_ARGV would be a numerically-indexed array of the options, whereas the rest
>> of the superglobals are indexed by strings and all have meanings. It's also
>> a bit of a big change, and would mean that code written for this version
>> wouldn't be backwards-compatible. I'm not sure what the opinions of most
>> people are about making these sorts of changes.. maybe this is something
>> that could be introduced in PHP5?
>
>I guess you could argue that this is slightly cleaner, but the fact that 
>it isn't backwards compatible makes the hassle factor too high for such a 
>marginal cleanliness gain.
>
>-Rasmus
>
>

-- 
https://www.paypal.com/xclick/[EMAIL PROTECTED]&no_note=1&tax=0¤cy_code=EUR
 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Segfault with PHP and bison 1.875(a)

[Sebastian Bergmann]

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://sebastian-bergmann.de/   http://phpOpenTracker.de/

Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Segfault with PHP and bison 1.875(a)

[Paul Eggert]

"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 recall those responses.  I don't see what Bison
skeleton files have to do with this issue, nor do I recall the Bison
team saying they didn't care about it.  At any rate, I hope we've
gotten to the bottom of the problem now that PHP bug#25770 has been
filed.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Segfault with PHP and bison 1.875(a)

[Paul Eggert]

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 the behavior is undefined in this case.
See ,
section "Lexical Structure of the Grammar", which says "The
application shall ensure that the NUL character is not used in grammar
rules or literals."  This prohibits grammars from using '\0' tokens.

I suspect that earlier versions of Bison silently ignored any grammar
rules containing '\0' tokens, but newer versions cause them to make
the generated parser dump core.  Both behaviors conform to POSIX, but
obviously it'd be better if Bison issued a diagnostic when it sees
such tokens.  I'll install a fix to Bison to do that.

Here is a patch to PHP to fix the PHP bug.  This patch is relative to
php5, but the bug is php4 as well.  I've submitted this patch to
bugs.php.net (it's PHP bug #25770).

2003-10-06  Paul Eggert  <[EMAIL PROTECTED]>

* Zend/zend_ini_parser.y:
  This fixes PHP bugs #25770 and #21159.

Index: Zend/zend_ini_parser.y
===
RCS file: /repository/ZendEngine2/zend_ini_parser.y,v
retrieving revision 1.24
diff -p -u -r1.24 zend_ini_parser.y
--- Zend/zend_ini_parser.y  10 Jun 2003 20:03:25 -  1.24
+++ Zend/zend_ini_parser.y  7 Oct 2003 06:55:36 -
@@ -213,7 +213,6 @@ string_or_value:
|   CFG_TRUE { $$ = $1; }
|   CFG_FALSE { $$ = $1; }
|   '\n' { $$.value.str.val = strdup(""); $$.value.str.len=0; $$.type = 
IS_STRING; }
-   |   '\0' { $$.value.str.val = strdup(""); $$.value.str.len=0; $$.type = 
IS_STRING; }
 ;
 
 expr:

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php