Re: [PHP-DEV] Extending DB2 odbc support

[Frank M. Kromann]

Hi,

To my knowledge IBM uses a Client Level Interface CLI and the
specifications for CLI is exactly the same as ODBC. Compiling the ODBC
extension with CLI and some other form of ODBC library would make sence if
you wanted to use native IBM code and other ODBC at the same time. This
was the case in PHP3 where the ODBC functions was renamed to db2_* when
compiling with CLI (using shared objects or dll's made it possible to use
both at the same time).

I don't see a need to add specific db2 functions, but perhaps extend the
ODBC extension with generic ODBC/CLI functions.

- Frank
> 
> On Friday, November 8, 2002, at 08:34 PM, tim wrote:
> >
> > If I take the existing php odbc code and add the ibm-db2 specific
> > extensions, what are the chances of this making it into the main php
> > distribution as a new extension ( ext/ibmdb2 ) ? Is it a good idea to
> > maintain a separate cvs tree on sf.net so it gets some testing first?
> 
> I cannot comment directly on the creation of ext/ibmdb2, although I'd 
> rather see something like that moved to PECL (where everything will be 
> eventually).  As for separate CVS trees, while it sounds like a good 
> idea, it's my opinion that it's not a good thing.
> 
> If you can detail/outline the changes you want to make a bit more it 
> might help in the discussion.  Right now there is another user 
> extending ODBC to better support IBM DB2 systems.
> 
> > I am looking to create something similar to oracle's php extension.
> 
> What would be the advantages of doing this?  What sort of extra 
> functionality is there that implementing such a system will provide to 
> DB2 systems?  I'm just trying to get a feel for what you're reasonings,

> and level of implementation will be.
> 
>  >---<
> Dan Kalowsky"A little less conversation,
> http://www.deadmime.org/~danka little more action."
> [EMAIL PROTECTED]- "A Little Less Conversation",
> [EMAIL PROTECTED]Elvis Presley
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 




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

Re: [PHP-DEV] Extending DB2 odbc support

[Dan Kalowsky]

On Friday, November 8, 2002, at 08:34 PM, tim wrote:


If I take the existing php odbc code and add the ibm-db2 specific
extensions, what are the chances of this making it into the main php
distribution as a new extension ( ext/ibmdb2 ) ? Is it a good idea to
maintain a separate cvs tree on sf.net so it gets some testing first?


I cannot comment directly on the creation of ext/ibmdb2, although I'd 
rather see something like that moved to PECL (where everything will be 
eventually).  As for separate CVS trees, while it sounds like a good 
idea, it's my opinion that it's not a good thing.

If you can detail/outline the changes you want to make a bit more it 
might help in the discussion.  Right now there is another user 
extending ODBC to better support IBM DB2 systems.

I am looking to create something similar to oracle's php extension.


What would be the advantages of doing this?  What sort of extra 
functionality is there that implementing such a system will provide to 
DB2 systems?  I'm just trying to get a feel for what you're reasonings, 
and level of implementation will be.

>---<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


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

[PHP-DEV] Return -1

[Maxim Maletsky]

Guys,

I have just fixed a few doc files where it was stating that a function
returned -1 but the sources had clear RETURN_FALSE.

Done that, I took some time to grep my phpdoc and php4 trees for -1
returns and, surprisingly, I found out that there were a few suspicious places
where -1 could be better changed to RETURN_FALSE.

Some of such places were FTP, pgSQL, LDAP functions.  Maybe a dozen or
less in total.

I don't think this should be done right now, as we would directly break
the backwards compatibility. But, shouldn't we be considering such
consistency changes for PHP5 releases?

My point is that functions behaviour consistency can be very important
for many users, and breaking just a few lines of PHP4 code since first
PHP5 releases would probably be a small price to pay.

What do you all think? Am I saying something strategically logical or
this is only my own paranoia?

-- 
Maxim Maletsky
[EMAIL PROTECTED]


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

Re: [PHP-DEV] mbstring and 4.3.0

[Rui Hirokawa]

I completely agree with Wez.
mbstring has very foundamental functionalities for multibyte users.
Multibyte users can 'not' build any useful application without mbstring.
We must understand there are so many users who are using multibyte
character encoding. 
multibyte string functions for multibyte users has nealy same meaning
with string functions for singlebyte users.
If PHP lacks string functions, who can use PHP ?

I think mbstring enabled by default in PHP 4.3 is very good decision.

'function overloading' in mbstring is to make easier multibyte-aware
application, but, it is disabled by default.
I also agree with Wez, the official zend API for function overloading 
is needed. I will change the implemantaion if some official API 
is available.

Rui

On Fri,  8 Nov 2002 10:13:29 +
[EMAIL PROTECTED] (Wez Furlong) wrote:

> I see the known-good codeset conversion implementation as a *very* good
> reason to have mbstring enabled by default.
> (Just look at all the problems with iconv and recode on different systems
> out there).
> 
> I agree that the magic features for lazy programmers (function overloading
> and transparent encoding) are slightly worrying, but they are disabled
> by default, and as I have said - I don't use those, but I do use the
> conversion functions and *that* configuration works just fine.
> 
> The conversion functions are something that really should be there by
> default, as it allows people to write portable globalized scripts.
> Remember that a large majority of users are vhosted and have not control
> over the build of PHP.  By not providing a reliable and portable
> codeset conversion API, we are holding back "the masses" from writing
> (and distributing) "killer apps" in PHP.
> 
> Yes, I can enable mbstring at configure time, and yes, the CJK people
> can do likewise, but what about the rest of the world running from vhosts
> when they want to use unicode, quoted-printable, uu-encoding,  favourite encoding here> encodings which are also supported by mbstring?
> 
> We took the decision to enable it by default; let's not be short-sighted
> and disable it primarily out of ignorance (no offence intended).
> 
> I've yet to see someone comment on my suggestions for a practical solution
> that would shut up both myself and the people advocating disabling it.
> 
> --Wez.

-- 
-
Rui Hirokawa <[EMAIL PROTECTED]>
 <[EMAIL PROTECTED]>

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

Re: [PHP-DEV] Extending DB2 odbc support

[tim]

On Fri, 8 Nov 2002 08:18:06 -0500
Dan Kalowsky <[EMAIL PROTECTED]> wrote:

> I've been maintaining the ODBC extension for a bit.  While I welcome 
> the addition of new ODBC functionality, I am hesitent to add in 
> functions that are not ODBC compliant to the code (i.e. db2_connect(),
> 
> or some such).
> 
> If you can make the functions generic enough that they can be executed
> 
> through ODBC, then feel free to submit the patches to the list and 
> myself to get them included in.

If I take the existing php odbc code and add the ibm-db2 specific
extensions, what are the chances of this making it into the main php
distribution as a new extension ( ext/ibmdb2 ) ? Is it a good idea to
maintain a separate cvs tree on sf.net so it gets some testing first?

I am looking to create something similar to oracle's php extension.

Thanks,
Tim

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

[PHP-DEV] Re: [PHP] Do I need the closing ?> tag

[Ernest E Vogelsinger]

At 23:24 08.11.2002, David McArthur said:
[snip]
>PHP 4.2.2 (linux) doesn't seem to mind if I leave off the closing ?> tag at
>the end of a file.  Is the ?> assumed at EOF?
>
>I have PHP that outputs binary and along the way I include() a lot of php
>scripts.  I'm constantly having problems when I leave a little whitespace at
>the end of some script after the ?> which screws up the output binary.
>First time this happened it took me hours to figure out the cause.
>
>What does everyone think about just leaving off the ?> as a solution to
>this?  It works for me now, but would any PHP developer care to
>prognosticate on the liklihood this might change in future?
[snip] 

The least I can say that it's bad style... it's not documented, and
therefore any tag should be closed.

Most ascii editors can be configured to discard trailing whitespaces; and
PHP will even ignore a newline character following immediately a closing tag:

--[html]-
Outside
Outside
--[html]-
will correctly produce this:
OutsideInsideOutside

-- 
   >O Ernest E. Vogelsinger
   (\)ICQ #13394035
^ http://www.vogelsinger.at/



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

Re: [PHP-DEV] Do I need the closing ?> tag

[Sterling Hughes]

> PHP 4.2.2 (linux) doesn't seem to mind if I leave off the closing ?> tag at
> the end of a file.  Is the ?> assumed at EOF?
> 
> I have PHP that outputs binary and along the way I include() a lot of php
> scripts.  I'm constantly having problems when I leave a little whitespace at
> the end of some script after the ?> which screws up the output binary.
> First time this happened it took me hours to figure out the cause.
> 
> What does everyone think about just leaving off the ?> as a solution to
> this?  It works for me now, but would any PHP developer care to
> prognosticate on the liklihood this might change in future?
> 

I definitely think that _you_ should do it.

But this is not the proper place for these questions, ask them on
[EMAIL PROTECTED]

?> Sterling


-- 
Sterling Hughes <[EMAIL PROTECTED]>
Did I help you? Consider a gift: http://wishlist.edwardbear.org/

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

[PHP-DEV] Do I need the closing ?> tag

[David McArthur]

PHP 4.2.2 (linux) doesn't seem to mind if I leave off the closing ?> tag at
the end of a file.  Is the ?> assumed at EOF?

I have PHP that outputs binary and along the way I include() a lot of php
scripts.  I'm constantly having problems when I leave a little whitespace at
the end of some script after the ?> which screws up the output binary.
First time this happened it took me hours to figure out the cause.

What does everyone think about just leaving off the ?> as a solution to
this?  It works for me now, but would any PHP developer care to
prognosticate on the liklihood this might change in future?




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

Re: [PHP-DEV] turning strlen() into an opcode

[Sterling Hughes]

> On Fri, Nov 08, 2002 at 04:17:43PM -0500, Andrei Zmievski wrote:
> 
> > I've made a small patch that turns strlen() into a statement executed by
> > the engine instead of a function. The reasoning is that something that
> > integral should probably be in the engine. I haven't done hard
> > benchmarking but it seems to improve performance of that particular
> > piece of code by about 25%. Feedback is welcome.
>  
> I'd be more interested in seeing a more generic len() function (a la
> Python) that would return the length of the variable passed to it (the
> number of characters in a string, then number of elements in an
> array).  Actually, I suppose extending count() to handle strings would
> be mostly equivalent.
>

ughh, no more syntatic sugar, php is sweet enough how it is :)

-Sterling


> -- 
> Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/)
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

-- 
Sterling Hughes <[EMAIL PROTECTED]>
Did I help you? Consider a gift: http://wishlist.edwardbear.org/

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

Re: [PHP-DEV] bison error [was: PHP 4.3.0]

[Rasmus Lerdorf]

I'm not seeing any problems with bison-1.75 here.

On Fri, 8 Nov 2002, Dave Viner wrote:

> here's the message i posted to [EMAIL PROTECTED] for more help in the bison
> problem.
>
> http://www.geocrawler.com/lists/3/GNU/350/0/10107563/
>
> I'm not good enough with bison to understand why it produces no error
> message and yet does not produce a .c file.
>
> even reducing the bison command to its simplest form:
> Administrator@DVINER-LAP /cygdrive/d/php/php4/Zend
> $ bison zend_language_parser.y
>
> Administrator@DVINER-LAP /cygdrive/d/php/php4/Zend
> $ ls -l zend_language_parser*
> -rwxr-xr-x1 Administ None33095 Nov  6 09:56
> zend_language_parser.y
>
> Administrator@DVINER-LAP /cygdrive/d/php/php4/Zend
> $ bison zend_ini_parser.y
> zend_ini_parser.y:215.4-6: unrecognized escape: `\\0'
>
> Administrator@DVINER-LAP /cygdrive/d/php/php4/Zend
> $ ls -l zend_ini_parser*
> -rwxr-xr-x1 Administ None 6336 Nov  6 09:56 zend_ini_parser.y
>
> Administrator@DVINER-LAP /cygdrive/d/php/php4/Zend
> $
>
> Still fails.  The zend_ini_parser produces a warning or error at least.
> zend_ini_parser.y:215.4-6: unrecognized escape: `\\0'
> But I'm not good enough with bison to know how to fix it !
>
> dave
>
>
> -Original Message-
> From: Andi Gutmans [mailto:andi@;zend.com]
> Sent: Friday, November 08, 2002 2:34 PM
> To: [EMAIL PROTECTED]
> Subject: [PHP-DEV] PHP 4.3.0
>
>
> Hey,
>
> What's the schedule for 4.3? It seems to be lingering. That said I'd like
> to resolve the bison issue before we release it (i.e. make sure that ZE1
> isn't bitten by versions > 1.28).
>
> Andi
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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

[PHP-DEV] bison error [was: PHP 4.3.0]

[Dave Viner]

here's the message i posted to [EMAIL PROTECTED] for more help in the bison
problem.

http://www.geocrawler.com/lists/3/GNU/350/0/10107563/

I'm not good enough with bison to understand why it produces no error
message and yet does not produce a .c file.

even reducing the bison command to its simplest form:
Administrator@DVINER-LAP /cygdrive/d/php/php4/Zend
$ bison zend_language_parser.y

Administrator@DVINER-LAP /cygdrive/d/php/php4/Zend
$ ls -l zend_language_parser*
-rwxr-xr-x1 Administ None33095 Nov  6 09:56
zend_language_parser.y

Administrator@DVINER-LAP /cygdrive/d/php/php4/Zend
$ bison zend_ini_parser.y
zend_ini_parser.y:215.4-6: unrecognized escape: `\\0'

Administrator@DVINER-LAP /cygdrive/d/php/php4/Zend
$ ls -l zend_ini_parser*
-rwxr-xr-x1 Administ None 6336 Nov  6 09:56 zend_ini_parser.y

Administrator@DVINER-LAP /cygdrive/d/php/php4/Zend
$

Still fails.  The zend_ini_parser produces a warning or error at least.
zend_ini_parser.y:215.4-6: unrecognized escape: `\\0'
But I'm not good enough with bison to know how to fix it !

dave


-Original Message-
From: Andi Gutmans [mailto:andi@;zend.com]
Sent: Friday, November 08, 2002 2:34 PM
To: [EMAIL PROTECTED]
Subject: [PHP-DEV] PHP 4.3.0


Hey,

What's the schedule for 4.3? It seems to be lingering. That said I'd like
to resolve the bison issue before we release it (i.e. make sure that ZE1
isn't bitten by versions > 1.28).

Andi


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



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

Re: [PHP-DEV] PHP 4.3.0

[Andrei Zmievski]

On Sat, 09 Nov 2002, Andi Gutmans wrote:
> Hey,
> 
> What's the schedule for 4.3? It seems to be lingering. That said I'd like 
> to resolve the bison issue before we release it (i.e. make sure that ZE1 
> isn't bitten by versions > 1.28).

It's not lingering. We just have to be more careful since it's such a
large release. I will make RC1 this weekend.

-Andrei   http://www.gravitonic.com/

"It's an emergent property of connected human minds that
they create things for one another's pleasure and to conquer
their uneasy sense of being too alone." -- Eben Moglen

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

Re: [PHP-DEV] turning strlen() into an opcode

[Jon Parise]

On Fri, Nov 08, 2002 at 04:17:43PM -0500, Andrei Zmievski wrote:

> I've made a small patch that turns strlen() into a statement executed by
> the engine instead of a function. The reasoning is that something that
> integral should probably be in the engine. I haven't done hard
> benchmarking but it seems to improve performance of that particular
> piece of code by about 25%. Feedback is welcome.
 
I'd be more interested in seeing a more generic len() function (a la
Python) that would return the length of the variable passed to it (the
number of characters in a string, then number of elements in an
array).  Actually, I suppose extending count() to handle strings would
be mostly equivalent.

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

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

Re: [PHP-DEV] [PATCH] Fix for bug #19566

[Moriyoshi Koizumi]

var_args issue doesn't have much to do with the purpose of the patch. We 
were perhaps just curious about the usage of va_start() and va_end().
And that warning reducer was later added by Marcus, so the first version 
should look nice. What about it?

Moriyoshi

Andi Gutmans <[EMAIL PROTECTED]> wrote:

> I haven't followed the thread. What is the problem with the var_args()?
> Also, please don't commit the second part of the patch. The warning is due 
> to the compiler not understanding the code well enough. Functionality wise 
> there's no reason to NULL that variable. Live with the warning or upgrade 
> to a better compiler.
> 
> Andi
> 
> At 07:25 PM 11/8/2002 +0100, Derick Rethans wrote:
> >On Fri, 8 Nov 2002, Marcus Börger wrote:
> >
> > > Moriyoshi  could you make a *.phpt file from the bug?
> > >
> > > Attached is a new diff tested already. It also fixes a compiler warning.
> > > Since i do not have Zend karma someone with karma should commit it
> > > or give me karma.
> >
> >I can commit this, after you fix the whitespace :)
> >
> >Derick
> >
> > > cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend\)
> > > Index: zend_hash.c
> > > ===
> > > RCS file: /repository/ZendEngine2/zend_hash.c,v
> > > retrieving revision 1.93
> > > diff -u -r1.93 zend_hash.c
> > > --- zend_hash.c 5 Nov 2002 18:22:02 -   1.93
> > > +++ zend_hash.c 8 Nov 2002 17:25:59 -
> > > @@ -722,9 +722,9 @@
> > >
> > >  HASH_PROTECT_RECURSION(ht);
> > >
> > > -   va_start(args, num_args);
> > >  p = ht->pListHead;
> > >  while (p != NULL) {
> > > +   va_start(args, num_args);
> > >  hash_key.arKey = p->arKey;
> > >  hash_key.nKeyLength = p->nKeyLength;
> > >  hash_key.h = p->h;
> > > @@ -733,8 +733,8 @@
> > >  } else {
> > >  p = p->pListNext;
> > >  }
> > > +   va_end(args);
> > >  }
> > > -   va_end(args);
> > >
> > >  HASH_UNPROTECT_RECURSION(ht);
> > >   }
> > > @@ -1163,7 +1163,7 @@
> > >
> > >   ZEND_API int zend_hash_compare(HashTable *ht1, HashTable *ht2,
> > > compare_func_t compar, zend_bool ordered TSRMLS_DC)
> > >   {
> > > -   Bucket *p1, *p2;
> > > +   Bucket *p1, *p2 = NULL /* fixes warning */;
> > >  int result;
> > >  void *pData2;
> > >
> > >
> > >
> > > At 16:45 08.11.2002, Moriyoshi Koizumi wrote:
> > > >Yep, the spec goes right. a corresponding va_end() dtor should be applied
> > > >to ap once ap has been initialized by a va_start().
> > > >IMO no va_end() is needed without a preceding va_start(), and it doesn't
> > > >matter if ap is used between va_start() and va_end().
> > > >
> > > >BTW, could anyone commit this patch if there seems no problem?
> > > >
> > > >Moriyoshi
> > > >
> > > >[EMAIL PROTECTED] (Marcus Börger) wrote:
> > > >
> > > > > Some comments on ISO9899 standard
> > > > > 7.15.1.3-2 Read between the lines: without va_end the behaviour is
> > > > undefined.
> > > > >   What ever that means i guess you have to call va_end and that 
> > requires
> > > > > va_start.
> > > > >
> > > > > 7.15.1.4-3 Says do not call va_start twice without va_end.
> > > > >
> > > > > marcus
> > > > >
> > > > >
> > > > > ISO/IEC 9899:1999 (E) ©ISO/IEC
> > > > >
> > > > > 7.15.1.3 The va_end macro
> > > > > Synopsis
> > > > > 1 #include 
> > > > > void va_end(va_list ap);
> > > > > Description
> > > > > 2 The va_end macro facilitates a normal return from the function whose
> > > > variable
> > > > > argument list was referred to by the expansion of va_start, or the
> > > > function
> > > > > containing
> > > > > the expansion of va_copy, that initialized the va_list ap. The va_end
> > > > macro may
> > > > > modify ap so that it is no longer usable (without an intervening
> > > > invocation
> > > > > of va_start
> > > > > or va_copy). If there is no corresponding invocation of the 
> > va_start or
> > > > va_copy
> > > > > macro, or if the va_end macro is not invoked before the return, the
> > > > behavior is
> > > > > undefined.
> > > > > Returns
> > > > > 3 The va_end macro returns no value.
> > > > >
> > > > > 7.15.1.4 The va_start macro
> > > > > Synopsis
> > > > > 1 #include 
> > > > > void va_start(va_list ap, parmN);
> > > > > Description
> > > > > 2 The va_start macro shall be invoked before any access to the unnamed
> > > > > arguments.
> > > > > 3 The va_start macro initializes ap for subsequent use by va_arg and
> > > > va_end.
> > > > > va_start (or va_copy) shall not be invoked again for the same ap 
> > without an
> > > > > intervening invocation of va_end for the same ap.
> > > > > (...)
> > > > >
> > > > >
> > > > > At 10:47 08.11.2002, Moriyoshi Koizumi wrote:
> > > > > >See http://www.opengroup.org/onlinepubs/007908799/xsh/stdarg.h.html
> > > > > >This appears to imply that va_start() can be used more than twice.
> > > > > >
> >

[PHP-DEV] Re: RfC: *_fetch_object()

[Yasuo Ohgaki]

I don't mind making pg_fetch_object() accept object (not class)
(Boptionally and initialize field values as object's properties.
(B
(BHow about other db module maintainers?
(B
(BBTW, pg_fetch_object() accepted 3rd optional parameter
(Bfor a long time. I've disabled it recently, since having
(B$obj->1, $obj->2, and so on does not make much sense.
(B(It can be accessible via. variable variable, but not
(Bdirectly) Some db modules may be needed to overload behavior
(Bdepend on parameter types.
(B
(B--
(BYasuo Ohgaki
(B
(BTimm Friebe wrote:
(B> Hi,
(B> what does everyone think about adding a second parameter to the
(B> *_fetch_object() functions (sybase_fetch_object, mysql_fetch_object, ...
(B> etc.) which allows users to define a class name which will then be used
(B> instead of "stdClass"?
(B> 
(B> E.g.:
(B>   class Article {
(B>   var $article_id, $caption, $text;
(B>   }
(B> 
(B>   $q= sybase_query('select * from article where article_id= 1');
(B>   if ($q) while ($a= sybase_fetch_object($q, 'Article')) {
(B>   var_dump($a);
(B>   }
(B>   
(B> This saves a couple of lines of code in PHP (formerly, you'd either put
(B> all of article's attributes in the constructor, made the constructor
(B> accept an associative array or assigned all of the attributes like this:
(B> 
(B>   $a= &new Article();
(B>   $a->article_id= $row['article_id'];
(B>   $a->caption= $row['caption'];
(B>   $a->text= $row['text'];
(B> 
(B> ) all of which seems ugly and looks like unnecessary overhead. Since PHP
(B> is missing a cast working on user-defined types (
(B> 
(B>   while ($o= sybase_fetch_object($q)) {
(B>   $a= (Article)$o;
(B>   }
(B> 
(B> ) there would be another suggestion to introduce a function cast:
(B> 
(B>   while ($o= sybase_fetch_object($q)) {
(B>   $a= cast($o, 'Article');
(B>   }
(B> 
(B> Though maybe the name isn't ideal and could be implemented in userland,
(B> too (
(B>   function &cast(&$var, $type) {
(B>   // [...Handle non-objects and normal types...]
(B>   // [...Handle non-existant classes w/ name $type...]
(B>   $ret= &new $type();
(B>   foreach (get_object_vars($var) as $k=> $v) {
(B>   $ret->$k= $v;
(B>   }
(B>   return $ret;
(B>   }
(B> 
(B> ) but with more performance issues than if it was built-in. Maybe it's
(B> even simpler to allow (MyType)$var syntax, but this would have to be
(B> introduced into Zend Engine.
(B> 
(B> Thoughts?
(B> 
(B
(B
(B-- 
(BPHP Development Mailing List 
(BTo unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PHP 4.3.0

[Andi Gutmans]

Hey,

What's the schedule for 4.3? It seems to be lingering. That said I'd like 
to resolve the bison issue before we release it (i.e. make sure that ZE1 
isn't bitten by versions > 1.28).

Andi


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

Re: [PHP-DEV] turning strlen() into an opcode

[Rasmus Lerdorf]

Do you think strlen() is actually called that often?  And isn't it a
relatively quick function as it is?  Just seems like you are optimizing a
function that isn't actually called that often and when it is called
having a 25% speedup on a function that takes a tiny fraction of the
overall execution time isn't going to be noticeable.

I wouldn't be against perhaps opcoding some functions, just not sure
strlen() would be my first candidate.

-Rasmus

On Fri, 8 Nov 2002, Andrei Zmievski wrote:

> I've made a small patch that turns strlen() into a statement executed by
> the engine instead of a function. The reasoning is that something that
> integral should probably be in the engine. I haven't done hard
> benchmarking but it seems to improve performance of that particular
> piece of code by about 25%. Feedback is welcome.
>
> -Andrei   http://www.gravitonic.com/
> * "UNIX, isn't that some archaic form of DOS?" - our job applicant *
>


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

Re: [PHP-DEV] turning strlen() into an opcode

[Andi Gutmans]

At 05:18 PM 11/8/2002 -0500, Andrei Zmievski wrote:

On Sat, 09 Nov 2002, Andi Gutmans wrote:
> I am very much against anything like this.
> Improving strlen()'s performance only will have a negligible performance
> impact on a real world script.
> With the same kind of argument you could probably find 10-20 functions
> which would be faster if you'd make opcodes for them. That's not really
> what you'd want to do.
> Also, the patch isn't quite the same functionality wise because strlen in
> your patch is a reserved word. This isn't my main problem though as it
> could be solved.

Just out of curiousity, what are the problems with making it a reserved
word and how could it be solved?


What if you wanted to have a constant STRLEN? It would break.
It could be solved by doing strcmp()'s during the compilation of a function 
and checking if the function name is strlen().


> If you want to really help improve performance of real-world scripts then
> try and find a way to improve performance of *all* function calls, 
i.e., of
> the extension API; and not by moving functions from the extension API into
> the core.

No big deal. This just came up at the PHP conference in Germany during a
chat with George and Thies.

I could have guessed Thies had a hand in it :)

Andi


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

Re: [PHP-DEV] [PATCH] Fix for bug #19566

[Andi Gutmans]

I haven't followed the thread. What is the problem with the var_args()?
Also, please don't commit the second part of the patch. The warning is due 
to the compiler not understanding the code well enough. Functionality wise 
there's no reason to NULL that variable. Live with the warning or upgrade 
to a better compiler.

Andi

At 07:25 PM 11/8/2002 +0100, Derick Rethans wrote:
On Fri, 8 Nov 2002, Marcus Börger wrote:

> Moriyoshi  could you make a *.phpt file from the bug?
>
> Attached is a new diff tested already. It also fixes a compiler warning.
> Since i do not have Zend karma someone with karma should commit it
> or give me karma.

I can commit this, after you fix the whitespace :)

Derick

> cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend\)
> Index: zend_hash.c
> ===
> RCS file: /repository/ZendEngine2/zend_hash.c,v
> retrieving revision 1.93
> diff -u -r1.93 zend_hash.c
> --- zend_hash.c 5 Nov 2002 18:22:02 -   1.93
> +++ zend_hash.c 8 Nov 2002 17:25:59 -
> @@ -722,9 +722,9 @@
>
>  HASH_PROTECT_RECURSION(ht);
>
> -   va_start(args, num_args);
>  p = ht->pListHead;
>  while (p != NULL) {
> +   va_start(args, num_args);
>  hash_key.arKey = p->arKey;
>  hash_key.nKeyLength = p->nKeyLength;
>  hash_key.h = p->h;
> @@ -733,8 +733,8 @@
>  } else {
>  p = p->pListNext;
>  }
> +   va_end(args);
>  }
> -   va_end(args);
>
>  HASH_UNPROTECT_RECURSION(ht);
>   }
> @@ -1163,7 +1163,7 @@
>
>   ZEND_API int zend_hash_compare(HashTable *ht1, HashTable *ht2,
> compare_func_t compar, zend_bool ordered TSRMLS_DC)
>   {
> -   Bucket *p1, *p2;
> +   Bucket *p1, *p2 = NULL /* fixes warning */;
>  int result;
>  void *pData2;
>
>
>
> At 16:45 08.11.2002, Moriyoshi Koizumi wrote:
> >Yep, the spec goes right. a corresponding va_end() dtor should be applied
> >to ap once ap has been initialized by a va_start().
> >IMO no va_end() is needed without a preceding va_start(), and it doesn't
> >matter if ap is used between va_start() and va_end().
> >
> >BTW, could anyone commit this patch if there seems no problem?
> >
> >Moriyoshi
> >
> >[EMAIL PROTECTED] (Marcus Börger) wrote:
> >
> > > Some comments on ISO9899 standard
> > > 7.15.1.3-2 Read between the lines: without va_end the behaviour is
> > undefined.
> > >   What ever that means i guess you have to call va_end and that 
requires
> > > va_start.
> > >
> > > 7.15.1.4-3 Says do not call va_start twice without va_end.
> > >
> > > marcus
> > >
> > >
> > > ISO/IEC 9899:1999 (E) ©ISO/IEC
> > >
> > > 7.15.1.3 The va_end macro
> > > Synopsis
> > > 1 #include 
> > > void va_end(va_list ap);
> > > Description
> > > 2 The va_end macro facilitates a normal return from the function whose
> > variable
> > > argument list was referred to by the expansion of va_start, or the
> > function
> > > containing
> > > the expansion of va_copy, that initialized the va_list ap. The va_end
> > macro may
> > > modify ap so that it is no longer usable (without an intervening
> > invocation
> > > of va_start
> > > or va_copy). If there is no corresponding invocation of the 
va_start or
> > va_copy
> > > macro, or if the va_end macro is not invoked before the return, the
> > behavior is
> > > undefined.
> > > Returns
> > > 3 The va_end macro returns no value.
> > >
> > > 7.15.1.4 The va_start macro
> > > Synopsis
> > > 1 #include 
> > > void va_start(va_list ap, parmN);
> > > Description
> > > 2 The va_start macro shall be invoked before any access to the unnamed
> > > arguments.
> > > 3 The va_start macro initializes ap for subsequent use by va_arg and
> > va_end.
> > > va_start (or va_copy) shall not be invoked again for the same ap 
without an
> > > intervening invocation of va_end for the same ap.
> > > (...)
> > >
> > >
> > > At 10:47 08.11.2002, Moriyoshi Koizumi wrote:
> > > >See http://www.opengroup.org/onlinepubs/007908799/xsh/stdarg.h.html
> > > >This appears to imply that va_start() can be used more than twice.
> > > >
> > > >And I don't think va_start() always has to be invoked.
> > > >
> > > >Moriyoshi
> > > >
> > > >[EMAIL PROTECTED] (Marcus Börger) wrote:
> > > >
> > > > > I am not sure if va_start can be called twice in a row (rekursive).
> > > > > Manual does not say anything about that.
> > > > >
> > > > > How about:
> > > > >
> > > > > cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend)
> > > > > Index: zend_hash.c
> > > > > ===
> > > > > RCS file: /repository/ZendEngine2/zend_hash.c,v
> > > > > retrieving revision 1.93
> > > > > diff -u -r1.93 zend_hash.c
> > > > > --- zend_hash.c 5 Nov 2002 18:22:02 -   1.93
> > > > > +++ zend_hash.c 8 Nov 2002 09:32:48 -
> > > > > @@ -722,9 +722,13 @@
> > > > >
> > > > >  HA

Re: [PHP-DEV] turning strlen() into an opcode

[Andrei Zmievski]

On Sat, 09 Nov 2002, Andi Gutmans wrote:
> I am very much against anything like this.
> Improving strlen()'s performance only will have a negligible performance 
> impact on a real world script.
> With the same kind of argument you could probably find 10-20 functions 
> which would be faster if you'd make opcodes for them. That's not really 
> what you'd want to do.
> Also, the patch isn't quite the same functionality wise because strlen in 
> your patch is a reserved word. This isn't my main problem though as it 
> could be solved.

Just out of curiousity, what are the problems with making it a reserved
word and how could it be solved?

> If you want to really help improve performance of real-world scripts then 
> try and find a way to improve performance of *all* function calls, i.e., of 
> the extension API; and not by moving functions from the extension API into 
> the core.

No big deal. This just came up at the PHP conference in Germany during a
chat with George and Thies.

-Andrei   http://www.gravitonic.com/
* If Bill Gates had a nickel for every time Windows crashed.. Oh, wait.. *

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

Re: [PHP-DEV] turning strlen() into an opcode

[Andi Gutmans]

Hi,

I am very much against anything like this.
Improving strlen()'s performance only will have a negligible performance 
impact on a real world script.
With the same kind of argument you could probably find 10-20 functions 
which would be faster if you'd make opcodes for them. That's not really 
what you'd want to do.
Also, the patch isn't quite the same functionality wise because strlen in 
your patch is a reserved word. This isn't my main problem though as it 
could be solved.
If you want to really help improve performance of real-world scripts then 
try and find a way to improve performance of *all* function calls, i.e., of 
the extension API; and not by moving functions from the extension API into 
the core.

Andi

At 04:17 PM 11/8/2002 -0500, Andrei Zmievski wrote:
I've made a small patch that turns strlen() into a statement executed by
the engine instead of a function. The reasoning is that something that
integral should probably be in the engine. I haven't done hard
benchmarking but it seems to improve performance of that particular
piece of code by about 25%. Feedback is welcome.

-Andrei   http://www.gravitonic.com/
* "UNIX, isn't that some archaic form of DOS?" - our job applicant *

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



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

[PHP-DEV] Is socket_create_pair() useful?

[Leon Atkinson]

I understand how (in C) socketpair() is useful if I can fork().  It's not
obvious what I can do with the two sockets that socket_create_pair()
creates.  What am I missing?

Thanks,
Leon

---
Leon Atkinson 


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

[PHP-DEV] Fatal error with current CVS php4/pear, inc. segfault

[Markus Fischer]

Current CVS upon installing gives me:

PHP 4.3.0-dev (cli) (built: Nov  8 2002 21:56:15)
Copyright (c) 1997-2002 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend Technologies

$ make install

Installing PHP SAPI module
Installing shared extensions: 
/home/mfischer/php4/lib/php/extensions/no-debug-non-zts-20020429/
Installing PHP CLI binary:/home/mfischer/php4/bin/
Installing PEAR environment:  /home/mfischer/php4/lib/php/
[PEAR] Archive_Tar- installed: 0.9
[PEAR] Console_Getopt - installed: 1.0
[PEAR] PEAR   - installed: 1.0b1

Fatal error: Call to undefined function:  136152012() in 
/home/mfischer/isrc/cvs/php4/pear/PEAR.php on line 641
[PEAR] DB - installed: 1.3
[PEAR] HTTP   - installed: 1.2
[PEAR] Mail   - installed: 1.0.1
[PEAR] Net_SMTP   - installed: 1.0
[PEAR] Net_Socket - installed: 1.0.1
[PEAR] XML_Parser - installed: 1.0
[PEAR] XML_RPC- installed: 1.0.4

Fatal error: Call to undefined function:  136152676() in 
/home/mfischer/isrc/cvs/php4/pear/PEAR.php on line 641
Installing build environment: /home/mfischer/php4/lib/php/build/
Installing header files:  /home/mfischer/php4/include/php/
Installing helper programs:   /home/mfischer/php4/bin/
  program: phpize
  program: php-config


Line 641 is

[...]
640:if (method_exists($objref, $destructor)) {
641:$objref->$destructor();
642:break;
643:} else {
[...]

Putting the line

echo get_class($objref), "->$destructor", "\n";

before 641 gives

Installing PHP SAPI module
Installing shared extensions: 
/home/mfischer/php4/lib/php/extensions/no-debug-non-zts-20020429/
Installing PHP CLI binary:/home/mfischer/php4/bin/
Installing PEAR environment:  /home/mfischer/php4/lib/php/
[PEAR] Archive_Tar- installed: 0.9
[PEAR] Console_Getopt - installed: 1.0
[PEAR] PEAR   - installed: 1.0b1
pear_config->_pear

Fatal error: Call to undefined function:  ->_pear() in 
/home/mfischer/isrc/cvs/php4/pear/PEAR.php on line 642
[PEAR] DB - installed: 1.3
[PEAR] HTTP   - installed: 1.2
[PEAR] Mail   - installed: 1.0.1
[PEAR] Net_SMTP   - installed: 1.0
[PEAR] Net_Socket - installed: 1.0.1
[PEAR] XML_Parser - installed: 1.0
[PEAR] XML_RPC- installed: 1.0.4
pear_config->_pear

Fatal error: Call to undefined function:  ->_pear() in 
/home/mfischer/isrc/cvs/php4/pear/PEAR.php on line 642
Installing build environment: /home/mfischer/php4/lib/php/build/
Installing header files:  /home/mfischer/php4/include/php/
Installing helper programs:   /home/mfischer/php4/bin/
  program: phpize
  program: php-config


Now, if I change

echo get_class($objref), "->$destructor", "\n";
to
echo get_class($objref), "$destructor", "\n";

I can even reproduce a segfault:

(gdb) r /home/mfischer/isrc/cvs/php4/pear/install-pear.php 
/home/mfischer/isrc/cvs/php4/pear/packages/*.tar
Program received signal SIGSEGV, Segmentation fault.
0x081295eb in zend_hash_index_update_or_next_insert (ht=0x831e4f8, h=1, 
pData=0xbfffe7a0, nDataSize=4, pDest=0x0, flag=1) at 
/home/mfischer/isrc/cvs/php4/Zend/zend_hash.c:377
377 p = ht->arBuckets[nIndex];
(gdb) bt full
#0  0x081295eb in zend_hash_index_update_or_next_insert (ht=0x831e4f8, h=1, 
pData=0xbfffe7a0, nDataSize=4, pDest=0x0, flag=1) at 
/home/mfischer/isrc/cvs/php4/Zend/zend_hash.c:377
ht = (HashTable *) 0x831e4f8
nDataSize = 4
flag = 1
nIndex = 0
p = (Bucket *) 0xbfffe7a0
#1  0x0812bdae in zif_each (ht=1, return_value=0x8341d8c, this_ptr=0x0, 
return_value_used=1) at /home/mfischer/isrc/cvs/php4/Zend/zend_builtin_functions.c:365
return_value = (zval *) 0x8341d8c
array = (zval **) 0x81d3474
entry = (zval *) 0x8341d8c
entry_ptr = (zval **) 0x830b8e8
tmp = (zval *) 0xbfffe7a0
string_key = 0x1 
num_key = 136270088
inserted_pointer = (zval **) 0x81f6560
target_hash = (HashTable *) 0x81fcf64
#2  0x0813593a in execute (op_array=0x81f51b0) at 
/home/mfischer/isrc/cvs/php4/Zend/zend_execute.c:1597
original_return_value = (zval **) 0x81f5108
return_value_used = 1
execute_data = {opline = 0x81f6548, function_state = {function_symbol_table = 
0x82e1a2c, function = 0x81a7bc0, reserved = {0x8125419, 0x81dad64, 0x16, 0xb13c}}, 
fbc = 0x0, ce = 0x0, object = {ptr = 0x0}, Ts = 0xbfffe7c4,
  original_in_execution = 0 '\0', op_array = 0x81f51b0, prev_execute_data = 0xb0f8}
#3  0x0811f623 in call_user_function_ex (function_table=0x81a68c8, object_pp=0x0, 
function_name=0x81fcc04, retval_ptr_ptr=0xb178, param_count=0, params=0x832ade4, 
no_separation=1, symbol_table=0x0)
at /home/mfischer/isrc/cvs/php4/Zend/zend_execute_API.c:561
function_name = (zval *) 0x0
i = 0
original_return_value = (zval **) 0xbfffd608
calling_symbol_table = (HashTable *) 0x81a654c

[PHP-DEV] turning strlen() into an opcode

[Andrei Zmievski]

I've made a small patch that turns strlen() into a statement executed by
the engine instead of a function. The reasoning is that something that
integral should probably be in the engine. I haven't done hard
benchmarking but it seems to improve performance of that particular
piece of code by about 25%. Feedback is welcome.

-Andrei   http://www.gravitonic.com/
* "UNIX, isn't that some archaic form of DOS?" - our job applicant *

Index: zend_builtin_functions.c
===
RCS file: /repository/Zend/zend_builtin_functions.c,v
retrieving revision 1.124
diff -u -2 -b -w -B -r1.124 zend_builtin_functions.c
--- zend_builtin_functions.c21 Oct 2002 08:42:32 -  1.124
+++ zend_builtin_functions.c8 Nov 2002 21:15:20 -
@@ -30,5 +30,4 @@
 static ZEND_FUNCTION(func_get_arg);
 static ZEND_FUNCTION(func_get_args);
-static ZEND_NAMED_FUNCTION(zend_if_strlen);
 static ZEND_FUNCTION(strcmp);
 static ZEND_FUNCTION(strncmp);
@@ -80,5 +79,4 @@
ZEND_FE(func_get_arg,   NULL)
ZEND_FE(func_get_args,  NULL)
-   { "strlen", zend_if_strlen, NULL },
ZEND_FE(strcmp, NULL)
ZEND_FE(strncmp,NULL)
@@ -244,19 +242,4 @@
zend_hash_next_index_insert(return_value->value.ht, &element, 
sizeof(zval *), NULL);
}
-}
-/* }}} */
-
-
-/* {{{ proto int strlen(string str)
-   Get string length */
-ZEND_NAMED_FUNCTION(zend_if_strlen)
-{
-   zval **str;
-   
-   if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, &str) == FAILURE) {
-   ZEND_WRONG_PARAM_COUNT();
-   }
-   convert_to_string_ex(str);
-   RETVAL_LONG((*str)->value.str.len);
 }
 /* }}} */
Index: zend_compile.c
===
RCS file: /repository/Zend/zend_compile.c,v
retrieving revision 1.239
diff -u -2 -b -w -B -r1.239 zend_compile.c
--- zend_compile.c  3 Nov 2002 15:16:44 -   1.239
+++ zend_compile.c  8 Nov 2002 21:15:21 -
@@ -2101,4 +2101,15 @@
 }
 
+void zend_do_strlen(znode *result, znode *expr TSRMLS_DC)
+{
+   zend_op *opline = get_next_op(CG(active_op_array) TSRMLS_CC);
+
+   opline->opcode = ZEND_STRLEN;
+   opline->result.op_type = IS_TMP_VAR;
+   opline->result.u.var = get_temporary_variable(CG(active_op_array));
+   opline->op1 = *expr;
+   SET_UNUSED(opline->op2);
+   *result = opline->result;
+}
 
 void zend_do_foreach_begin(znode *foreach_token, znode *array, znode 
*open_brackets_token, znode *as_token, int variable TSRMLS_DC)
Index: zend_compile.h
===
RCS file: /repository/Zend/zend_compile.h,v
retrieving revision 1.144
diff -u -2 -b -w -B -r1.144 zend_compile.h
--- zend_compile.h  4 Aug 2002 06:39:44 -   1.144
+++ zend_compile.h  8 Nov 2002 21:15:21 -
@@ -326,4 +326,6 @@
 void zend_do_isset_or_isempty(int type, znode *result, znode *variable TSRMLS_DC);
 
+void zend_do_strlen(znode *result, znode *expr TSRMLS_DC);
+
 void zend_do_foreach_begin(znode *foreach_token, znode *array, znode 
*open_brackets_token, znode *as_token, int variable TSRMLS_DC);
 void zend_do_foreach_cont(znode *value, znode *key, znode *as_token TSRMLS_DC);
@@ -522,4 +524,6 @@
 
 #define ZEND_SEND_VAR_NO_REF   106
+
+#define ZEND_STRLEN 107
 
 /* end of block */
Index: zend_execute.c
===
RCS file: /repository/Zend/zend_execute.c,v
retrieving revision 1.315
diff -u -2 -b -w -B -r1.315 zend_execute.c
--- zend_execute.c  3 Nov 2002 15:16:45 -   1.315
+++ zend_execute.c  8 Nov 2002 21:15:21 -
@@ -2360,4 +2360,20 @@
}
NEXT_OPCODE();
+   case ZEND_STRLEN: {
+   zval tmp_val, *val = 
+get_zval_ptr(&EX(opline)->op1, EX(Ts), &EG(free_op1), BP_VAR_R);
+   if (val->type != IS_STRING) {
+   tmp_val = *val;
+   zval_copy_ctor(&tmp_val);
+   convert_to_string(&tmp_val);
+   val = &tmp_val;
+   }
+   
+EX(Ts)[EX(opline)->result.u.var].tmp_var.value.lval = val->value.str.len;
+   EX(Ts)[EX(opline)->result.u.var].tmp_var.type 
+= IS_LONG;
+   if (val == &tmp_val) {
+   zval_dtor(&tmp_val);
+   }
+   FREE_OP(EX(Ts), &EX(opline)->op1, 
+EG(free_op1));
+   }
+

[PHP-DEV] Create a class variable in extension?

[phpdev]

Hello,

1. I have been able to create a class within my extension, but am unable
to create a class variable that can be used throughout the class
methods. This class variable needs to be an array. Below is how I would
write the class in php.
class foo {
  var $foo = array();

  functions...
}

2. How can you create a constructor for your class in an extension that
loads when somebody calls $var = new foo();? Below is what I mean in php
classes:
class foo {
   function foo() {
   ...
   }
}


Thanks for any help,
Daniel Simser
[EMAIL PROTECTED]


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

Re: [PHP-DEV] Compiling PHP as Apache 2 static module?

[Melvyn Sopacua]

At 14:06 11/8/2002 -0500, Robert Twitty wrote:


Is it possible to compile PHP as an Apache 2.0 static module. None of PHP
's configure indicate that this is possible.


Nor does any other Apache mod.
There's no support for that, in Apache, last time I looked.

Believe me - I'm waiting too :)

Met vriendelijke groeten / With kind regards,

Webmaster IDG.nl
Melvyn Sopacua

<@Logan> I spent a minute looking at my own code by accident.
<@Logan> I was thinking "What the hell is this guy doing?"


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

[PHP-DEV] Compiling PHP as Apache 2 static module?

[Robert Twitty]

Is it possible to compile PHP as an Apache 2.0 static module. None of PHP
's configure indicate that this is possible.

-- bob



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

Re: [PHP-DEV] [PATCH] Fix for bug #19566

[Derick Rethans]

On Fri, 8 Nov 2002, Marcus Börger wrote:

> Moriyoshi  could you make a *.phpt file from the bug?
> 
> Attached is a new diff tested already. It also fixes a compiler warning.
> Since i do not have Zend karma someone with karma should commit it
> or give me karma.

I can commit this, after you fix the whitespace :)

Derick

> cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend\)
> Index: zend_hash.c
> ===
> RCS file: /repository/ZendEngine2/zend_hash.c,v
> retrieving revision 1.93
> diff -u -r1.93 zend_hash.c
> --- zend_hash.c 5 Nov 2002 18:22:02 -   1.93
> +++ zend_hash.c 8 Nov 2002 17:25:59 -
> @@ -722,9 +722,9 @@
> 
>  HASH_PROTECT_RECURSION(ht);
> 
> -   va_start(args, num_args);
>  p = ht->pListHead;
>  while (p != NULL) {
> +   va_start(args, num_args);
>  hash_key.arKey = p->arKey;
>  hash_key.nKeyLength = p->nKeyLength;
>  hash_key.h = p->h;
> @@ -733,8 +733,8 @@
>  } else {
>  p = p->pListNext;
>  }
> +   va_end(args);
>  }
> -   va_end(args);
> 
>  HASH_UNPROTECT_RECURSION(ht);
>   }
> @@ -1163,7 +1163,7 @@
> 
>   ZEND_API int zend_hash_compare(HashTable *ht1, HashTable *ht2, 
> compare_func_t compar, zend_bool ordered TSRMLS_DC)
>   {
> -   Bucket *p1, *p2;
> +   Bucket *p1, *p2 = NULL /* fixes warning */;
>  int result;
>  void *pData2;
> 
> 
> 
> At 16:45 08.11.2002, Moriyoshi Koizumi wrote:
> >Yep, the spec goes right. a corresponding va_end() dtor should be applied
> >to ap once ap has been initialized by a va_start().
> >IMO no va_end() is needed without a preceding va_start(), and it doesn't
> >matter if ap is used between va_start() and va_end().
> >
> >BTW, could anyone commit this patch if there seems no problem?
> >
> >Moriyoshi
> >
> >[EMAIL PROTECTED] (Marcus Börger) wrote:
> >
> > > Some comments on ISO9899 standard
> > > 7.15.1.3-2 Read between the lines: without va_end the behaviour is 
> > undefined.
> > >   What ever that means i guess you have to call va_end and that requires
> > > va_start.
> > >
> > > 7.15.1.4-3 Says do not call va_start twice without va_end.
> > >
> > > marcus
> > >
> > >
> > > ISO/IEC 9899:1999 (E) ©ISO/IEC
> > >
> > > 7.15.1.3 The va_end macro
> > > Synopsis
> > > 1 #include 
> > > void va_end(va_list ap);
> > > Description
> > > 2 The va_end macro facilitates a normal return from the function whose 
> > variable
> > > argument list was referred to by the expansion of va_start, or the 
> > function
> > > containing
> > > the expansion of va_copy, that initialized the va_list ap. The va_end 
> > macro may
> > > modify ap so that it is no longer usable (without an intervening 
> > invocation
> > > of va_start
> > > or va_copy). If there is no corresponding invocation of the va_start or 
> > va_copy
> > > macro, or if the va_end macro is not invoked before the return, the 
> > behavior is
> > > undefined.
> > > Returns
> > > 3 The va_end macro returns no value.
> > >
> > > 7.15.1.4 The va_start macro
> > > Synopsis
> > > 1 #include 
> > > void va_start(va_list ap, parmN);
> > > Description
> > > 2 The va_start macro shall be invoked before any access to the unnamed
> > > arguments.
> > > 3 The va_start macro initializes ap for subsequent use by va_arg and 
> > va_end.
> > > va_start (or va_copy) shall not be invoked again for the same ap without an
> > > intervening invocation of va_end for the same ap.
> > > (...)
> > >
> > >
> > > At 10:47 08.11.2002, Moriyoshi Koizumi wrote:
> > > >See http://www.opengroup.org/onlinepubs/007908799/xsh/stdarg.h.html
> > > >This appears to imply that va_start() can be used more than twice.
> > > >
> > > >And I don't think va_start() always has to be invoked.
> > > >
> > > >Moriyoshi
> > > >
> > > >[EMAIL PROTECTED] (Marcus Börger) wrote:
> > > >
> > > > > I am not sure if va_start can be called twice in a row (rekursive).
> > > > > Manual does not say anything about that.
> > > > >
> > > > > How about:
> > > > >
> > > > > cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend)
> > > > > Index: zend_hash.c
> > > > > ===
> > > > > RCS file: /repository/ZendEngine2/zend_hash.c,v
> > > > > retrieving revision 1.93
> > > > > diff -u -r1.93 zend_hash.c
> > > > > --- zend_hash.c 5 Nov 2002 18:22:02 -   1.93
> > > > > +++ zend_hash.c 8 Nov 2002 09:32:48 -
> > > > > @@ -722,9 +722,13 @@
> > > > >
> > > > >  HASH_PROTECT_RECURSION(ht);
> > > > >
> > > > > -   va_start(args, num_args);
> > > > >  p = ht->pListHead;
> > > > > +   if (p == NULL) {
> > > > > +   va_start(args, num_args);
> > > > > +   va_end(args);
> > > > > +   }
> > > > >  while (p != NULL) {
> > > > > +   va_start(args, num_args);
> > > > >

Re: [PHP-DEV] [PATCH] Fix for bug #19566

[Moriyoshi Koizumi]

done.

Moriyoshi

[EMAIL PROTECTED] (Marcus Börger) wrote:

> Moriyoshi  could you make a *.phpt file from the bug?
> 
> Attached is a new diff tested already. It also fixes a compiler warning.
> Since i do not have Zend karma someone with karma should commit it
> or give me karma.
> 
> marcus
> 
> cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend\)
> Index: zend_hash.c
> ===
> RCS file: /repository/ZendEngine2/zend_hash.c,v
> retrieving revision 1.93
> diff -u -r1.93 zend_hash.c
> --- zend_hash.c 5 Nov 2002 18:22:02 -   1.93
> +++ zend_hash.c 8 Nov 2002 17:25:59 -
> @@ -722,9 +722,9 @@
> 
>  HASH_PROTECT_RECURSION(ht);
> 
> -   va_start(args, num_args);
>  p = ht->pListHead;
>  while (p != NULL) {
> +   va_start(args, num_args);
>  hash_key.arKey = p->arKey;
>  hash_key.nKeyLength = p->nKeyLength;
>  hash_key.h = p->h;
> @@ -733,8 +733,8 @@
>  } else {
>  p = p->pListNext;
>  }
> +   va_end(args);
>  }
> -   va_end(args);
> 
>  HASH_UNPROTECT_RECURSION(ht);
>   }
> @@ -1163,7 +1163,7 @@
> 
>   ZEND_API int zend_hash_compare(HashTable *ht1, HashTable *ht2, 
> compare_func_t compar, zend_bool ordered TSRMLS_DC)
>   {
> -   Bucket *p1, *p2;
> +   Bucket *p1, *p2 = NULL /* fixes warning */;
>  int result;
>  void *pData2;
> 
> 
> 
> At 16:45 08.11.2002, Moriyoshi Koizumi wrote:
> >Yep, the spec goes right. a corresponding va_end() dtor should be applied
> >to ap once ap has been initialized by a va_start().
> >IMO no va_end() is needed without a preceding va_start(), and it doesn't
> >matter if ap is used between va_start() and va_end().
> >
> >BTW, could anyone commit this patch if there seems no problem?
> >
> >Moriyoshi
> >
> >[EMAIL PROTECTED] (Marcus Börger) wrote:
> >
> > > Some comments on ISO9899 standard
> > > 7.15.1.3-2 Read between the lines: without va_end the behaviour is 
> > undefined.
> > >   What ever that means i guess you have to call va_end and that requires
> > > va_start.
> > >
> > > 7.15.1.4-3 Says do not call va_start twice without va_end.
> > >
> > > marcus
> > >
> > >
> > > ISO/IEC 9899:1999 (E) ©ISO/IEC
> > >
> > > 7.15.1.3 The va_end macro
> > > Synopsis
> > > 1 #include 
> > > void va_end(va_list ap);
> > > Description
> > > 2 The va_end macro facilitates a normal return from the function whose 
> > variable
> > > argument list was referred to by the expansion of va_start, or the 
> > function
> > > containing
> > > the expansion of va_copy, that initialized the va_list ap. The va_end 
> > macro may
> > > modify ap so that it is no longer usable (without an intervening 
> > invocation
> > > of va_start
> > > or va_copy). If there is no corresponding invocation of the va_start or 
> > va_copy
> > > macro, or if the va_end macro is not invoked before the return, the 
> > behavior is
> > > undefined.
> > > Returns
> > > 3 The va_end macro returns no value.
> > >
> > > 7.15.1.4 The va_start macro
> > > Synopsis
> > > 1 #include 
> > > void va_start(va_list ap, parmN);
> > > Description
> > > 2 The va_start macro shall be invoked before any access to the unnamed
> > > arguments.
> > > 3 The va_start macro initializes ap for subsequent use by va_arg and 
> > va_end.
> > > va_start (or va_copy) shall not be invoked again for the same ap without an
> > > intervening invocation of va_end for the same ap.
> > > (...)
> > >
> > >
> > > At 10:47 08.11.2002, Moriyoshi Koizumi wrote:
> > > >See http://www.opengroup.org/onlinepubs/007908799/xsh/stdarg.h.html
> > > >This appears to imply that va_start() can be used more than twice.
> > > >
> > > >And I don't think va_start() always has to be invoked.
> > > >
> > > >Moriyoshi
> > > >
> > > >[EMAIL PROTECTED] (Marcus Börger) wrote:
> > > >
> > > > > I am not sure if va_start can be called twice in a row (rekursive).
> > > > > Manual does not say anything about that.
> > > > >
> > > > > How about:
> > > > >
> > > > > cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend)
> > > > > Index: zend_hash.c
> > > > > ===
> > > > > RCS file: /repository/ZendEngine2/zend_hash.c,v
> > > > > retrieving revision 1.93
> > > > > diff -u -r1.93 zend_hash.c
> > > > > --- zend_hash.c 5 Nov 2002 18:22:02 -   1.93
> > > > > +++ zend_hash.c 8 Nov 2002 09:32:48 -
> > > > > @@ -722,9 +722,13 @@
> > > > >
> > > > >  HASH_PROTECT_RECURSION(ht);
> > > > >
> > > > > -   va_start(args, num_args);
> > > > >  p = ht->pListHead;
> > > > > +   if (p == NULL) {
> > > > > +   va_start(args, num_args);
> > > > > +   va_end(args);
> > > > > +   }
> > > > >  while (p != NULL) {
> > > > > +   va_start(args, num_args);
> > > > >  hash_key.a

Re: [PHP-DEV] [PATCH] Fix for bug #19566

[Marcus Börger]

Moriyoshi  could you make a *.phpt file from the bug?

Attached is a new diff tested already. It also fixes a compiler warning.
Since i do not have Zend karma someone with karma should commit it
or give me karma.

marcus

cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend\)
Index: zend_hash.c
===
RCS file: /repository/ZendEngine2/zend_hash.c,v
retrieving revision 1.93
diff -u -r1.93 zend_hash.c
--- zend_hash.c 5 Nov 2002 18:22:02 -   1.93
+++ zend_hash.c 8 Nov 2002 17:25:59 -
@@ -722,9 +722,9 @@

HASH_PROTECT_RECURSION(ht);

-   va_start(args, num_args);
p = ht->pListHead;
while (p != NULL) {
+   va_start(args, num_args);
hash_key.arKey = p->arKey;
hash_key.nKeyLength = p->nKeyLength;
hash_key.h = p->h;
@@ -733,8 +733,8 @@
} else {
p = p->pListNext;
}
+   va_end(args);
}
-   va_end(args);

HASH_UNPROTECT_RECURSION(ht);
 }
@@ -1163,7 +1163,7 @@

 ZEND_API int zend_hash_compare(HashTable *ht1, HashTable *ht2, 
compare_func_t compar, zend_bool ordered TSRMLS_DC)
 {
-   Bucket *p1, *p2;
+   Bucket *p1, *p2 = NULL /* fixes warning */;
int result;
void *pData2;



At 16:45 08.11.2002, Moriyoshi Koizumi wrote:
Yep, the spec goes right. a corresponding va_end() dtor should be applied
to ap once ap has been initialized by a va_start().
IMO no va_end() is needed without a preceding va_start(), and it doesn't
matter if ap is used between va_start() and va_end().

BTW, could anyone commit this patch if there seems no problem?

Moriyoshi

[EMAIL PROTECTED] (Marcus Börger) wrote:

> Some comments on ISO9899 standard
> 7.15.1.3-2 Read between the lines: without va_end the behaviour is 
undefined.
>   What ever that means i guess you have to call va_end and that requires
> va_start.
>
> 7.15.1.4-3 Says do not call va_start twice without va_end.
>
> marcus
>
>
> ISO/IEC 9899:1999 (E) ©ISO/IEC
>
> 7.15.1.3 The va_end macro
> Synopsis
> 1 #include 
> void va_end(va_list ap);
> Description
> 2 The va_end macro facilitates a normal return from the function whose 
variable
> argument list was referred to by the expansion of va_start, or the 
function
> containing
> the expansion of va_copy, that initialized the va_list ap. The va_end 
macro may
> modify ap so that it is no longer usable (without an intervening 
invocation
> of va_start
> or va_copy). If there is no corresponding invocation of the va_start or 
va_copy
> macro, or if the va_end macro is not invoked before the return, the 
behavior is
> undefined.
> Returns
> 3 The va_end macro returns no value.
>
> 7.15.1.4 The va_start macro
> Synopsis
> 1 #include 
> void va_start(va_list ap, parmN);
> Description
> 2 The va_start macro shall be invoked before any access to the unnamed
> arguments.
> 3 The va_start macro initializes ap for subsequent use by va_arg and 
va_end.
> va_start (or va_copy) shall not be invoked again for the same ap without an
> intervening invocation of va_end for the same ap.
> (...)
>
>
> At 10:47 08.11.2002, Moriyoshi Koizumi wrote:
> >See http://www.opengroup.org/onlinepubs/007908799/xsh/stdarg.h.html
> >This appears to imply that va_start() can be used more than twice.
> >
> >And I don't think va_start() always has to be invoked.
> >
> >Moriyoshi
> >
> >[EMAIL PROTECTED] (Marcus Börger) wrote:
> >
> > > I am not sure if va_start can be called twice in a row (rekursive).
> > > Manual does not say anything about that.
> > >
> > > How about:
> > >
> > > cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend)
> > > Index: zend_hash.c
> > > ===
> > > RCS file: /repository/ZendEngine2/zend_hash.c,v
> > > retrieving revision 1.93
> > > diff -u -r1.93 zend_hash.c
> > > --- zend_hash.c 5 Nov 2002 18:22:02 -   1.93
> > > +++ zend_hash.c 8 Nov 2002 09:32:48 -
> > > @@ -722,9 +722,13 @@
> > >
> > >  HASH_PROTECT_RECURSION(ht);
> > >
> > > -   va_start(args, num_args);
> > >  p = ht->pListHead;
> > > +   if (p == NULL) {
> > > +   va_start(args, num_args);
> > > +   va_end(args);
> > > +   }
> > >  while (p != NULL) {
> > > +   va_start(args, num_args);
> > >  hash_key.arKey = p->arKey;
> > >  hash_key.nKeyLength = p->nKeyLength;
> > >  hash_key.h = p->h;
> > > @@ -733,8 +737,8 @@
> > >  } else {
> > >  p = p->pListNext;
> > >  }
> > > +   va_end(args);
> > >  }
> > > -   va_end(args);
> > >
> > >  HASH_UNPROTECT_RECURSION(ht);
> > >   }
> > >
> > >
> > > marcus
> > >
> > > At 09:52 08.11.2002, Moriyoshi Koizumi wrote:
> > > >Hi,
> > > >
> > > >The attached patch is a probable fix for bug #19566

[PHP-DEV] RfC: *_fetch_object()

[Timm Friebe]

Hi,
what does everyone think about adding a second parameter to the
*_fetch_object() functions (sybase_fetch_object, mysql_fetch_object, ...
etc.) which allows users to define a class name which will then be used
instead of "stdClass"?

E.g.:
class Article {
var $article_id, $caption, $text;
}

$q= sybase_query('select * from article where article_id= 1');
if ($q) while ($a= sybase_fetch_object($q, 'Article')) {
var_dump($a);
}

This saves a couple of lines of code in PHP (formerly, you'd either put
all of article's attributes in the constructor, made the constructor
accept an associative array or assigned all of the attributes like this:

$a= &new Article();
$a->article_id= $row['article_id'];
$a->caption= $row['caption'];
$a->text= $row['text'];

) all of which seems ugly and looks like unnecessary overhead. Since PHP
is missing a cast working on user-defined types (

while ($o= sybase_fetch_object($q)) {
$a= (Article)$o;
}

) there would be another suggestion to introduce a function cast:

while ($o= sybase_fetch_object($q)) {
$a= cast($o, 'Article');
}

Though maybe the name isn't ideal and could be implemented in userland,
too (
function &cast(&$var, $type) {
// [...Handle non-objects and normal types...]
// [...Handle non-existant classes w/ name $type...]
$ret= &new $type();
foreach (get_object_vars($var) as $k=> $v) {
$ret->$k= $v;
}
return $ret;
}

) but with more performance issues than if it was built-in. Maybe it's
even simpler to allow (MyType)$var syntax, but this would have to be
introduced into Zend Engine.

Thoughts?

-- 
Timm
Any sufficiently advanced bug is indistinguishable from a feature


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

Re: [PHP-DEV] [PATCH] Fix for bug #19566

[Moriyoshi Koizumi]

Yep, the spec goes right. a corresponding va_end() dtor should be applied 
to ap once ap has been initialized by a va_start().
IMO no va_end() is needed without a preceding va_start(), and it doesn't 
matter if ap is used between va_start() and va_end().

BTW, could anyone commit this patch if there seems no problem?

Moriyoshi

[EMAIL PROTECTED] (Marcus Börger) wrote:

> Some comments on ISO9899 standard
> 7.15.1.3-2 Read between the lines: without va_end the behaviour is undefined.
>   What ever that means i guess you have to call va_end and that requires 
> va_start.
> 
> 7.15.1.4-3 Says do not call va_start twice without va_end.
> 
> marcus
> 
> 
> ISO/IEC 9899:1999 (E) ©ISO/IEC
> 
> 7.15.1.3 The va_end macro
> Synopsis
> 1 #include 
> void va_end(va_list ap);
> Description
> 2 The va_end macro facilitates a normal return from the function whose variable
> argument list was referred to by the expansion of va_start, or the function 
> containing
> the expansion of va_copy, that initialized the va_list ap. The va_end macro may
> modify ap so that it is no longer usable (without an intervening invocation 
> of va_start
> or va_copy). If there is no corresponding invocation of the va_start or va_copy
> macro, or if the va_end macro is not invoked before the return, the behavior is
> undefined.
> Returns
> 3 The va_end macro returns no value.
> 
> 7.15.1.4 The va_start macro
> Synopsis
> 1 #include 
> void va_start(va_list ap, parmN);
> Description
> 2 The va_start macro shall be invoked before any access to the unnamed 
> arguments.
> 3 The va_start macro initializes ap for subsequent use by va_arg and va_end.
> va_start (or va_copy) shall not be invoked again for the same ap without an
> intervening invocation of va_end for the same ap.
> (...)
> 
> 
> At 10:47 08.11.2002, Moriyoshi Koizumi wrote:
> >See http://www.opengroup.org/onlinepubs/007908799/xsh/stdarg.h.html
> >This appears to imply that va_start() can be used more than twice.
> >
> >And I don't think va_start() always has to be invoked.
> >
> >Moriyoshi
> >
> >[EMAIL PROTECTED] (Marcus Börger) wrote:
> >
> > > I am not sure if va_start can be called twice in a row (rekursive).
> > > Manual does not say anything about that.
> > >
> > > How about:
> > >
> > > cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend)
> > > Index: zend_hash.c
> > > ===
> > > RCS file: /repository/ZendEngine2/zend_hash.c,v
> > > retrieving revision 1.93
> > > diff -u -r1.93 zend_hash.c
> > > --- zend_hash.c 5 Nov 2002 18:22:02 -   1.93
> > > +++ zend_hash.c 8 Nov 2002 09:32:48 -
> > > @@ -722,9 +722,13 @@
> > >
> > >  HASH_PROTECT_RECURSION(ht);
> > >
> > > -   va_start(args, num_args);
> > >  p = ht->pListHead;
> > > +   if (p == NULL) {
> > > +   va_start(args, num_args);
> > > +   va_end(args);
> > > +   }
> > >  while (p != NULL) {
> > > +   va_start(args, num_args);
> > >  hash_key.arKey = p->arKey;
> > >  hash_key.nKeyLength = p->nKeyLength;
> > >  hash_key.h = p->h;
> > > @@ -733,8 +737,8 @@
> > >  } else {
> > >  p = p->pListNext;
> > >  }
> > > +   va_end(args);
> > >  }
> > > -   va_end(args);
> > >
> > >  HASH_UNPROTECT_RECURSION(ht);
> > >   }
> > >
> > >
> > > marcus
> > >
> > > At 09:52 08.11.2002, Moriyoshi Koizumi wrote:
> > > >Hi,
> > > >
> > > >The attached patch is a probable fix for bug #19566. I guess the bug
> > > >is that va_list is not properly initialized before each callback function
> > > >call. I've tested it in PPC linux, and it works fine.
> > > >
> > > >Regards,
> > > >Moriyoshi
> > > >
> > > >
> > > >--
> > > >PHP Development Mailing List 
> > > >To unsubscribe, visit: http://www.php.net/unsub.php


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

Re: [PHP-DEV] CVS account request

[Wez Furlong]

Hello Sergey,

PHP 4.3 will/does have SSL and TLS support integrated into the fopen
and fsockopen functions. (see the online manual:
http://php.net/fopen and http://php.net/fsockopen).

The current implementation requires that the openssl extension
is built-in to php (rather than shared), and does not allow for
using certificates (as your patch does).

I'm not so keen on the way that you get the fd from the sockets
extension, and would prefer to see those features integrated into
PHP more fully, so...

If you could read through the online docs for streams, take a look
in main/network.c and main/streams.c and come up with an alternative
patch that is integrated into the new streams API, I will review it
and then most likely commit it.  Feel free to ask me questions on
streams (as a hint, the certificate stuff should probably use the
stream_set_option API).

Please also read the README.SUBMITTING-PATCH file before posting
your next patch.

Thanks for your efforts!

--Wez.
"Streams Guy" and openssl extension maintainer

On 11/08/02, "Sergey A. Smitienko" <[EMAIL PROTECTED]> wrote:
> Hello,
>   
>   I want to contribute some functions to openssl and sockets
>   extantions, like SSL/TSL support for internet connections.
>   
>   I've made some patches for 4.2.3 - you can see it on my
>   homepage: www.sergey-smitienko.com.ua/files/.



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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /build buildcheck.sh

[Andi Gutmans]

By the way, I still haven't completely verified that this problem also 
happens with ZE1.
The main problem is that it's hard to find because it seems to have to do 
with bison's stack (some kind of corruption).
I haven't had time to report it to the bison guys to make sure it's not a 
bug in the engine.

Andi

At 02:57 PM 11/8/2002 +0100, Sascha Schumann wrote:
> Again: bison is not run at all when compiling a regular PHP version. 
The files
> generated by bison and flex are bundled in the source tarball.

In order to accomodate regular administrators, the already
existing bison check in configure should be extended to
display appropiate compatibility warnings.

Distribution maintainers and release managers rely on the
genfiles script to produce pre-generated files.  It is the
only appropiate location for a check which actually refuses
to generate files based on certain criteria.

So, there you go.  No job is left for buildconf.

- Sascha


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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /build buildcheck.sh

[Sascha Schumann]

> Again: bison is not run at all when compiling a regular PHP version. The files
> generated by bison and flex are bundled in the source tarball.

In order to accomodate regular administrators, the already
existing bison check in configure should be extended to
display appropiate compatibility warnings.

Distribution maintainers and release managers rely on the
genfiles script to produce pre-generated files.  It is the
only appropiate location for a check which actually refuses
to generate files based on certain criteria.

So, there you go.  No job is left for buildconf.

- Sascha


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

[PHP-DEV] CVS account request

[Sergey A. Smitienko]

Hello,

I want to contribute some functions to openssl and sockets
extantions, like SSL/TSL support for internet connections.

I've made some patches for 4.2.3 - you can see it on my
homepage: www.sergey-smitienko.com.ua/files/.

-- 
The Emperor wants to control the outer space, Yoda wants to explore the inner
space.That's the fundamental difference between the good and the bad sides of
the Force.

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

Re: [PHP-DEV] [PATCH] Fix for bug #19566

[Marcus Börger]

Some comments on ISO9899 standard
7.15.1.3-2 Read between the lines: without va_end the behaviour is undefined.
 What ever that means i guess you have to call va_end and that requires 
va_start.

7.15.1.4-3 Says do not call va_start twice without va_end.

marcus


ISO/IEC 9899:1999 (E) ©ISO/IEC

7.15.1.3 The va_end macro
Synopsis
1 #include 
void va_end(va_list ap);
Description
2 The va_end macro facilitates a normal return from the function whose variable
argument list was referred to by the expansion of va_start, or the function 
containing
the expansion of va_copy, that initialized the va_list ap. The va_end macro may
modify ap so that it is no longer usable (without an intervening invocation 
of va_start
or va_copy). If there is no corresponding invocation of the va_start or va_copy
macro, or if the va_end macro is not invoked before the return, the behavior is
undefined.
Returns
3 The va_end macro returns no value.

7.15.1.4 The va_start macro
Synopsis
1 #include 
void va_start(va_list ap, parmN);
Description
2 The va_start macro shall be invoked before any access to the unnamed 
arguments.
3 The va_start macro initializes ap for subsequent use by va_arg and va_end.
va_start (or va_copy) shall not be invoked again for the same ap without an
intervening invocation of va_end for the same ap.
(...)


At 10:47 08.11.2002, Moriyoshi Koizumi wrote:
See http://www.opengroup.org/onlinepubs/007908799/xsh/stdarg.h.html
This appears to imply that va_start() can be used more than twice.

And I don't think va_start() always has to be invoked.

Moriyoshi

[EMAIL PROTECTED] (Marcus Börger) wrote:

> I am not sure if va_start can be called twice in a row (rekursive).
> Manual does not say anything about that.
>
> How about:
>
> cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend)
> Index: zend_hash.c
> ===
> RCS file: /repository/ZendEngine2/zend_hash.c,v
> retrieving revision 1.93
> diff -u -r1.93 zend_hash.c
> --- zend_hash.c 5 Nov 2002 18:22:02 -   1.93
> +++ zend_hash.c 8 Nov 2002 09:32:48 -
> @@ -722,9 +722,13 @@
>
>  HASH_PROTECT_RECURSION(ht);
>
> -   va_start(args, num_args);
>  p = ht->pListHead;
> +   if (p == NULL) {
> +   va_start(args, num_args);
> +   va_end(args);
> +   }
>  while (p != NULL) {
> +   va_start(args, num_args);
>  hash_key.arKey = p->arKey;
>  hash_key.nKeyLength = p->nKeyLength;
>  hash_key.h = p->h;
> @@ -733,8 +737,8 @@
>  } else {
>  p = p->pListNext;
>  }
> +   va_end(args);
>  }
> -   va_end(args);
>
>  HASH_UNPROTECT_RECURSION(ht);
>   }
>
>
> marcus
>
> At 09:52 08.11.2002, Moriyoshi Koizumi wrote:
> >Hi,
> >
> >The attached patch is a probable fix for bug #19566. I guess the bug
> >is that va_list is not properly initialized before each callback function
> >call. I've tested it in PPC linux, and it works fine.
> >
> >Regards,
> >Moriyoshi
> >
> >
> >--
> >PHP Development Mailing List 
> >To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /build buildcheck.sh

[Edin Kadribasic]

On Friday 08 November 2002 13:47, Sascha Schumann wrote:
> Again:
>
> buildconf does not run bison.
>
> There is no point to put a bison check into buildconf.
>
> The bison version number should be checked before bison is
> actually run.  That would be
>
> configure
> genfiles

Again: bison is not run at all when compiling a regular PHP version. The files 
generated by bison and flex are bundled in the source tarball.

You need bison and flex only if you checkout CVS from the repository. 
buildconf is run on the same occassion. Therefore I still think that bison 
check should be in there. Why bother checking for bison version in configure 
when most users will not need it?

Edin

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

Re: [PHP-DEV] Extending DB2 odbc support

[Dan Kalowsky]

Tim,

I've been maintaining the ODBC extension for a bit.  While I welcome 
the addition of new ODBC functionality, I am hesitent to add in 
functions that are not ODBC compliant to the code (i.e. db2_connect(), 
or some such).

If you can make the functions generic enough that they can be executed 
through ODBC, then feel free to submit the patches to the list and 
myself to get them included in.

On Friday, November 8, 2002, at 07:12 AM, tim wrote:

Hi,

I am writing php applications which use php's builtin ibm-db2 support 
through odbc. However there are some DB2-specific extensions which are 
not included in php's DB2 support. I am interested in adding this 
functionality to php. Who should I talk to in order to avoid 
duplication of work? How would I best implement this in parallel with 
php's odbc layer?

Thanks,
Tim

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

>---<
Dan Kalowsky"Thought I'd visit the club,
http://www.deadmime.org/~dankGot as far as the door."
[EMAIL PROTECTED]  - "Don't Get Around Much Anymore",
[EMAIL PROTECTED]Ella Fitzgerald


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

[PHP-DEV] IBM 4694

[Jean-Michel Garcia]

Hello all,
I'm trying to use a till (cash register or POS) : IBM 4694.
This computer is a PC based engine, with a special plugged in card, 
hosting a set of RS 485 ports for devices like keyboard, printer or display.
The driver is writen by IBM, but not open Source.
So I'm fighting with PHP trying to create an enclosing module for the libs.
Does anyone ever heard about that ??
Thanks
JMG


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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /build buildcheck.sh

[Sascha Schumann]

> Since PHP distributions are shipped with bison and flex files pre-built, isn't
> it more logical to put the chek in ./buildconf?

Again:

buildconf does not run bison.

There is no point to put a bison check into buildconf.

The bison version number should be checked before bison is
actually run.  That would be

configure
genfiles

- Sascha


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

[PHP-DEV] Extending DB2 odbc support

[tim]

Hi,

I am writing php applications which use php's builtin ibm-db2 support through odbc. 
However there are some DB2-specific extensions which are not included in php's DB2 
support. I am interested in adding this functionality to php. Who should I talk to in 
order to avoid duplication of work? How would I best implement this in parallel with 
php's odbc layer? 

Thanks,
Tim

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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /build buildcheck.sh

[Edin Kadribasic]

On Friday 08 November 2002 12:54, Sascha Schumann wrote:
> > The same script doesn't work for me with Engine 2 bison > 1.28 and Engine
> > 1 bison == 1.75 (I haven't tried other combinations yet.
> > So this doesn't seem to be only an Engine 2 problem.
>
> Ok, then a suppressable configure-time check needs to be added.

Since PHP distributions are shipped with bison and flex files pre-built, isn't 
it more logical to put the chek in ./buildconf?

Edin

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

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /build buildcheck.sh

[Sascha Schumann]

> The same script doesn't work for me with Engine 2 bison > 1.28 and Engine 1
> bison == 1.75 (I haven't tried other combinations yet.
> So this doesn't seem to be only an Engine 2 problem.

Ok, then a suppressable configure-time check needs to be added.

- Sascha


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

Re: [PHP-DEV] mbstring and 4.3.0

[Maxim Maletsky]

I think Wez got a point here. Disabling mbstring can make many unhappy.


--
Maxim Maletsky
[EMAIL PROTECTED]



"Wez Furlong" <[EMAIL PROTECTED]> wrote... :

> I see the known-good codeset conversion implementation as a *very* good
> reason to have mbstring enabled by default.
> (Just look at all the problems with iconv and recode on different systems
> out there).
> 
> I agree that the magic features for lazy programmers (function overloading
> and transparent encoding) are slightly worrying, but they are disabled
> by default, and as I have said - I don't use those, but I do use the
> conversion functions and *that* configuration works just fine.
> 
> The conversion functions are something that really should be there by
> default, as it allows people to write portable globalized scripts.
> Remember that a large majority of users are vhosted and have not control
> over the build of PHP.  By not providing a reliable and portable
> codeset conversion API, we are holding back "the masses" from writing
> (and distributing) "killer apps" in PHP.
> 
> Yes, I can enable mbstring at configure time, and yes, the CJK people
> can do likewise, but what about the rest of the world running from vhosts
> when they want to use unicode, quoted-printable, uu-encoding,  favourite encoding here> encodings which are also supported by mbstring?
> 
> We took the decision to enable it by default; let's not be short-sighted
> and disable it primarily out of ignorance (no offence intended).
> 
> I've yet to see someone comment on my suggestions for a practical solution
> that would shut up both myself and the people advocating disabling it.
> 
> --Wez.
> 
> On 11/07/02, "Derick Rethans" <[EMAIL PROTECTED]> wrote:
> > On Thu, 7 Nov 2002, Marcus Boerger wrote:
> > 
> > > To make php be easier usable in non US-ASCII (127chars) environments
> > > especially those requiring UCS-2, UTF-8 or other any character mapping
> > > other than iso-8859-1 or -15 we should more likly try to integrate mbstring
> > > fully in php. As long as we cannot or want not make it a core component
> > > such as ext/standard we should enable it by default.
> > 
> > If people want it they can use --enable-mbstring. I see no reason why it 
> > should be enabled by default as long as it's not fully integrated in the 
> > core.
> 
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


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

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /build buildcheck.sh

[Andi Gutmans]

At 12:29 PM 10/30/2002 +0100, Sascha Schumann wrote:

>a) Bison is needed for CVS builds
>b) Bison is not needed for snapshot/release builds
>c) buildconf is needed for CVS builds

At some point in time, the CVS becomes a release.  Then you
would need to move the check into configure.  Why not do it
properly the first time?

>Bison versions above 1.28 have been reported (e.g. by Andi) to not work.

Yes, for Zend Engine *2*.

http://news.php.net/article.php?group=php.cvs&article=15505

Version 1, the default one, works perfectly with e.g. Bison
1.35.  At least I have not seen anyone claim the contrary.




 function getFrontendObject()
{

  $a = & new $GLOBALS['_PEAR_Command_uiclass'];
}
?>

The same script doesn't work for me with Engine 2 bison > 1.28 and Engine 1 
bison == 1.75 (I haven't tried other combinations yet.
So this doesn't seem to be only an Engine 2 problem.
Andi


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

Re: [PHP-DEV] mbstring and 4.3.0

[Wez Furlong]

I see the known-good codeset conversion implementation as a *very* good
reason to have mbstring enabled by default.
(Just look at all the problems with iconv and recode on different systems
out there).

I agree that the magic features for lazy programmers (function overloading
and transparent encoding) are slightly worrying, but they are disabled
by default, and as I have said - I don't use those, but I do use the
conversion functions and *that* configuration works just fine.

The conversion functions are something that really should be there by
default, as it allows people to write portable globalized scripts.
Remember that a large majority of users are vhosted and have not control
over the build of PHP.  By not providing a reliable and portable
codeset conversion API, we are holding back "the masses" from writing
(and distributing) "killer apps" in PHP.

Yes, I can enable mbstring at configure time, and yes, the CJK people
can do likewise, but what about the rest of the world running from vhosts
when they want to use unicode, quoted-printable, uu-encoding,  encodings which are also supported by mbstring?

We took the decision to enable it by default; let's not be short-sighted
and disable it primarily out of ignorance (no offence intended).

I've yet to see someone comment on my suggestions for a practical solution
that would shut up both myself and the people advocating disabling it.

--Wez.

On 11/07/02, "Derick Rethans" <[EMAIL PROTECTED]> wrote:
> On Thu, 7 Nov 2002, Marcus Boerger wrote:
> 
> > To make php be easier usable in non US-ASCII (127chars) environments
> > especially those requiring UCS-2, UTF-8 or other any character mapping
> > other than iso-8859-1 or -15 we should more likly try to integrate mbstring
> > fully in php. As long as we cannot or want not make it a core component
> > such as ext/standard we should enable it by default.
> 
> If people want it they can use --enable-mbstring. I see no reason why it 
> should be enabled by default as long as it's not fully integrated in the 
> core.



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

Re: [PHP-DEV] Re: mbstring and 4.3.0

[Moriyoshi Koizumi]

> PHP 4.3.0's Zend Engine also comes with SJIS awareness. It does not
> make sense to have SJIS awareness without mbstring also.
> (Need compile option to enable SJIS awareness)

In addition, we'll have to take in account all of the double byte encodings 
in which second bytes of characters spans GL area (\x20-\x7e), like cp936(a 
MS variant of GB2312), cp949(ditto of KSC5601). Those encodings also need 
such awareness.

Moriyoshi


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

[PHP-DEV] shared build fails. gettext and imap

[Yasuo Ohgaki]

Recent CVS source fails to build gettext and imap
(Bas shared module with my Linux.
(B
(BAnyone can build them as shared module?
(B
(B--
(BYasuo Ohgaki
(B
(B
(B-- 
(BPHP Development Mailing List 
(BTo unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Fix for bug #19566

[Moriyoshi Koizumi]

See http://www.opengroup.org/onlinepubs/007908799/xsh/stdarg.h.html
This appears to imply that va_start() can be used more than twice.

And I don't think va_start() always has to be invoked.

Moriyoshi

[EMAIL PROTECTED] (Marcus Börger) wrote:

> I am not sure if va_start can be called twice in a row (rekursive).
> Manual does not say anything about that.
> 
> How about:
> 
> cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend)
> Index: zend_hash.c
> ===
> RCS file: /repository/ZendEngine2/zend_hash.c,v
> retrieving revision 1.93
> diff -u -r1.93 zend_hash.c
> --- zend_hash.c 5 Nov 2002 18:22:02 -   1.93
> +++ zend_hash.c 8 Nov 2002 09:32:48 -
> @@ -722,9 +722,13 @@
> 
>  HASH_PROTECT_RECURSION(ht);
> 
> -   va_start(args, num_args);
>  p = ht->pListHead;
> +   if (p == NULL) {
> +   va_start(args, num_args);
> +   va_end(args);
> +   }
>  while (p != NULL) {
> +   va_start(args, num_args);
>  hash_key.arKey = p->arKey;
>  hash_key.nKeyLength = p->nKeyLength;
>  hash_key.h = p->h;
> @@ -733,8 +737,8 @@
>  } else {
>  p = p->pListNext;
>  }
> +   va_end(args);
>  }
> -   va_end(args);
> 
>  HASH_UNPROTECT_RECURSION(ht);
>   }
> 
> 
> marcus
> 
> At 09:52 08.11.2002, Moriyoshi Koizumi wrote:
> >Hi,
> >
> >The attached patch is a probable fix for bug #19566. I guess the bug
> >is that va_list is not properly initialized before each callback function
> >call. I've tested it in PPC linux, and it works fine.
> >
> >Regards,
> >Moriyoshi
> >
> >
> >--
> >PHP Development Mailing List 
> >To unsubscribe, visit: http://www.php.net/unsub.php


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

Re: [PHP-DEV] Re: cvs: php4 / Makefile.global run-tests.php

[Yasuo Ohgaki]

Yasuo Ohgaki wrote:

Derick,

I've pointed out problems _WEEKS_ ago.
I let you know problems _MANY_ times.

Derick, be responsible with your change and opinion at least.
Don't forget you're the one broke it w/o discussion first.
When I add "-c php.ini-dist", there is discussion. As a result,
there is -c option.

Please revert your patch. (And don't forget to remove double
-d 'safe_mode=0')


I don't see commit that fixes problems yet.
When you'll do that?

--
Yasuo Ohgaki




BTW, everyone agree with Derick's statement for such
a simple & obvious bug fixes with CVS managed sources?

--
Yasuo Ohgaki

Derick Rethans wrote:


On Thu, 31 Oct 2002, Yasuo Ohgaki wrote:



Derick Rethans wrote:


derickThu Oct 31 09:02:00 2002 EDT

 Modified files: /php4Makefile.global 
run-tests.php  Log:
 Discuss first!


Huh? What do you mean discuss first?
There is discussion and the patch is valid.

In addition, you're the one insisted certain ini should
not be used.

Let me know how you would like to solve puzzle. For instance,
if users is disabling some functions that are needed by
run-tests.php?

You should have clever idea that I cannot think of ;)




Authors: Ilia Alshanetsky <[EMAIL PROTECTED]> 
 Preston L. Bannister <[EMAIL PROTECTED]>   
 Marcus Boerger <[EMAIL PROTECTED]>  
 Derick Rethans <[EMAIL PROTECTED]> 
 Sander Roobol <[EMAIL PROTECTED]> 
Those people commit to run-tests.php from now, whether a patch is 
valid or not. If too much other people keep messing with it we will 
never get a valid and stable testsuite.
Derick





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

Re: [PHP-DEV] [PATCH] Fix for bug #19566

[Marcus Börger]

I am not sure if va_start can be called twice in a row (rekursive).
Manual does not say anything about that.

How about:

cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend)
Index: zend_hash.c
===
RCS file: /repository/ZendEngine2/zend_hash.c,v
retrieving revision 1.93
diff -u -r1.93 zend_hash.c
--- zend_hash.c 5 Nov 2002 18:22:02 -   1.93
+++ zend_hash.c 8 Nov 2002 09:32:48 -
@@ -722,9 +722,13 @@

HASH_PROTECT_RECURSION(ht);

-   va_start(args, num_args);
p = ht->pListHead;
+   if (p == NULL) {
+   va_start(args, num_args);
+   va_end(args);
+   }
while (p != NULL) {
+   va_start(args, num_args);
hash_key.arKey = p->arKey;
hash_key.nKeyLength = p->nKeyLength;
hash_key.h = p->h;
@@ -733,8 +737,8 @@
} else {
p = p->pListNext;
}
+   va_end(args);
}
-   va_end(args);

HASH_UNPROTECT_RECURSION(ht);
 }


marcus

At 09:52 08.11.2002, Moriyoshi Koizumi wrote:

Hi,

The attached patch is a probable fix for bug #19566. I guess the bug
is that va_list is not properly initialized before each callback function
call. I've tested it in PPC linux, and it works fine.

Regards,
Moriyoshi


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

[PHP-DEV] Re: mbstring and 4.3.0

[Yasuo Ohgaki]

Andrei Zmievski wrote:

At the PHP Conference in Germany several of us have discussed the
current state of mbstring and there was a proposal to not have it
enabled by default for 4.3.0 release. It seems that the extension
attempts to do "magic" stuff by overloading functions in the executor
globals and, as Thies said, that could be dangerous. Also, doesn't it
affect run-tests.php script currently?


AFAIK, it doesn't.



Comments are welcome.



Encoding translation, which is hard coded in 4.2.x or less, is
integrated and changeable by php.ini or .htaccess setting. And it's
default to off.

Function overloading is changeable by php.ini or .htaccess. It gives
flexibility porting single byte application to multibyte aware with a
lot less hassle. It's default to off and only changeable by INI_SYSTEM
and INI_PERDIR.

PHP 4.3.0's Zend Engine also comes with SJIS awareness. It does not
make sense to have SJIS awareness without mbstring also.
(Need compile option to enable SJIS awareness)

There are few modules that depend on mbstring. Current module loader
is not smart enough to detect dependency, too.

Unfortunately, PHP 4.2.3 has problem for handling array inputs, but
it's not mbstring developers' fault.

--
Yasuo Ohgaki


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

Re: [PHP-DEV] mbstring and 4.3.0

[Moriyoshi Koizumi]

--snip
> but the mysql extension isn't invasive of other parts of the language, and
> can be safely disabled. I do not believe mbstring can be safely disabled,
> and i do not think that you have the transparent stuff disabled by default.
> 

Right, I'm sure those two cases are different. I just wanted to illustrate 
that there are quite a few aspects to think of before excluding / including 
an extension in a default build. There are definitely considerable number of 
people out there who will easily be bothered by that change.
If you doubt it is safely disabled, please look through the relevant part of 
mbstring, and if you still have questions, please ask me then.

> the theory of mbstring is good; i am just concerned that a: it really hasn't
> been explained and discussed much on list, and b: there are two development
> trees, which just doesn't make sense.
> 
> it's like some kind of underground secret society or something...

I agree with you on these points. You may well consider me as a member of 
underground kong-foo coder syndicate, though I'm Japanese and not good at 
any marshal art stuff :)

Moriyoshi



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

RE: [PHP-DEV] mbstring and 4.3.0

[James Cox]

>
> >
> > Historically, I have been against mbstring being enabled by default.
> > My feelings towards anything being enabled by default, unless it is
> > considered core functionality, is pretty negative though.
>
> The reasoning to consider a extension as a part of core, is prone
> to be obscure. It's interesting what would happen if mysql
> extension turned
> out to be harmful.
>

but the mysql extension isn't invasive of other parts of the language, and
can be safely disabled. I do not believe mbstring can be safely disabled,
and i do not think that you have the transparent stuff disabled by default.

the theory of mbstring is good; i am just concerned that a: it really hasn't
been explained and discussed much on list, and b: there are two development
trees, which just doesn't make sense.

it's like some kind of underground secret society or something...

 -- james


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

[PHP-DEV] [PATCH] Fix for bug #19566

[Moriyoshi Koizumi]

Hi,

The attached patch is a probable fix for bug #19566. I guess the bug 
is that va_list is not properly initialized before each callback function 
call. I've tested it in PPC linux, and it works fine.

Regards,
Moriyoshi


Index: zend_hash.c
===
RCS file: /repository/Zend/zend_hash.c,v
retrieving revision 1.87
diff -u -r1.87 zend_hash.c
--- zend_hash.c 17 Aug 2002 16:06:50 -  1.87
+++ zend_hash.c 8 Nov 2002 08:46:34 -
@@ -724,9 +724,9 @@
 
HASH_PROTECT_RECURSION(ht);
 
-   va_start(args, num_args);
p = ht->pListHead;
while (p != NULL) {
+   va_start(args, num_args);
hash_key.arKey = p->arKey;
hash_key.nKeyLength = p->nKeyLength;
hash_key.h = p->h;
@@ -735,8 +735,8 @@
} else {
p = p->pListNext;
}
+   va_end(args);
}
-   va_end(args);
 
HASH_UNPROTECT_RECURSION(ht);
 }

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