Re: [PHP-DEV] Question for Zeev, Zak or Georg - mysql_query and possible integer overflow?

[Zak Greant]

D'oh - read too little, too fast. :)

On Tue, Mar 25, 2003 at 05:55:42PM -0800, Zeev Suraski wrote:
> I believe he meant the query id's that the engine uses, and not the auto 
> increment id's.  Wez's response was accurate, we'll overflow at some 
> point.  This is basically because PHP was designed with short requests in 
> mind.  We could probably fix it relatively easily for ZE2.

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

Re: [PHP-DEV] Question for Zeev, Zak or Georg - mysql_query and possible integer overflow?

[Zak Greant]

On Tue, Mar 25, 2003 at 01:50:17PM +, Matt Flaherty wrote:
> Hi,
> 
> I have a question for the authors of the mysql extension. I'm sure you
> gentlemen are very busy, but I'd appreciate your insight if you can
> spare a moment. I'm developing a stand-alone php application running in
> an infinite loop from the command line interface. A mysql database is
> polled continually for new rows to deal with. The same query is executed
> several times in one second. I've noticed that whether or not a query
> resource is freed the next query identifier returned from mysql_query()
> is ++ the last one. I'm sure this is by design and governed by the mysql
> driver. Naturally I'm concerned about integer overflow when the the
> application has been running uninterrupted for a very long time. I don't
> think I can wait around while a test script runs to see what happens
> after 4,294,967,295 is exceeded though! Can anyone tell me with
> certainty or hazard a guess what might happen here? I thank you very
> much for your time.

  The query that generates an auto_increment value larger than the largest
  value allowed for the column will fail with error 1062 (Duplicate
  entry 'xxx' for key 1)

> Matt
> 
> ps - I'm doing this through PEAR::DB::mysql

  I am not exactly sure how PEAR::DB will propagate this error through
  its error handling interface.

  An easy way to test this is to create a temporary table that has a
  TINYINT as its auto_incrementing primary key, fill the table up and
  then watch to see what breaks.
  
  Cheers!
  --zak

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

Re: [PHP-DEV] Proto void and return values...

[Zak Greant]

On Tue, 2002-11-12 at 20:25, David Brown wrote:
> On Tue, Nov 12, 2002 at 02:16:41PM -0500, David Brown wrote:
> | Hi everyone:
> | 
> | For functions prototyped as returning void, return values seem to be applied
> | at random. Some functions, such as trigger_error/user_error, srand, ob_start,
> | and phpinfo, use RETURN_TRUE. The vast majority of these functions just fall
> | through, implicitly returning NULL to userland.
> 
> Or perhaps I'v just thought about this entirely too long. Is it possible
> that the prototypes are just wrong in the documentation?

  Bingo! :) (or at least, that is my belief - I might be wrong :)

  --zak


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

Re: [PHP-DEV] PUT method support

[Zak Greant]

On Tue, 2002-11-12 at 14:14, Hartmut Holzgraefe wrote:
> 
> looks like this was a PHP3 only feature?
> 
> http://www.php.net/manual/sv/printwn/features.file-upload.put-method.php

  Yes - this never made it out of PHP 3.

  --zak


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

Re: [PHP-DEV] #20374 [NEW]: Performance enhancment forphp_mysql_do_connect. (fwd)

[Zak Greant]

On Tue, 2002-11-12 at 00:47, Rasmus Lerdorf wrote:
> Seems like a good idea to me.  Any volunteers?  Zak?

  Working on it right now. :)

  Cheers!
  --zak


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

[PHP-DEV] Embedded libmysql update

[Zak Greant]

Hello All,

Upgrading the embedded libmysql is taking me far too long. I have asked
for the core MySQL devs to take care of it.

A rather tired and frustrated,
--zak




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

Re: [PHP-DEV] PHP's vision

[Zak Greant]

On Mon, 2002-06-03 at 09:39, Sebastian Bergmann wrote:
> Jani Taskinen wrote:
> > Currently, the bundled mysql is not been updated. (it's 3.23.39)
> > Latest stable release is 3.23.49, AFAIK.
> 
>   I am told that Monty will see to it that Zak gets it updated before the
>   next release :-)

  Yep. I started work on it again on the plane to Germany. I am using a
  script to handle the work so that it will be easier and faster in the
  future.
 
  --zak


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

[PHP-DEV] Re: Bug #16768: mysql_connect("localhost", ...) doesn't connect tolocalhost! (fwd)

[Zak Greant]

On Wed, 2002-04-24 at 08:29, Derick Rethans wrote:
> Hey Zak,
> 
> I think this is a nice thing for 4.2.1. I can reproduce it. I hope 
> somebody can investigate this before friday (RC1 of 4.2.1 is scheduled 
> then).

  Thanks for the heads up!

  I return from San Jose on the 25th - I will look at this on the 26th

  --zak


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

Re: [PHP-DEV] Resume of my problem

[Zak Greant]

On March 25, 2002 01:50, Alexandre Soares wrote:
> HI,
> 
> I have a functino write in c, like as:
>
> void addvalue ( int a, int b, int *c )
> {
>   *c = a + b;
> }
>
>in php
>
> 
>   phpinclude ("alexlib");
>   addvalue ( 1, 2, c );
>   print ( "Value c = $c ");
>
> ?>
>
> what the procedure to make this ?

  Dear Alexandre,

  A better forum for your question is the php-general mailing list.

  This list is for discussing the development *of* PHP.

  --zak

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

Re: [PHP-DEV] mysql_tablename

[Zak Greant]

On March 25, 2002 00:04, Manuzhai wrote:
> It might be nice to make an alias called mysql_table_name for this, then
> deprecate mysql_tablename, for the sake of consistency. What about that?

  Good point! Interestingly, mysql_tablename() is an alias for mysql_result().

  However, your suggestion would make things more consistent - it will
  be added to the CVS version of PHP in a few minutes.

  --zak

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

Re: [PHP-DEV] [PATCH] Better fix for PHP Safe Mode FilesystemCircumvention Problem

[Zak Greant]

On Thu, 2002-02-28 at 07:22, Andi Gutmans wrote:
> At 05:03 AM 2/28/2002 -0700, Zak Greant wrote:
> >Hi Jason,
> >
> >Did this actually work? I wrote almost the same code on my own and
> >tested it, only to find that nothing changed. I walked through the code,
> >but did not spot a point where the CLIENT_LOCAL_FILES is actually used
> >other than:
> >
> >% grep -rn CLIENT_LOCAL_FILES *
> >ext/mysql/libmysql/libmysql.c:53:#define CLIENT_CAPABILITIES ...
> >ext/mysql/libmysql/mysql_com.h:73:#define CLIENT_LOCAL_FILES128  ...
> >
> >I have not yet looked further than this.
> >
> >Monty cooked up a patch just before he went on vacation, but the patch
> >is for a *way* newer version of libmysql and is not even remotely
> >compatible.
> >
> >We (errr.. the PHP we that is) may wish to consider updating the
> >embedded libmysql.
> 
> You (as in MySQL AB) were supposed to keep it up-to-date. Tim used to do it 
> but I think he has left. Please ask Monty about it :)

  Heh. Spank me Andi! ;)

  We will get it updated asap - maybe it can slip in for 4.2.0? :)


-- 
   __  ___ ___   __
  /  |/  /_ __/ __/ __ \/ /Zak Greant <[EMAIL PROTECTED]>   
 / /|_/ / // /\ \/ /_/ / /__   MySQL AB,  Advocate
/_/  /_/\_, /___/\___\_\___/   Calgary, Canada 
   <___/   www.mysql.com   403.244.7213


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

Re: [PHP-DEV] [PATCH] Better fix for PHP Safe Mode FilesystemCircumvention Problem

[Zak Greant]

Hi Jason,

Did this actually work? I wrote almost the same code on my own and
tested it, only to find that nothing changed. I walked through the code,
but did not spot a point where the CLIENT_LOCAL_FILES is actually used
other than:

% grep -rn CLIENT_LOCAL_FILES *
ext/mysql/libmysql/libmysql.c:53:#define CLIENT_CAPABILITIES ...
ext/mysql/libmysql/mysql_com.h:73:#define CLIENT_LOCAL_FILES128  ...

I have not yet looked further than this.

Monty cooked up a patch just before he went on vacation, but the patch
is for a *way* newer version of libmysql and is not even remotely
compatible.

We (errr.. the PHP we that is) may wish to consider updating the
embedded libmysql.

--zak

On Wed, 2002-02-27 at 09:59, Jason Greene wrote:
> This simple patch resolves this issue in a clean way, without
> introducing complex sql pre-processing code that introduces mutex
> problems.
> 
> The only issue is that it requires a modification to libmysql.c, which
> provided that everyone here agrees with this fix, then I will post it to
> [EMAIL PROTECTED] to get there reaction.
> 
> -Jason
> 
> 

> Index: ext/mysql/config.m4
> ===
> RCS file: /repository/php4/ext/mysql/config.m4,v
> retrieving revision 1.38
> diff -u -r1.38 config.m4
> --- ext/mysql/config.m4   30 Nov 2001 18:59:45 -  1.38
> +++ ext/mysql/config.m4   27 Feb 2002 16:51:33 -
> @@ -41,6 +41,9 @@
>  
>  if test "$PHP_MYSQL" != "no"; then
>AC_DEFINE(HAVE_MYSQL, 1, [Whether you have MySQL])
> +  if test "$PHP_SAFE_MODE" = "yes"; then
> + AC_DEFINE(DISALLOW_MYSQL_LOAD_LOCAL, 1, [Whether to disable load local])
> +  fi
>PHP_EXTENSION(mysql,$ext_shared)
>  fi
>  
> Index: ext/mysql/libmysql/libmysql.c
> ===
> RCS file: /repository/php4/ext/mysql/libmysql/libmysql.c,v
> retrieving revision 1.9
> diff -u -r1.9 libmysql.c
> --- ext/mysql/libmysql/libmysql.c 6 Nov 2001 16:59:07 -   1.9
> +++ ext/mysql/libmysql/libmysql.c 27 Feb 2002 16:51:33 -
> @@ -50,7 +50,11 @@
>  uint mysql_port=0;
>  my_stringmysql_unix_port=0;
>  
> +#ifndef DISALLOW_MYSQL_LOAD_LOCAL
>  #define CLIENT_CAPABILITIES  (CLIENT_LONG_PASSWORD | CLIENT_LONG_FLAG | 
>CLIENT_LOCAL_FILES | CLIENT_TRANSACTIONS)
> +#else 
> +#define CLIENT_CAPABILITIES  (CLIENT_LONG_PASSWORD | CLIENT_LONG_FLAG | 
>CLIENT_TRANSACTIONS) 
> +#endif 
>  
>  #ifdef __WIN__
>  #define CONNECT_TIMEOUT 20
> 
> ----
> 

> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
-- 
   __  ___ ___   __
  /  |/  /_ __/ __/ __ \/ /Zak Greant <[EMAIL PROTECTED]>   
 / /|_/ / // /\ \/ /_/ / /__   MySQL AB,  Advocate
/_/  /_/\_, /___/\___\_\___/   Calgary, Canada 
   <___/   www.mysql.com   403.244.7213


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

[PHP-DEV] Re: [PHP-QA] Re: 4.2.0 & CLI

[Zak Greant]

On Wed, 2002-02-27 at 20:23, Yasuo Ohgaki wrote:
> Jim Winstead wrote:
> > In php.dev Edin Kadribasic <[EMAIL PROTECTED]> wrote:
> > 
> >>1. If you compile CGI binary and then issue 'make install' it will be
> >>installed in $PREFIX/bin, then CLI will be put in the same place overwriting
> >>it. Any suggestions on what to do in this situation?
> >>
> > 
> > imho, the cgi binary should get called php.cgi.
> > 
> > jim
> > 
> 
> Sound nice to me.
> +1

  Good idea!  How about php-cgi instead so that some wacky sysadmin does
  not think that it is a cgi script and drop it into a cgi-bin
  directory? :)

  Also, is using the cli build of PHP going to break any old scripts?

  --zak




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

[PHP-DEV] Re: [PHP-QA] PHP 4.2.0 release process

[Zak Greant]

On Wed, 2002-02-27 at 11:31, Derick Rethans wrote:
> Hello folks,
> 
> after some overenthausiastic actions of me today I'd like to do it the
> formal way now. I think it's a good idea to start working on a PHP 4.2.0
> release now. Some interesting additions were added, the file upload code
> was rewriten and probably a lot more. I propose to branch to PHP_4_2_0 at
> next Wednesday March 6th. This should give most of you enough time to get
> your new code in. After that the QA team should gather the critical bugs
> and evaluate if they should be fixed before the 4.2.0 release. After this
> is evaluated it's time for the first RC, after which we can work at
> getting all those nasty little bugs out before we release.
> 
> In a few minutes I'll write another mail to QA with things that should be
> tested a lot, I believe Zak has some notes about that too.

  Yup. Anyone want to volunteer to give me a hand on detailing all of
  the various issues - I am setting this upcoming weekend to work on
  it.

-- 
   __  ___ ___   __
  /  |/  /_ __/ __/ __ \/ /Zak Greant <[EMAIL PROTECTED]>   
 / /|_/ / // /\ \/ /_/ / /__   MySQL AB,  Advocate
/_/  /_/\_, /___/\___\_\___/   Calgary, Canada 
   <___/   www.mysql.com   403.244.7213


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

Re: [PHP-DEV] PHP Safe Mode Filesystem Circumvention Problem -tested

[Zak Greant]

On Wed, 2002-02-27 at 05:40, [EMAIL PROTECTED] wrote:
> Hello,
> 
> I think it's a bad idea to patch extension for flaws not in PHP itself.
> Furthermore, this adds a performance loss to every query. Did you do any
> benchmarks with it? Anyway... I still think it's a bad idea, and from what
> I've heard Zak is talking with MySQL about this.

  +1 This is not a PHP problem. We (the PHP we, that is :) can't go
  around patching PHP for every client lib that we support. That would
  be hell to deal with for the developers.

  We (the MySQL we, that is :) will have a patch shortly. Additionally,
  an upcoming release of MySQL will feature an additional permission to
  control this case.

-- 
   __  ___ ___ ____  __
  /  |/  /_ __/ __/ __ \/ /Zak Greant <[EMAIL PROTECTED]>   
 / /|_/ / // /\ \/ /_/ / /__   MySQL AB,  Advocate
/_/  /_/\_, /___/\___\_\___/   Calgary, Canada 
   <___/   www.mysql.com   403.244.7213


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

[PHP-DEV] zak@php.net address mail forward change

[Zak Greant]

Hello All,

Could someone with the needed karma please point my [EMAIL PROTECTED] address
to my [EMAIL PROTECTED] address? Thanks!

-- 
   __  ___ ___   __
  /  |/  /_ __/ __/ __ \/ /Zak Greant <[EMAIL PROTECTED]>   
 / /|_/ / // /\ \/ /_/ / /__   MySQL AB 
/_/  /_/\_, /___/\___\_\___/   Calgary, Canada 
   <___/   www.mysql.com


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

Re: [PHP-DEV] Re: ZE repositories

[Zak Greant]

Zeev wrote:
...
> It should be noted that I believe it'll be better for the manual to lose 
> the ugly license it's under and move to the openbook license, than the 
> other way around.  But I've already done my share of license wars in my 
> life - if you want to talk to New Riders, go ahead.

  I will talk to Stephanie Wall at New Riders about this.

-- 
For technical support contracts, goto https://order.mysql.com/
   __  ___ ___   __
  /  |/  /_ __/ __/ __ \/ /Zak Greant <[EMAIL PROTECTED]>   
 / /|_/ / // /\ \/ /_/ / /__   MySQL AB
/_/  /_/\_, /___/\___\_\___/   Calgary, Canada 
   <___/   www.mysql.com


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

Re: [PHP-DEV] PHP Safe Mode Filesystem Circumvention Problem (fwd)

[Zak Greant]

On Mon, 2002-02-04 at 22:23, James E. Flemer wrote:
> Comments on this? I am going to take a look at the code in
> the mysql extension, and at the code in mysql as well
> tomorrow. Not sure if this is directly a PHP problem (vs a
> mysql problem), but it is something that PHP *could* block
> it seems.

  IIAR, this is not really a weakness, merely a configuration issues.
  Wou can deny MySQL users access to the file based functions very 
  easily.

  REVOKE FILE ON db TO user...

  Will do a bit more research to ensure that this is truly bogus.

  --zak

-- 
For technical support contracts, goto https://order.mysql.com/
   __  ___ ___   __
  /  |/  /_ __/ __/ __ \/ /Zak Greant <[EMAIL PROTECTED]>   
 / /|_/ / // /\ \/ /_/ / /__   MySQL AB
/_/  /_/\_, /___/\___\_\___/   Calgary, Canada 
   <___/   www.mysql.com


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

[PHP-DEV] Re: [Zend Engine 2] Heredoc-Syntax

[Zak Greant]

On Wed, 2002-01-30 at 04:04, [EMAIL PROTECTED] wrote:
> On Wed, 30 Jan 2002, Yasuo Ohgaki wrote:
> 
> > > therefore i wrote 'on its own line'. i suppose heredoc is handled by
> > > the scanner, so this should not be a problem.
> 
> It's handled by the scanner indeed
> 
> > >
> > > yohgaki: you were talking about reasons and mentioned only one that
> > > isn't a reason for me. any other reasons ?
> >
> > As I mentioned, feel free to write and submit patch :)
> >
> > PS: You are better to search archive, there were discussion
> > regarding heredoc patch. It's not directly related to
> > this change, but it may help. The last patch was rejected,
> > IIRC.
> 
> It's fairly easy to patch, the question is if we want it. Andi, what's
> your statement on this? I don't see why the heredoc label should be on the
> first column anyways.

  I talked to [EMAIL PROTECTED] about this quite some time ago. IIRC, we
  agreed that <<- heredoc syntax was an acceptable way to handle this.
  The <<- syntax would work like the same way as <<- in bash.

  Of course, I never got around to implementing it... :)


-- 
For technical support contracts, goto https://order.mysql.com/
   __  ___ ___   __
  /  |/  /_ __/ __/ __ \/ /Zak Greant <[EMAIL PROTECTED]>   
 / /|_/ / // /\ \/ /_/ / /__   MySQL AB
/_/  /_/\_, /___/\___\_\___/   Calgary, Canada 
   <___/   www.mysql.com


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] TML++

[Zak Greant]

On Sun, 2002-01-27 at 22:16, Joey Smith wrote:
> On Saturday, Jan. 26th, at 11:36am MST my son, Joseph Clark Smith,
> Jr. was born. He is 19.5" in length and 7 lbs. 5 oz.
> 
> More pictures later, but here's on to start with:
> http://www.joeysmith.com/~joey/jj.jpg


Many congratulations to you and your partner, Joey!! :)

--zak


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Taking a short break.

[Zak Greant]

Hey All,

I need to take a couple of weeks off to avert financial distaster/get some 
contracts finished up/get ready for a new job. See you next month. :)

(Note: If there is anything that needs my attention, feel free to mail me 
directly! I will be around... :)

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: migrating PHPs across machines...

[Zak Greant]

On 2002-12-01 05:14, Abhimanyu_Bhola wrote:
> Thanks a lot.
>
> # but I dont think I need to do this if I dont switch my DB server !!!
>
> and,
>
> # what to do regarding the php.ini file? Do I have to manually transfer
> all the settings by examining the old and new ones or how to go about it?

  Hi Abi,

  While Manuel was kind enough to answer you, this question is best suited 
  to the PHP database or general mailing list. The Dev list is (usually) 
  for discussing issues related to building PHP instead of building with 
  PHP.

  --zak

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: migrating PHPs across machines...

[Zak Greant]

On 2002-12-01 09:23, Manuel Lemos wrote:

  [cut]

> His follow messages just confirm what I said.

  I find intolerance in both sides of the argument.

> >   But Derick *does* spend time helping me.* :) I still think that with
> > just a teeny bit of restraint on both sides, this would not happen.
>
> I was kidding, but since you took it seriously, just by going to
> http://bugs.php.net/search.php I can see that there 920 outstand bug
> reports to be addressed. How come anybody can think that "repressing
> Manuel" is a better way to spend time than fixing all those bugs? I
> looks like Derick wants to show off and exhibit his official @php.net
> badge and act like a PHP mailing lists "watchdog". Never mind, lets let
> him figure that he'd better have a life of his own instead of bothering
> to step on others' feet.

  Manuel, Derick spends a fabulous amount of time on improving PHP. I 
  very much respect his effort and generally quiet, determined demeanor.

  He is not showing off his status. He is venting frustration that many
  in the community feel. Many of the long and loud threads on this list
  over the last little while have been pointless fights... 

  You defend yourself so vigorously and take offense so quickly that 
  people have trouble relating to you.

[cut]

> It was not intended, but now you have to face the justice or Mr. Net cop
> Derick.

  Actually I don't - in fact, I don't recall ever having been troubled by
  those who disagree with you.  I am probably the least adept of the people
  actively involved with the development effort and I make a lot of mistakes
  and foolish suggestions, yet no one troubles me... 

> Just to relax, you know that 4 years ago I wrote a book named something
> that would be translated as  "Being on the Internet". I have one chapter
> that talks about typical behaviours that the Internet make outstand in
> users. One of the described behaviours is what I called the "Net Cop".
> It is that guy that thinks of himself of a big shot that knows all and
> is going to fix the world by repressing others. Derick just reminded me
> of a Net Cop. Anyway, I tend to understand people like him, because as I
> explained in the book, usually people just repress others because they
> are or at least were repressed by others in the past. Despite they hated
> it, they just do the same and repress others with shouting at them with
> public messages to try to humilliate them, just like Derick tried. Never
> mind, nothing that some good analysis sessions would not solve! :-)

  Manuel, you are very intelligent and have the benefit of being older than 
  many of us on the list - why can't you identify your own behavior in the 
  bad things that you attribute to others? 

  I believe that you are a net cop. Derick certainly is not - I somewhat am
  -- just by the virtue of not being able to leave other people's 
  discussions well enough alone. :)  Anyone remember when I was *stupid*
  enough to try and moderate the last big fight between Zeev and Sascha?

> Anyway, talking about books, and to not completely waste this thread I
> have just skimmed your book, PHP Functions Essential Reference. I must
> congratulate you and your co-authors for the book. It is a very good
> approach to make turn a reference manual into a much more useful PHP
> programming hand book.

  Thank you! We worked hard on providing cookbook-style examples 
  to match the reference material.

> I am sorry I could not yet find time to publish a review in the PHP
> Classes site because I have been very busy with things that gave me a
> lot of work like completely removing the uses of strtok function from
> the site code because PHP developers broke it after version 4.0.6 and I
> could not avoid the upgrade to use the APC cache to speedup the site
> service.

  This is an example of the negative behavior that we discuseed. Everyone
  know that you have issues with this. Each time that you bring it up 
  without adding any constructive input with it, it makes people angry.

  If I found what I considered to be a flaw in Metabase, and 
  continually hounded you on the "problem" without offering any compromise 
  or assistance, you would likely not find me very good company.

> I probably only have time to review your book in February because I am
> still very busy with a new release of Metabase to be out on its second
> anniversary since its first public release that will happen on the 18th.
> There are a few inovating features that I want release but I have to
> work a lot to make it happen in time. Then I need to get back to MetaL
> developement that will also have its first public release soon,
> hopefully some time next month. But don't worry I will make a nice
> review of your 

Re: [PHP-DEV] Re: migrating PHPs across machines...

[Zak Greant]

On 2002-12-01 05:41, Manuel Lemos wrote:
> Zak Greant wrote:
> > On 2002-12-01 05:24, Manuel Lemos wrote:
> > > Hello,
> > >
> > > [EMAIL PROTECTED] wrote:
> > > > [insert other shameless plugs here]
> > >
> > > What is the matter with you? Why this hostility again? Does the truth
> > > bothers you?
> > >
> > > Are you going to start yet another "repress Manuel because we don't
> > > want him to help PHP users" thread?
> > >
> > > Get a grip! I wish new guys like you that just got @php.net stop
> > > acting as if you it got over your head and you think you are a big
> > > shot because of that and you the right to act this arrogant.
> > >
> > > What? You did not like my response? That's to make you think again
> > > next time before you decide to get me started with your repressing
> > > arrogance.
> > >
> > > :-(
> >
> >   Chill Manuel! If your responses to the smallest slight were less
> >   overblown/entertaining, people would taunt you *much* less often.
>
> I don't think there is an excuse for Derick sistematic arrogance. Still,
> that is just my opinion.

  I feel that you have read too much into too little. However, this is only 
  my opinion as well. :)

> I wish the Dericks of this this list would better spend their time
> helping that Zaks instead of just annoying the Manuels because they
> hardcoded in their minds that "repressing the Manuels" is a much better
> thing to do! :-)

  But Derick *does* spend time helping me.* :) I still think that with just 
  a teeny bit of restraint on both sides, this would not happen.

> >   Also, user level questions should stay on the general or db list.
>
> Yes, sorry, my mistake, I didn't quite notice the list this was going
> to, I just followed-up the original post.

  :) No worries - I have done the same many times.


  * As have *many* people on this list - even you. :)

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: migrating PHPs across machines...

[Zak Greant]

On 2002-12-01 05:24, Manuel Lemos wrote:
> Hello,
>
> [EMAIL PROTECTED] wrote:
> > [insert other shameless plugs here]
>
> What is the matter with you? Why this hostility again? Does the truth
> bothers you?
>
> Are you going to start yet another "repress Manuel because we don't want
> him to help PHP users" thread?
>
> Get a grip! I wish new guys like you that just got @php.net stop acting
> as if you it got over your head and you think you are a big shot because
> of that and you the right to act this arrogant.
>
> What? You did not like my response? That's to make you think again next
> time before you decide to get me started with your repressing arrogance.
>
> :-(

  Chill Manuel! If your responses to the smallest slight were less 
  overblown/entertaining, people would taunt you *much* less often.

  Also, user level questions should stay on the general or db list.

  --zak

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] consistent way to handle structs

[Zak Greant]

On 2002-11-01 04:51, Andi Gutmans wrote:
> On Fri, 11 Jan 2002, Markus Fischer wrote:
> > What other way do we have to specify arbitray optional
> > parameters without an ordering? Teh disadvantage of optional
> > parmeters is when you need to only set the last one, you'll
> > have to define all preceding optional parameters too.
>
> How does the MySQL C API handle this?
 
  The function that connects to MySQL accepts *many* arguments. :)

  Also, a separate function allows options to be set for a connection
  before it is made.

  The general process is:

  /* Get a connection handle */
  connection_handle = mysql_init ();  

  /* Set options */
  mysql_options (connection_handle, flag, arg_for_flag);

  /* Now connect to MySQL */
  mysql_real_connect (
connection_handle,
host,
user,
password,
db_name,
port,
socket,
flags
  );


  I am digging through the MySQL extension to try and figure out how
  to implement mysql_options without having to do it like the C api.

  Needless to say, I am learning more C than I ever planned to, :)

> I think using array() is pretty sucky. Look at the following example and
> I'm sure you're planning on it getting much worse.
> mysql_connect("foo", array("bar" => 1, "hello" => 2));

  I don't think it is *that* terrible. It seems better than having a billion
  args to a function - :). I suppose that people can always write wrappers 
  for this sort of case though. PEAR handles this well. IMHO :)

> > For functions like mysql_connect() the performance impact is
> > negligible (methinks).
>
> I don't think it'll always be negligible.
> It might not always be a bad idea but I think that if we support this
> easy to use function we're going to see this kind of stuff pop-up in more
> places than the very few places which just can't do without.

  You are right, that could get nasty. If PEAR becomes more tightly 
  integrated with PHP proper, then we really would not need to worry about 
  this.  If someone wants easy, they use the PEAR DB class. If they want 
  fast (or verbose ;) then they can use the extension.


-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: Behaviour of $array1 + $array2

[Zak Greant]

On 2002-10-01 21:28, Markus Fischer wrote:
> On Thu, Jan 10, 2002 at 05:58:28PM -0700, Zak Greant wrote :
[cut]
> >   Also, there have been discussions on Dev about this issue before.
> >   Might be a bit tough to find though. :)
>
> Hmm .. well, at least, it should be clearly documented.

  I agree!  I just wanted to make sure that you knew that this had been
  covered once before -- there might be some useful information in the 
  archives.

--zak

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: Behaviour of $array1 + $array2

[Zak Greant]

On 2002-10-01 17:33, Yasuo Ohgaki wrote:
> Markus Fischer wrote:
> > Can someone point me where the following behaviour is documented:
> >
> > $ php -q
> >  > $foo = array(27 => 'Ene');
> > $bar = array(-1 => 'Mene');
> >
> > $baz = $foo + $bar;
> >
> > var_dump($baz);
> > ?>
> > array(2) {
> >   [27]=>
> >   string(3) "Ene"
> >   [-1]=>
> >   string(4) "Mene"
> > }
> >
> > cheers
> >
> > - Markus
>
> I guess it's not.
>
> There is note explains this behavior. Accoding to the note,
> "PHP Developer's Cookbook claims (p. 87 and sort of on p. 108)
> that '+' is syntactic sugar for array_merge."

  Also, there have been discussions on Dev about this issue before.
  Might be a bit tough to find though. :)

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] E_NOTICE

[Zak Greant]

On 2002-10-01 07:49, [EMAIL PROTECTED] wrote:
> On Thu, 10 Jan 2002, Zak Greant wrote:
> > On 2002-10-01 07:38, Derick Rethans wrote:
> > > Hello,
> > >
> > > can somebody clarify why a E_NOTICE prints 'Warning' and
> > > E_USER_NOTICE prints 'Notice'. IMO it is more clear to print 'Notice'
> > > in both cases.
> >
> >   It probably has something to do with maintaining backwards
> > compatibility. Could we set a php.ini flag to control this behavior? ;>
> >
> :) Anyway, it doesn't make sense to me. IMO it should just show 'Notice'
> for both cases.

  Agreed. Having anything else is just confusing.

--zak

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] E_NOTICE

[Zak Greant]

On 2002-10-01 07:38, Derick Rethans wrote:
> Hello,
>
> can somebody clarify why a E_NOTICE prints 'Warning' and E_USER_NOTICE
> prints 'Notice'. IMO it is more clear to print 'Notice' in both cases.

  It probably has something to do with maintaining backwards compatibility.
  Could we set a php.ini flag to control this behavior? ;>

  /me grins, dodges, runs and hides...

--zak

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #14938 Updated: No htmlescape() function for PHP4

[Zak Greant]

On 2002-8-01 17:36, [EMAIL PROTECTED] wrote:
> ID: 14938
> Updated by: philip
> Reported By: [EMAIL PROTECTED]
> Old Status: Closed
> Status: Duplicate
> Bug Type: Documentation problem
> Operating System: Linux
> PHP Version: 4.1.1
> Assigned To: imajes
> New Comment:
>
> Be sure to discuss this with Zak, see bug #14418 which stemmed from this
> htmlescape() doc bug, not sure where he's at on it.  I'm sure he
> wouldn't mind if you did a commit though :)

  I need to get off my lazy ass and fix it. :)

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension

[Zak Greant]

On 2002-3-01 15:43, Joao Prado Maia wrote:
> So ? I didn't see any C code from Zak either. If all we are doing right
> now is speculating on the creation of a PHP based 'prototype' of this
> MySQL-only abstraction thing, why is it more interesting than a existing
> package like PEAR::DB ?
>
> Talk is just that - talk. The weird part is that Zak probably know about
> PEAR::DB and he might even know about Stig's plan on writing a C port of
> a stable version of it. Maybe I'm wrong, but I just don't feel very good
> about all this duplication of efforts and even more about a abstraction
> class _just_ for MySQL.

  I do know about PEAR::DB - I looked at the IDEAS file to see what was
  planned.  I probably should have reviewed the PEAR DEV list, but - hey -
  I can't read every PHP list.

  I respect the work that the PEAR team has done.  Please don't make an
  issue of something that we do not need to worry about yet.

  I will keep writing my code.  When I have something useable, I will 
  present it to whoever is interested.  It can be integrated into PEAR or
  PHP or nothing -- whatever works best for the users.

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension

[Zak Greant]

On 2002-3-01 06:44, [EMAIL PROTECTED] wrote:
> ** Reply to note from Markus Fischer <[EMAIL PROTECTED]> Thu, 3
> Jan 2002 15:18:16 +0100
>
> > On Thu, Jan 03, 2002 at 02:06:23PM +, Phil Driscoll wrote :
> > > Sounds good to me except for the OO wrappers.
> > >
> > > Do we already have OO wrappers to anything else not in user land? -
> > > if so then I'm probably too late to make the point, but to me such a
> > > thing feels 'all wrong' and 'not php'. I'm particularly concerned
> > > that we don't create functionality which is only accessible by OO
> > > means.
> >
> > Why?
>
> Because not everyone wants to use *(#$&ing objects in a simple script!

  No one will be forced to use the wrapper! :)

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension

[Zak Greant]

On 2002-3-01 11:29, Andi Gutmans wrote:
> Zak,
>
> You will probably be better off waiting for the ZE2's new object
> overloading facilities. It will hopefully be easier to write and will
> allow you to do some things which you can't do today.
> If you write it for ZE1 your extension's API might look different than if
> you had written it for ZE2 due to some existing limitations, changing it
> later on for ZE2 would then cause a BC problem.

  Hi Andi,

  Thanks for the warning! I am partially doing this for practice/fun - as 
  long as we keep the extension away from PEAR/PHP it can be updated to ZE2
  when the time comes without breaking BC. :)

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension

[Zak Greant]

On 2002-3-01 07:06, Phil Driscoll wrote:
> Sounds good to me except for the OO wrappers.
>
> Do we already have OO wrappers to anything else not in user land? - if so
> then I'm probably too late to make the point, but to me such a thing
> feels 'all wrong' and 'not php'. I'm particularly concerned that we don't
> create functionality which is only accessible by OO means.

  I know that you don't like OO Phil. :) I also dislike (most) OO for many 
  applications.  I believe that during this stage, OO is the easiest way to
  rough this idea out. I will be more than happy to look at a proceedural 
  interface later on.

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension

[Zak Greant]

On 2002-3-01 07:32, Joao Prado Maia wrote:
[cut]
> My personal opinion is that the OOP layer idea is pretty bad. Instead of
> having 7 or 8 set of functions to learn, now the newbie will have 8 set
> of functions / APIs. The idea might sound very sexy and everything, but
> the real problem is that there is already _some_ talks in PEAR-DEV about
> trying to create a unified API for all databases (a new one, not
> PEAR::DB) which would be eventually be ported to C.
>
> I really don't feel very good with yet another database abstraction
> package, and this time just for MySQL. I say database abstraction not in
> the sense that it will abstract everything, but that it gives a thin
> layer of abstraction to the underlying database.
>
> In any case, I _really_ hope you will talk with Stig and get to know more
> about the latest discussions (flame-wars?) in PEAR-DEV about the upcoming
> re-write of PEAR::DB and also about the intention of re-writing it in C
> once it is stable.

  Hi Joao,

  Thanks for the feedback! I understand your objections, but do not agree 
  with all of them.

  I am not competing with the PEAR project. I am talking about proposed
  functionality and have avoided discussions of whether it should be a
  part of PHP, PEAR/PECL or neither.

  There is significant work to be done before this would be integrated with
  anything.

  No one will be forced to use the wrapper.

  I am currently focusing on MySQL rather than on all databases.  
  Developing this for a single database reduces the design overhead.

  The average new user will not need to learn multiple APIs.  Initially, 
  they will choose an API that works for them and then learn the bare 
  minimum needed to use it.

  I am glad that others are discussing similar ideas and would be happy to
  discuss or collaborate.

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension

[Zak Greant]

On 2002-3-01 03:39, Lukas Smith wrote:
> Well PHP and MySQL are a very popular combo .. but I do not see a point
> in "separating" the API's even further ... DB API's are a major concern
> for myself right now too
>
> It would be really nice to work more in the direction of unifying all of
> the API's on a "C level"
>
> Other than that there is nothing against doing that change .. but I
> think it would only make sense to do it across the board

  I plan to keep my focus on this very small to avoid distraction. :)

  I am currently working on a PHP based implementation that uses Andrei's 
  overload extension.  Once I this is somewhat stable and users have had a 
  chance to work with it, I plan to implement it in C.

  --zak

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension

[Zak Greant]

On 2002-3-01 02:43, Alexander Merz wrote:
> > Create an OO-based wrapper for the MySQL extension. The wrapper would
> > provide the user with access to all of a database's information without
>
> Yeah, lets re-invent PEAR:DB :)
>
> Such things are already on the ToDo list for PEAR::DB.
  
  What makes you think that this could not be a part of PEAR::DB? ;)

--zak

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension

[Zak Greant]

On 2002-3-01 02:01, Markus Fischer wrote:
> On Thu, Jan 03, 2002 at 01:19:03AM -0700, Zak Greant wrote :
> > The major benefits of the wrapper would be:
> >   - Small and simple API. The number of functions would drop from 41 to
> >  around 12.
>
> But you know you just can't remove the existing functions.

  Of course not!! :)  The OO wrapper would not replace the current 
  extension.

--zak

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Proposed updates and extensions to the MySQL extension

[Zak Greant]

Hello All,

Monty has a series of proposed changes and updates to the MySQL extension
(along with a few ideas of mine that we have discussed) that I would like to
present to the dev list for feedback and review.

Synopsis of Proposed Changes

Update the PHP built-in MySQL library to support MySQL 4.0.1


Extend mysql_connect()/mysql_pconnect() to allow the optional selection 
of a default database, a MySQL config file and a group within the selected
config file.

The default database parameter will allow the default database to be
selected at connection time, instead of requiring a separate call.

The other parameters will allow the connection to use the client connect 
options set in the config file (such as passwords, connection timeouts, 
etc.) This will allow passwords to be stored outside of the PHP script.


Allow persistent connections to be closed and 'pruned'. Possible ways to
implement this include adding mysql_pclose(), which would close a 
persistent connection and remove it from the connection cache.

...or add a function that flags persistent connections as removeable. Calls
to mysql_close() made on a flagged connection would close it and remove it
from the connection cache. i.e. mysql_trim_pconnections (); An optional
argument could allow the connections to be pruned down to a certain number.


Create an OO-based wrapper for the MySQL extension. The wrapper would 
provide the user with access to all of a database's information without 
requiring explicit queries or functions calls to retrieve the data. The 
user would not need to call call mysql_db_name, mysql_field_*, 
mysql_list_fields, etc. The wrapper would also encompass the rest of the 
MySQL extension's functionality.

The major benefits of the wrapper would be:
  - Small and simple API. The number of functions would drop from 41 to
 around 12.
  - Full information on the server, databases, tables and fields could
easily be viewed with one call to var_dump()
  - Connection handles, etc. would all be managed by the object
  - Error messages, last insert id, etc. would be stored as object 
properties.

The library would work something like the following:
   // Connect to MySQL and select database
   $mysql = new oo_mysql ('localhost', 'user', 'password', 'db');

   // Accessing the tables property triggers a SHOW TABLES query
   var_dump ($mysql->tables);

Notes: The wrapper would not retrieve the information until the 
corresponding property was requested. This will keep the size of the object 
down.

As always, feedback is welcome! :)


Thanks!

--zak

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #14782 Updated: key_exists renamed to array_key_exists

[Zak Greant]

Well said. :) Well enough that the developer who made the change has 
asked to have an alias added. Attached is the required patch.

The alias should appear in the next maintenence release of PHP.

--zak

On 2002-2-01 09:10, [EMAIL PROTECTED] wrote:
> ID: 14782
> User updated by: [EMAIL PROTECTED]
> Reported By: [EMAIL PROTECTED]
> Status: Closed
> Bug Type: Feature/Change Request
> Operating System: all
> PHP Version: 4.1.1
> Old Assigned To: zak
> Assigned To:
> New Comment:
>
> I understand the issue or having functions disappear and then reappear..
>

[cut]


Index: ext/standard/basic_functions.c
===
RCS file: /repository/php4/ext/standard/basic_functions.c,v
retrieving revision 1.433
retrieving revision 1.434
diff -u -r1.433 -r1.434
--- ext/standard/basic_functions.c	30 Dec 2001 09:36:24 -	1.433
+++ ext/standard/basic_functions.c	2 Jan 2002 21:21:48 -	1.434
@@ -17,7 +17,7 @@
+--+
  */
 
-/* $Id: basic_functions.c,v 1.433 2001/12/30 09:36:24 zak Exp $ */
+/* $Id: basic_functions.c,v 1.434 2002/01/02 21:21:48 zak Exp $ */
 
 #include "php.h"
 #include "php_main.h"
@@ -789,6 +789,7 @@
 	/* aliases from array.c */
 	PHP_FALIAS(pos, current,  first_arg_force_ref)
 	PHP_FALIAS(sizeof, count, 	NULL)
+	PHP_FALIAS(key_exists,			array_key_exists,		NULL)
 
 	/* functions from assert.c */
 	PHP_FE(assert,			NULL)


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Moving extensions to PECL

[Zak Greant]

On 2001-31-12 11:38, Jon Parise wrote:
> I think the following "standard" extensions should be moved to
> PECL:
>
> ext/cybercash
> ext/icap
> ext/pfpro
> ext/yaz
>
> This is definitely not an inclusive list; it's just a start.  I
> can't imagine a lot of people using these modules, so they seem
> like good candidates for removal from the base PHP distribution.
>
> Are there any well-founded objections to this (either in practice
> or principle)?

  We should probably add cybermut to the list as well.

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] [IMPORTANT] wishes for php ...

[Zak Greant]

On 2001-30-12 05:53, Gabor Hojtsy wrote:
> > Ah, and btw, that's what we've the documentation team for, no?
>
> Well, no php-dev people is engaged to know DocBook XML, the
> doc building process, or translation related things. No phpdoc people
> engaged to know C, some know very few C, or have no experience
> with C at all.
>
> I have seen a note in the php-weekly sometime ago from Rasmus,
> bringing the fact to attention, that all people who have write Karma
> to the "php4" module, have write Karma to the "phpdoc" module. This
> needs to be for something :) Maybe just to give a possibility for a
> dream to come true :) IMHO only a few poeple have
> write Karma to "php4" from "phpdoc". I do not say, that to document
> any extension or function, we need write Karma. This only shows, that
> the majority of documentation people are not involved in development.
>
> I took part in Sterlings whole day workshop and Zak's intro to the
> PHP source session at the php conference. I cannot say I understand
> what's in the C code know, but I have a better understanding. Using
> that knowledge, I was able to write documentation for things like
> ini_file(),
> and some functions like this. As you know, to understand the PHP C
> source, knowing C is not enough. One even need to know the Zend
> API. For the Zend API, we have a somewhat oudated documentation,
> from the early days, when the PHP 4 version was not even released.
  [...]

  There is a wiki to support my talk from the PHP I18N Conference that 
  is located at http://fooassociates.com/rtfs

  It contains the complete text (more *and* less :) of my presentation.

  The PHPDoc team may find it handy. Also, if you ask questions on the
  Wiki about particular aspects of the source, I will do my best to 
  answer them (or find someone who can).

  --zak

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /main rfc1867.c

[Zak Greant]

On December 25, 2001 04:34 pm, Yasuo Ohgaki wrote:
> Sterling Hughes wrote:
> >>>Sterling: Thursday, December 13, 2001 7:19 PM
> >>>
> >>>Please provide a more descriptive note about what you changed
> >>> and what was wrong.  Also, it would be great if you could add
> >>> some test cases, which show what the problem was, and how your
> >>> fixes made the problem go away.
> >>
> >>Next time i will follow your advise. I did not want to write
> >> redundant comments.
> >>Array uploads did not work because php_register_variable truncates
> >> [*] from the variable name and therefore had to be moved a few
> >> lines down. I marked that as comment in the patch. And one cannot
> >> really write test cases for the bugs
> >>i fixed without writing something that send malformed/untypical
> >> POST headers.
> >
> > Hrrm, yeah, I'm thinking that the test suite should contain a
> > simple webserver which we can run PHP with (as a CGI even), it
> > would make the test suite more robust as there are a lot of
> > features that rely on the presence of a webserver...  (we might
> > also provide an FTP server, that doesn't need to run PHP, just to
> > test certain request based services..)
> >
> > -Sterling
>
> This is one of feature for test suite that we should have ;)
>
> We may be better to use Apache, since web server is complex
> enough to develop from scratch.
> Since Apache is configurable as user want, how about include
> configure line for test suite and httpd.conf?

  What about something like thttpd instead? Small (120k) enough to
  include in the testing suite and a bit less daunting to customize. :)

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] NULLs & the PHP testing framework

[Zak Greant]

It looks like the current testing framework can not properly handle 
NUL. I have not tracked down the problem yet, but suspect that it 
occurs around line 549 when data is being read from a popen stream and 
written to the temp output file.  For Un*x systems, could we use use a 
system call and redirect the output to a file? I think that would let 
us handle the NULs successfully???

Just a thought before I head off to sleep. :)

G'night!

--zak

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: Bug #14613: Implement Function/Feature Conformity Tests

[Zak Greant]

On December 20, 2001 02:09 am, Yasuo Ohgaki wrote:
> Great, Zak!!
>
> I was hoping someone start this.
>
> I really hope there is a BNF. Simplied one is preferred,
> it helps to understand what zend expects. (Well I can read
> lex(flex)/yacc(bison) source, but I'm just lazy enough to
> understand BNF from them. I guess many programmers are
> as lazy as me ;)

  I don't think that I will be trying to do a BNF! :)
  For now, I only hope to tackle what I had outlined in my feature
  request.

  --zak

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] New Dev Weekly Summary

[Zak Greant]

Hello All,

If you have not been able to follow the list over the last week, I hope 
that this summary help you catch up! Note that the summary is quite 
high-level and leaves out a lot of the unresolved activity on the list, 
as well as skipping over threads that have a lot of conflict, but no 
real, errr..., value. (IMHO :)

Also, before I send this off to Zend for posting on the site, does 
anyone have any corrections or additions (coughDerickcoughAndreicough) 
? :)

---

FIX: Bug Database Cleanup
In celebration of the release of PHP 4.1.0, a group of people 
(including Yasuo Ohgaki, Sander Roobol, Markus Fisher, Derick Rethans, 
Jani Taskinen and other) have been working on clearing out the old bugs 
in the bug database. Nice work guys!


FIX: mcrypt Extension
Derick Rethans has corrected a series of bugs in PHP's mcrypt 
extension. The corrections should appear in the next release of PHP. 
The bugs corrected include bug 13399 and bug 14162. Visit 
http://bugs.php.et http://bugs.php.net/bug.php?id=13399 and 
http://bugs.php.net/bug.php?id=14162 for details.


REQ: Documentation of Thread-Safe Functions
Emanuel Dejanu has requested that the functions that are Thread-Safe 
(aka safe to use with threaded web-servers, like IIS and Apache (under 
Windows)be listed as so in the documentation.  To keep an eye on how 
this request progresses, visit http://bugs.php.net/bug.php?id=14447


FIX: Long integer numbers in dBase
Vlad Krupin fixed a problem that was causing the dbase_get_record() and 
dbase_get_record_with_names() functions to only retrieve the first 10 
digits of integer fields. The functions can now retrieve all digits 
stored in integer fields. For more details, see 
http://bugs.php.net/bug.php?id=5993


NEW: Windows Binaries of 4.1.0 Released
Official Windows binaries of PHP 4.1.0 have been released and are 
available on http://[your favorite mirror].php.net/downloads.php. 
Please do use a local mirror to download the new binaries!


TLK: PostgreSQL Function Renamed
Yasuo Ohgaki has renamed the functions in the Postgres extension so 
that they conform to the PHP function naming conventions. The old 
function names are still available and scripts using the old names 
should continue to work as expected. The changes to the function names 
should appear in the next release of PHP after 4.1.0


FIX: Improved Error Handling for Sybase and MSSQL
Dave Brotherstone has submitted a patch that would handle "raiserror" 
type error thrown by the SQL server.
The patch needs to be reviewed and tested. To see how the patch fares, 
visit http://marc.theaimsgroup.com/?t=10080795062&r=1&w=2


FIX: Better Spam Protection for the PHP Mailing Lists
A new method of spam protection has been implemented for the PHP 
mailing lists. The spam protection works by only allowing messages from 
known email addresses to be posted to the list. Unknown users can 
easily become known users with a simple email-based registration 
process. The registration process is triggered by simply sending a 
message to a PHP mailing list. If you encounter problems posting to a 
PHP mailing list, you can contact the list administrators at 
[EMAIL PROTECTED]


TLK: Improved Error Reporting for PHP
Yasuo Ohgaki has suggested that the PHP developers improve the 
consistency of how PHP reports errors, ensuring that similar types of 
problems return similar and appropriate error messages. To follow this 
discussion, visit 
http://marc.theaimsgroup.com/?t=10081440185&r=1&w=2


TLK: Improving the PHP Test Suite
Sterling Hughes has suggested that the PHP test suite be expanded to 
include a set of simple servers like a web server and FTP server. The 
presence of these servers would allow the test suite to test features 
that the current testing framework cannot handle. To follow this 
discussion, go to 
http://marc.theaimsgroup.com/?t=10082758939&r=1&w=2


NEW: Experimental and Powerful Object-Oriented Functionality
Andrei Zmievski has cooked up an extension called 'overload' that 
allows for powerful overloading and extension of objects. The extension 
allows developers to control how the object responds to method 
invocations and how the object handles the assignment and retrieval of 
properties.  If you wish to test the overload extension, you will need 
to download a current snapshot of PHP - visit http://snaps.php.net/  
The ext/overload directory in the PHP source tree contains a simple 
usage example. Additionally Stig Sather Bakken has used the extension 
to implement an autoloader - see the Autoloader.php file in the PEAR 
directory to check it out.




-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Upcoming Weekly Dev Summary

[Zak Greant]

Hello All,

I am going to start working on the Zend Weekly Dev summary shortly.

If there is anything interesting, noteworthy or cool that has happened 
in the last week that you would like mentioned in the weekly summary, 
drop me a note to tell me about it. While I catch most of what happens 
on the dev list, I seem to miss a couple of things every week.* :)

Also, if there is anything that you would like to make the QA aware 
of, drop me a line and I will include it in the version of the summary 
that I post to the QA list.

Note, I might not include everything that is sent to me - if I don't 
think the content is appropriate, it will not go in.


* Yes, Andre. I will include a short writeup on the overload extension. 
:)

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Karma Request

[Zak Greant]

Hello Karma Granters,

Could I get karma to be able to commit to the PHP source? I have a 
bunch of minor maintenance tasks, like correcting prototypes, 
correcting outdated return values, adding additional regression tests, 
etc., that I would like to perform.

I have attached the first patch for review. Feedback and guidance are 
welcome! :)

--zak

Index: array.c
===
RCS file: /repository/php4/ext/standard/array.c,v
retrieving revision 1.148
diff -u -r1.148 array.c
--- array.c	11 Dec 2001 15:30:27 -	1.148
+++ array.c	13 Dec 2001 09:18:21 -
@@ -179,59 +179,45 @@
 	return array_key_compare(a, b TSRMLS_CC) * -1;
 }
 
-/* {{{ proto int krsort(array array_arg [, int sort_flags])
-   Sort an array reverse by key */
+/* {{{ proto bool krsort(array array_arg [, int sort_flags])
+   Sort an array by key value in reverse order */
 PHP_FUNCTION(krsort)
 {
-	zval **array, **sort_type;
-	int sort_type_val = SORT_REGULAR;
+	zval *array;
+	long sort_type = SORT_REGULAR;
 	HashTable *target_hash;
 
-	if (ZEND_NUM_ARGS() < 1 || ZEND_NUM_ARGS() > 2 ||
-		zend_get_parameters_ex(ZEND_NUM_ARGS(), &array, &sort_type) == FAILURE) {
-		WRONG_PARAM_COUNT;
-	}
-	target_hash = HASH_OF(*array);
-	if (!target_hash) {
-		php_error(E_WARNING, "Wrong datatype in krsort() call");
-		return;
-	}
-	if (ZEND_NUM_ARGS() == 2) {
-		convert_to_long_ex(sort_type);
-		sort_type_val = Z_LVAL_PP(sort_type);
+	if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "a|l", &array, &sort_type) == FAILURE) {
+		RETURN_FALSE;
 	}
-	set_compare_func(sort_type_val TSRMLS_CC);
+	
+	target_hash = HASH_OF(array);
+	set_compare_func(sort_type TSRMLS_CC);
+	
 	if (zend_hash_sort(target_hash, zend_qsort, array_reverse_key_compare, 0 TSRMLS_CC) == FAILURE) {
-		return;
+		RETURN_FALSE;
 	}
 	RETURN_TRUE;
 }
 /* }}} */
 
-/* {{{ proto int ksort(array array_arg [, int sort_flags])
+/* {{{ proto bool ksort(array array_arg [, int sort_flags])
Sort an array by key */
 PHP_FUNCTION(ksort)
 {
-	zval **array, **sort_type;
-	int sort_type_val = SORT_REGULAR;
+	zval *array;
+	long sort_type = SORT_REGULAR;
 	HashTable *target_hash;
 
-	if (ZEND_NUM_ARGS() < 1 || ZEND_NUM_ARGS() > 2 ||
-		zend_get_parameters_ex(ZEND_NUM_ARGS(), &array, &sort_type) == FAILURE) {
-		WRONG_PARAM_COUNT;
-	}
-	target_hash = HASH_OF(*array);
-	if (!target_hash) {
-		php_error(E_WARNING, "Wrong datatype in ksort() call");
-		return;
-	}
-	if (ZEND_NUM_ARGS() == 2) {
-		convert_to_long_ex(sort_type);
-		sort_type_val = Z_LVAL_PP(sort_type);
+	if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "a|l", &array, &sort_type) == FAILURE) {
+		RETURN_FALSE;
 	}
-	set_compare_func(sort_type_val TSRMLS_CC);
+
+	target_hash = HASH_OF(array);
+	set_compare_func(sort_type TSRMLS_CC);
+	
 	if (zend_hash_sort(target_hash, zend_qsort, array_key_compare, 0 TSRMLS_CC) == FAILURE) {
-		return;
+		RETURN_FALSE;
 	}
 	RETURN_TRUE;
 }
@@ -402,57 +388,43 @@
 /* }}} */
 
 
-/* {{{ proto void asort(array array_arg [, int sort_flags])
+/* {{{ proto bool asort(array array_arg [, int sort_flags])
Sort an array and maintain index association */
 PHP_FUNCTION(asort)
 {
-	zval **array, **sort_type;
-	int sort_type_val = SORT_REGULAR;
+	zval *array;
+	long sort_type = SORT_REGULAR;
 	HashTable *target_hash;
 
-	if (ZEND_NUM_ARGS() < 1 || ZEND_NUM_ARGS() > 2 ||
-		zend_get_parameters_ex(ZEND_NUM_ARGS(), &array, &sort_type) == FAILURE) {
-		WRONG_PARAM_COUNT;
-	}
-	target_hash = HASH_OF(*array);
-	if (!target_hash) {
-		php_error(E_WARNING, "Wrong datatype in asort() call");
-		return;
-	}
-	if (ZEND_NUM_ARGS() == 2) {
-		convert_to_long_ex(sort_type);
-		sort_type_val = Z_LVAL_PP(sort_type);
+	if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "a|l", &array, &sort_type) == FAILURE) {
+		RETURN_FALSE;
 	}
-	set_compare_func(sort_type_val TSRMLS_CC);
+	
+	target_hash = HASH_OF(array);
+	set_compare_func(sort_type TSRMLS_CC);
+	
 	if (zend_hash_sort(target_hash, zend_qsort, array_data_compare, 0 TSRMLS_CC) == FAILURE) {
-		return;
+		RETURN_FALSE;
 	}
 	RETURN_TRUE;
 }
 /* }}} */
 
-/* {{{ proto void arsort(array array_arg [, int sort_flags])
+/* {{{ proto bool arsort(array array_arg [, int sort_flags])
Sort an array in reverse order and maintain index association */
 PHP_FUNCTION(arsort)
 {
-	zval **array, **sort_type;
-	int sort_type_val = SORT_REGULAR;
+	zval *array;
+	long sort_type = SORT_REGULAR;
 	HashTable *target_hash;
 
-	if (ZEND_NUM_ARGS() < 1 || ZEND_NUM_ARGS() > 2 ||
-		zend_get_parameters_ex(ZEND_NUM_ARGS(), &array, &sort_type) == FAILURE) {
-		WRONG_PARAM_COUNT;
-	}
-	target_hash = HASH_OF(*array);
-	if (!target_hash) {
-		php_error(E_WARNING, "Wrong datatype in arsort() call");
+	if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "a|l", &array, &sort_type) == FAILURE) {
 		RETURN_FALSE;
 	}
-	if (ZEND_NUM_ARGS() == 2) {
-		convert_to_long_ex(sort_type);
-		sort_type_val = Z_LVAL_PP(sort_type);
-	}
-	set_compare_func(sort_type_

Re: [PHP-DEV] [patch] krsort() ext/standard/array.c

[Zak Greant]

On December 12, 2001 07:33 am, Andrei Zmievski wrote:
> On Wed, 12 Dec 2001, Sterling Hughes wrote:
> > And those functions would be? :) Are you talking about
> > regularly used functions such as strlen(), etc.?
>
> Functions like count(), for example, that people tend to use in a
> loop unnecessarily.
>
> > I agree that zend_basic_functions.c should remain abstracted, I
> > guess where we draw the line is a bit fuzzy to me?  What are
> > your thoughts as to what functions should remain
> > un-zend-parse-parameterized (say *that* 10 times fast :).
>
> Yes, the distinction is not clear. Perhaps, the person who does the
> conversion for each module could do some benchmark tests on their
> programs and see what might need to be adjusted.

I did a simple test with krsort before and after zend_parse_parameters.

See the attached files for information on the changes that I made and 
the test that I used. In this case, it looks like we face at most about 
a 0.0001 second penalty per function call for using 
zend_parse_parameters. This is based on the data below: (4.762 seconds 
- 3.704 seconds) / 1 calls to krsort)

Profiling would probably be a better choice, however, I am having a few 
troubles getting profiling going with the PHP source. :) 

As always, correction and comments welcome.

---

With zend_parse_parameters():

real0m4.762s
user0m4.710s
sys 0m0.030s
 
real0m4.738s
user0m4.700s
sys 0m0.030s
 
real0m4.726s
user0m4.700s
sys 0m0.020s

Without zend_parse_parameters(): 

real0m3.704s
user0m3.620s
sys 0m0.040s
 
real0m3.833s
user0m3.660s
sys 0m0.020s
 
real0m3.764s
user0m3.650s
sys 0m0.010s


-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

 $v) {
$array[$v] = $k;
}

define (MAX, 1);

for ($x=0; $x < MAX; ++$x) {
$data = $array;
krsort ($data);
}
?>


Index: ext/standard/array.c
===
RCS file: /repository/php4/ext/standard/array.c,v
retrieving revision 1.148
diff -u -r1.148 array.c
--- ext/standard/array.c	11 Dec 2001 15:30:27 -	1.148
+++ ext/standard/array.c	13 Dec 2001 07:19:29 -
@@ -179,39 +179,34 @@
 	return array_key_compare(a, b TSRMLS_CC) * -1;
 }
 
-/* {{{ proto int krsort(array array_arg [, int sort_flags])
-   Sort an array reverse by key */
+/* {{{ proto bool krsort(array array_arg [, int sort_flags])
+   Sort an array by key value in reverse order */
 PHP_FUNCTION(krsort)
 {
-	zval **array, **sort_type;
-	int sort_type_val = SORT_REGULAR;
+	zval *array;
+	long sort_type_val = SORT_REGULAR;
 	HashTable *target_hash;
 
-	if (ZEND_NUM_ARGS() < 1 || ZEND_NUM_ARGS() > 2 ||
-		zend_get_parameters_ex(ZEND_NUM_ARGS(), &array, &sort_type) == FAILURE) {
-		WRONG_PARAM_COUNT;
-	}
-	target_hash = HASH_OF(*array);
-	if (!target_hash) {
-		php_error(E_WARNING, "Wrong datatype in krsort() call");
-		return;
-	}
-	if (ZEND_NUM_ARGS() == 2) {
-		convert_to_long_ex(sort_type);
-		sort_type_val = Z_LVAL_PP(sort_type);
+	if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "a|l", &array, &sort_type_val) == FAILURE) {
+		RETURN_FALSE;
 	}
+	
+	target_hash = HASH_OF(array);
 	set_compare_func(sort_type_val TSRMLS_CC);
+	
 	if (zend_hash_sort(target_hash, zend_qsort, array_reverse_key_compare, 0 TSRMLS_CC) == FAILURE) {
-		return;
+		RETURN_FALSE;
 	}
+	
 	RETURN_TRUE;
 }
 /* }}} */


CODING_STANDARDS
CREDITS
CVS
ChangeLog
ChangeLog.1999.gz
ChangeLog.2000.gz
EXTENSIONS
INSTALL
LICENSE
Makefile
Makefile.in
NEWS
README.CVS-RULES
README.EXTENSIONS
README.EXT_SKEL
README.PARAMETER_PARSING_API
README.QNX
README.SELF-CONTAINED-EXTENSIONS
README.STREAMS
README.Zeus
RELEASE_PROCESS
TODO
TODO-4.2.txt
TSRM
Zend
acconfig.h
acconfig.h.in
acinclude.m4
aclocal.m4
apidoc-zend.txt
apidoc.txt
build
buildconf
buildmk.stamp
config.guess
config.log
config.nice
config.status
config.sub
config_vars.mk
configure
configure.in
cvsclean
dynlib.m4
ext
footer
generated_lists
genfiles
header
install-sh
libphp4.la
libs
libtool
ltmain.sh
main
makedist
makerpm
missing
mkinstalldirs
modules
pear
php.ini-dist
php.ini-recommended
php4.gif
php4.spec
php4.spec.in
php_version.h
regex
run-tests.php
sapi
scripts
snapshot
stamp-h.in
stub.c
stub.lo
stub.o
tests
win32


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] [patch] krsort() ext/standard/array.c

[Zak Greant]

On December 12, 2001 03:54 am, Sterling Hughes wrote:
[...]
> Sure, commit it... But please don't send a patch for every proto
> change, we'll yell out you fine if you commit something bad... ;)

  C'mon - the list needs the extra traffic to appear active. :)
  To commit to the source code, I will need extra karma.

>   Btw, yes, if you wouldn't mind zend_parse_parameters() conversion
>   would be great, its probably a little trickier than protos, but,
>   its what we want all the source to be using in X
>   years/months/days/minutes/seconds.

  I will start doing this (taking into account Andrei's constraints)

  Also, is there a good source of documentation on 
  zend_parse_parameters(), or should I run throught the dev messages
  and create some.


--zak

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #13933 Updated: error_log and HTTP redirect using header conflict

[Zak Greant]

On December 12, 2001 02:51 am, [EMAIL PROTECTED] wrote:
> ID: 13933
> Updated by: yohgaki
> Reported By: [EMAIL PROTECTED]
> Status: Open
> Bug Type: Output Control
> Operating System: Windows NT4 SP6
> PHP Version: 4.0.6
> Assigned To: zak
> New Comment:
>
> Zak,  is this bug analyzed?
> I'm trying to sort out output buffering problems.
> Thanks.

  Nope - not yet, go ahead and take it if you like. :)

  --zak

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] [patch] krsort() ext/standard/array.c

[Zak Greant]

  Also, when touching up functions, is there any significant advantage 
  to migrating them to zend_parse_parameters? 

On December 11, 2001 06:53 pm, I wrote:
> Hello All,
>
> After reviewing Christian Dickmann's list of functions with broken
> prototypes, I have started making corrections where needed.

[...]

--zak


-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] [patch] krsort() ext/standard/array.c

[Zak Greant]

Hello All,

After reviewing Christian Dickmann's list of functions with broken 
prototypes, I have started making corrections where needed.

Given that I am not sure that everyone will agree that these changes 
are needed (or that I will make the changes properly FTM), I am 
starting slowly. :)

The attached patch corrects the proto, improves the proto description 
and makes the function return FALSE when it encounters an error.

Feedback is welcome!

I realize that someone more skilled could do this work about 20x 
faster. However, I would like to tackle small tasks like this to get 
more familiar with the source. :)

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

Index: ext/standard/array.c
===
RCS file: /repository/php4/ext/standard/array.c,v
retrieving revision 1.148
diff -u -r1.148 array.c
--- ext/standard/array.c	11 Dec 2001 15:30:27 -	1.148
+++ ext/standard/array.c	12 Dec 2001 01:44:22 -
@@ -179,8 +179,8 @@
 	return array_key_compare(a, b TSRMLS_CC) * -1;
 }
 
-/* {{{ proto int krsort(array array_arg [, int sort_flags])
-   Sort an array reverse by key */
+/* {{{ proto bool krsort(array array_arg [, int sort_flags])
+   Sort an array by key value in reverse order */
 PHP_FUNCTION(krsort)
 {
 	zval **array, **sort_type;
@@ -194,7 +194,7 @@
 	target_hash = HASH_OF(*array);
 	if (!target_hash) {
 		php_error(E_WARNING, "Wrong datatype in krsort() call");
-		return;
+		RETURN_FALSE
 	}
 	if (ZEND_NUM_ARGS() == 2) {
 		convert_to_long_ex(sort_type);
@@ -202,7 +202,7 @@
 	}
 	set_compare_func(sort_type_val TSRMLS_CC);
 	if (zend_hash_sort(target_hash, zend_qsort, array_reverse_key_compare, 0 TSRMLS_CC) == FAILURE) {
-		return;
+		RETURN_FALSE;
 	}
 	RETURN_TRUE;
 }


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: Bugs in ext/standard/array.c

[Zak Greant]

On December 10, 2001 03:09 pm, Christian Dickmann wrote:
> I programmed a small PHP Script, which
> searches for these "negligible inconsistency".
> It is very simple, but it shows some positions
> in the source, which should be changed ...
>
> Someone out there, who wants to do this?
>
> Here the URL:
> http://dickmann.dynip.de/phpbugs.php
> and
> http://dickmann.dynip.de/phpbugs.php?verbose=1
> (which displays the source of the found functions)

  Hi Christian,

  Thanks for the script! I will take a look at the output :)

--zak

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Orphan Bugs

[Zak Greant]

Hello All,

In working up the summary, I noticed that the following new bug reports 
had not yet been reviewed. Anyone have some time to kill? :)

http://bugs.php.net/bug.php?id=14245&edit=1
http://bugs.php.net/bug.php?id=14355&edit=1
http://bugs.php.net/bug.php?id=14369&edit=1
http://bugs.php.net/bug.php?id=14371&edit=1
http://bugs.php.net/bug.php?id=14379&edit=1
http://bugs.php.net/bug.php?id=14383&edit=1
http://bugs.php.net/bug.php?id=14385&edit=1
http://bugs.php.net/bug.php?id=14382&edit=1
http://bugs.php.net/bug.php?id=14376&edit=1
http://bugs.php.net/bug.php?id=14370&edit=1
http://bugs.php.net/bug.php?id=14358&edit=1
http://bugs.php.net/bug.php?id=14354&edit=1

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] xmlrpc extension in 4.1.0

[Zak Greant]

On December 10, 2001 03:42 pm, Colin Viebrock wrote:
> Any docs on using this extension?

  Hey Colin,

  There is an article on Zend -
  http://www.zend.com/zend/tut/tut-xml-rpc-client.php

  HTH,

  --zak

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Problem with complex data structure and sessions

[Zak Greant]

Probably the best thing to do is visit http://bugs.php.net and review 
the guidelines for submitting a bug.  If you get through the process 
and feel that you have found a bug, please submit a bug report.

--zak

On December 10, 2001 02:51 pm, Frank wrote:
> I am new to online PHP communities so if there is a better place to
> post this please let me know.
>
> I may have encountered a bug in PHP 4.0.6, but I don't know where to
> look to see if it is a known problem, and I have not been able to
> reproduce the problem in trivial code.
>
> I have been programming for a couple decades now, but just started
> with PHP a few months ago.  I've spent a couple months developing a
> fairly typical catalog / shopping cart / order system for a small web
> site.  My code works flawlessly on 4.0.8 under Windows XP (my
> development environment), but when I uploaded it to our host (4.0.6
> under FreeBSD) it failed in the following way:
>
> The Shopping cart (we call it a basket) object includes a two
> dimensional array of "item" objects indexed by catalog number and
> package size, and a second array of references to the same item
> objects.  Simplified a little, items are added like this:
>
> $this->items[$catalognum][$size] = new BasketItem($catalognum, $size,
> $quantity);
> $this->ref[] = &$this->items[$catalognum][$size];
>
> Somewhere in the serialize/store/load/unserialize process handled by
> the built in session support, $basket->ref[] comes to contain
> references to arrays rather than references to objects.  If I add an
> "echo $basket->ref[0]" line to a particular page it will print
> "Object" on the hit that creates the basket, and "Array" when I
> refresh the page.  Under 4.0.8/Windows it will print "Object" each
> time.
>
> This problem causes my code to fail with a "Call to a member function
> on a non-object" error.
>
> Where can I best look to see if this is a known problem?

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: HOW2 on making C++ extensions in 4.1.0 (and 4.0.6?)

[Zak Greant]

On December 4, 2001 08:43 am, l0t3k wrote:
> Lars,
> check out ext/satellite, and also the author's site. he has an
> upcoming framework for producing PHP extensions in C++
>
> Lars Knudsen <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>
> > Does anyone have some (WORKING!) howto's on using C++ in
> > extensions.  I've tried for a couple of days now, and it's starting
> > to bug me ;-) Why isn't there a C++ extension/demo in the package?
> >
> > - Lars Knudsen
> > Developer (well... having 2nd thoughts now ;-) )

Drop by http://www.twisd.de/technologie/apl.php The APL is a
PHP extension that is written in C++

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Function Request: csv_explode()

[Zak Greant]

On December 5, 2001 01:29 am, Stig S. Bakken wrote:
> Splitting a CSV string into an array could be done like this too:
>
> $fields = explode('","', trim($string, '"'));

Hey Stig,

I don't think that it is quite that simple. :) The sample code
will break for unquoted values and weird combos of quotes and 
commas inside quote-delimited strings.

--zak


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] CVS Account Maintenance Request

[Zak Greant]

Hello - could someone with the needed karma point my [EMAIL PROTECTED] email 
address to [EMAIL PROTECTED]  My ISP is having serious troubles with 
their mail server...

-- 
--zak

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #14282 Updated: wrong strtotime calculation with timezones -0100 and +0100

[Zak Greant]

On December 2, 2001 04:35 am, you wrote:
> ID: 14282
> Updated by: derick
> Reported By: [EMAIL PROTECTED]
> Status: Closed
> Bug Type: Date/time related
> Operating System: any
> PHP Version: 4.1.0
> New Comment:
>
> This was not fixed yet in CVS. It is now however.

Thanks for the catch - I misread your earlier commit to the same file
as having corrected this bug. :)

--zak

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #14298: PUT absent $PHP_PUT_FILENAME $PHP_UPLOADED_FILE_NAME

[Zak Greant]

On November 30, 2001 08:33 am, [EMAIL PROTECTED] wrote:
> From: [EMAIL PROTECTED]
> Operating system:
> PHP version:  4.0.6
> PHP Bug Type: HTTP related
> Bug description:  PUT absent $PHP_PUT_FILENAME   $PHP_UPLOADED_FILE_NAME
>
> Document:
>   features.file-upload.put-method.html
> SAYS:
>   The filename of this temporary file is in the
>   $PHP_PUT_FILENAME variable
> SAYS:
>   copy(
>   $PHP_UPLOADED_FILE_NAME,
>   $DOCUMENT_ROOT.$REQUEST_URI
>   );
>
> Neither works. What does?

I have spent some time digging around looking for the solution to this 
problem and need a bit of help.

I can find the code that handles PUT method uploads in PHP 3. However, I 
don't find any handler code in PHP 4 - nor do I see any variables that relate 
to PUT file uploads when I capture the content of $GLOBALS from the PUT 
handler script.

Anyone have any clue here - it looks like PUT support never got implemented 
for PHP 4 (or it was removed - however, I did not see a NEWS or CVS log entry 
that mentioned it...)

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.1.0RC4

[Zak Greant]

On December 1, 2001 10:23 am, Stig Venaas wrote:
> On Sat, Dec 01, 2001 at 09:55:19AM -0700, Zak Greant wrote:
> > On December 1, 2001 01:36 am, Stig Venaas wrote:
> > > Isn't there anyone on the QA team doing LDAP tests? I hope you agree
> > > that ldap_first/next_attribute() not working is bad. I'm doing some
> > > testing myself, but not systematic, so I didn't spot this until now.
> >
> > It doesn't look like it. I would imagine that many things are
> > not getting that thoroughly tested... :(
>
> Yes, I suppose so. I'm doing some LDAP tests once in a while, but
> not thoroughly.

I have some ideas on how we can start trying to ensure that
each extension gets love and attention during the QA process.

However, I don't want to start anything else until I get my current
QA tasks complete! :)


[...]
> > Anyone want to step up and test this?
>
> Of course I've tested this myself. It's now in the 4.0.7 branch, and
> should be in RC5. It would be reassuring if this and other LDAP things
> were tested by the QA team though. I'll try to do more LDAP testing
> myself with future releases.


        Thanks! Hopefully in a couple of months we can get the testing
of individual extensions into the QA process.

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.1.0RC4

[Zak Greant]

On December 1, 2001 01:36 am, Stig Venaas wrote:
> On Fri, Nov 30, 2001 at 10:25:14PM -0700, Zak Greant wrote:
> > On November 30, 2001 09:12 pm, Zeev Suraski wrote:
> > > http://www.php.net/~zeev/php-4.1.0RC4.tar.gz
> > >
> > > The plan is to release Monday, unless a real earth quaker is found...
> >
> > Builds and runs on SuSE 7.1 as CGI
> > See http://fooassociates.com/phpqa/index.php?ZakGreantBuilds4.1.0RC4
>
> Isn't there anyone on the QA team doing LDAP tests? I hope you agree
> that ldap_first/next_attribute() not working is bad. I'm doing some
> testing myself, but not systematic, so I didn't spot this until now.

It doesn't look like it. I would imagine that many things are
not getting that thoroughly tested... :(

> Here's a script that illustrates how they don't work:
>
> $ds=ldap_connect("158.38.60.76");
> ldap_bind($ds,"","");
> $sr=ldap_search($ds,"dc=uninett,dc=no", "objectclass=person",
> array("cn","mail")); $entry = ldap_first_entry($ds, $sr);
> echo ldap_first_attribute($ds, $entry, $ber);
> echo ldap_next_attribute($ds, $entry, $ber);
>
> If it works, you should get "cnmail" as output. As it is now, you
> will get an error that $ber is not a valid resource, since neither
> of the functions set $ber. This works with latest CVS and if you
> apply my latest ldap.c change to 4.1.0.

Anyone want to step up and test this?

-- 
--zak

"We must be the change we wish to see." - M. K. Ghandi


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] 4.1.0RC4

[Zak Greant]

On November 30, 2001 09:12 pm, Zeev Suraski wrote:
> http://www.php.net/~zeev/php-4.1.0RC4.tar.gz
>
> The plan is to release Monday, unless a real earth quaker is found...

Builds and runs on SuSE 7.1 as CGI
See http://fooassociates.com/phpqa/index.php?ZakGreantBuilds4.1.0RC4

-- 
--zak

"We must be the change we wish to see." - M. K. Ghandi

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

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

[Zak Greant]

On November 29, 2001 10:38 am, aidan peiser wrote:
> Learning PHP
> Coding in PHP
> Reading the PHP source
> Writing web pages with PHP

Good Day,

Thankfully, you do not need a CVS account for these purposes. Please review 
the notes at http://www.php.net/cvs-php.php

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] Re: File Uploads in the PHP 4.2.0

[Zak Greant]

On November 22, 2001 02:53 am, James Moore wrote:
[...]
> > Good point. Anyone else? : )
>
> WIndows users should have a debugger available to be able to provide
> a stack trace or somthing similar the thought of getting 20 people
> telling us There was an access violation in MVCSRT.dll at insturciotn
> 0xA9283CD9, the memory at 0x1 could not be read doesnt help
> at all. if we dont get enough people with these requirements we can
> just ask for people generally but people with access to a debugger
> (pref MSVC) should be first in line to test
>
> :))

Another good point. : )

Anyone know of any free debuggers?

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: File Uploads in the PHP 4.2.0

[Zak Greant]

On November 22, 2001 04:04 am, Jan Lehnardt wrote:
> Hi,
> On Thu, 22 Nov 2001 02:06:54 -0700
>
> Zak Greant <[EMAIL PROTECTED]> wrote:
> > Users running Linux-like operating systems should download the
> > snapshot
> > from snaps.php.net that is dated [???], and then build and install
> > >
>
> it.
>
> isn't php4-latest on snaps.php.net the most dated version ?

We might want to have users using the same version for testing rather 
than adding in extra variables by dealing with different versions.

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: File Uploads in the PHP 4.2.0

[Zak Greant]

On November 22, 2001 02:12 am, [EMAIL PROTECTED] wrote:
> Hello,
>
> I think we should add something that asks for testers with some more
> indepth knowlegde of C, per example:

Good point. Anyone else? : )

...

> We are seeking 20-30 testers to build and/or install the current
> development version of PHP and test all of their file upload scripts
> with the new version. Ideally, those testing will use PHP's file
> upload functionality on a regular basis (or use third-party scripts
> that do). It is also important that in case php/apache segfaults a
> good backtrace is created (on Unix like operating systems). Therefore
> it would be prefered if the tester/you knows how to do this. (Check
> this for spelling :)
...

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: File Uploads in the PHP 4.2.0

[Zak Greant]

On November 22, 2001 01:07 am, Derick Rethans wrote:
> On Wed, 21 Nov 2001, Zak Greant wrote:
> > I was trying to forget that anything had been changed with
> > file uploads. ; )
> >
> > I am all in favor of attempting to recruit additional help for
> > this.
> >
> > I would also like to try to assembling a collection of file upload
> > test scripts that the QA team can run with the RCs.
>
> Sounds fine, let's start to recruit these people then :) But as Jani
> said, maybe it's wise to let the testers create their own scripts
> too.

Alrightly then... here is the rough recruiting letter. Suggestions and 
improvements welcome.



From: The PHP Developer and Quality Assurance Teams 
<[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>

Subject: Testers needed for PHP's File Upload functionality

Significant changes have recently been made to PHP's HTTP file upload 
functionality. Before the changes are incorporated into a major 
release, the PHP Development team wishes to ensure that the changes 
receive thorough testing.

We are seeking 20=30 testers to build and/or install the current 
development version of PHP and test all of their file upload scripts 
with the new version. Ideally, those testing will use PHP's file upload 
functionality on a regular basis (or use third-party scripts that do).

These people should then report back to the PHP Quality Assurance team 
mailing list ([EMAIL PROTECTED]) if the scripts worked or failed. If 
the scripts failed, the tester should also report details about the 
failure.

Users running Linux-like operating systems should download the snapshot 
from snaps.php.net that is dated [???], and then build and install it. 
Instructions on building and installing the snapshot are included in 
the download.

Users running a Windows-family operating system can download a 
pre-compiled binary from http://...


Thank you,

The PHP Developer and Quality Assurance Teams


----

We should probably send the letter separately to all the PHP lists with 
high traffic. 

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] PHP 4.1.0 Final RC QA Status

[Zak Greant]

On November 21, 2001 06:55 am, Jani Taskinen wrote:
> I think we should be testing the pre-compiled binaries which will
> later on become the release for win32 platforms. As we have seen many
> times before, there have been build-problems in the release which
> were not caught by tests. Whoever builds it should build also RC
> builds.

I don't quite grok the last sentence... so I will interprete it as
being what I want to hear. ; )

I think that you just said this:

Whoever is responsible for building the distributed Windows
binary should also build each of the RCs and distribute them to
the QA team for testing.

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.1.0 Final RC QA Status

[Zak Greant]

PHP 4.1.0 Final RC QA Status


Over the last few days, 12 people have submitted 26 build reports for 
the latest RC. (Hopefully, I have not missed anyone. :)

A full listing of the reports can be viewed at:
http://fooassociates.com/phpqa/

--- Overview ---

There has been a good deal of testing on various flavours of Linux:

SuSE: 8 builds
Red Hat: 6 builds
Debian: 3 builds
Slackware: 1 build

Each of these used Apache or CGI

FreeBSD has also been built a few times using Apache and CGI


Rounding out the other OSs:

Mac OS X + Apache
Sun OS 5.8 + CGI
Win32 + Apache + ISAPI


--- Plan? ---

While we have had a good amount of testing for Un*x/Apache and Un*x/CGI 
builds of the RC, we have only had a few tests of other OSs and SAPIs.

I do not know that we have time this RC to try and find people to build 
with other SAPIs and OSs. However, I feel that we should try to get a 
bit more testing on the various Win platforms. 

Any comments?

--- Finally ---

Thanks to everyone who has taken the time to build the RC and submit a 
report via the mailing lists and/or the PHP QA Wiki!

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.1.0 Final RC

[Zak Greant]

** Successfull CGI Build **

SuSE 7.1
Linux linux 2.2.18 #1 Wed Jan 24 12:28:55 GMT 2001 i686 unknown

./configure \
--enable-force-cgi-redirect \
--enable-discard-path \
--disable-short-tags \
--enable-calendar \
--enable-ftp \
--with-postgres

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

Running tests in /usr/src/packages/SOURCES/php-4.1.0RC3//ext/crack/tests

[all 1 test(s) skipped]

Running tests in /usr/src/packages/SOURCES/php-4.1.0RC3//ext/ctype/tests

[all 2 test(s) skipped]

Running tests in /usr/src/packages/SOURCES/php-4.1.0RC3//ext/cybermut/tests
===
[all 1 test(s) skipped]

Running tests in /usr/src/packages/SOURCES/php-4.1.0RC3//ext/db/tests
=
[all 6 test(s) skipped]

Running tests in /usr/src/packages/SOURCES/php-4.1.0RC3//ext/dbplus/tests
=
[all 1 test(s) skipped]

Running tests in /usr/src/packages/SOURCES/php-4.1.0RC3//ext/dbx/tests
==
[all 8 test(s) skipped]

Running tests in /usr/src/packages/SOURCES/php-4.1.0RC3//ext/gmp/tests
==
[all 2 test(s) skipped]

Running tests in /usr/src/packages/SOURCES/php-4.1.0RC3//ext/iconv/tests

[all 1 test(s) skipped]

Running tests in /usr/src/packages/SOURCES/php-4.1.0RC3//ext/interbase/tests

[all 6 test(s) skipped]

Running tests in /usr/src/packages/SOURCES/php-4.1.0RC3//ext/mailparse/tests

[all 2 test(s) skipped]

Running tests in /usr/src/packages/SOURCES/php-4.1.0RC3//ext/mcrypt/tests
=
[all 1 test(s) skipped]

Running tests in /usr/src/packages/SOURCES/php-4.1.0RC3//ext/ncurses/tests
==
[all 1 test(s) skipped]

Running tests in /usr/src/packages/SOURCES/php-4.1.0RC3//ext/pcntl/tests

[all 1 test(s) skipped]

Running tests in /usr/src/packages/SOURCES/php-4.1.0RC3//ext/satellite/tests

[all 5 test(s) skipped]

Running tests in /usr/src/packages/SOURCES/php-4.1.0RC3//ext/session/tests
==
Session Object Serialization (001.phpt)  ... failed
session_unset() without any session (002.phpt)   ... failed
Session Object Deserialization (003.phpt)... failed
session_set_save_handler test (004.phpt) ... failed
Custom save handler, multiple session_start()s, complex data structu ... passed
References between variables in sessions ... passed

Running tests in /usr/src/packages/SOURCES/php-4.1.0RC3//ext/skeleton/tests
===
[all 1 test(s) skipped]

Running tests in /usr/src/packages/SOURCES/php-4.1.0RC3//ext/standard/tests/assert
==
assert() (assert.phpt)   ... failed

Running tests in /usr/src/packages/SOURCES/php-4.1.0RC3//ext/standard/tests/file

File type functions  ... passed

Running tests in 
/usr/src/packages/SOURCES/php-4.1.0RC3//ext/standard/tests/general_functions
=
sprintf() function   ... passed
quoted_printable_decode() function test  ... passed
levenshtein() function test  ... passed
fgetcsv() with tab delimited fields (BUG #8258)  ... passed
is_scalar() function test... passed

Running tests in /usr/src/packages/SOURCES/php-4.1.0RC3//ext/standard/tests/math

Simple math tests... pass

[PHP-DEV] Re: [PHP-QA] 4.1.0 Final RC

[Zak Greant]

** Successfull Build **

SuSE 7.1
Linux linux 2.2.18 #1 Wed Jan 24 12:28:55 GMT 2001 i686 unknown 

./configure \
--with-apxs=/usr/local/apache/bin/apxs \
--disable-short-tags \
--enable-calendar \
--enable-ftp \
--with-pgsql

All applications on server seem to work as expected.

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] php module calling php code

[Zak Greant]

On November 19, 2001 12:23 pm, colin mcdonald wrote:
> Hi,
>
> can anyone point me to some examples/documentation for any of the
> following:
>
> C code calling methods of an object defined in a user's php code. (I
> know you can call user's php functions, but can this be done?)

IIAGR, you should be able to find an example in call_user_func()

> OR
>
> How would I define a PHP Object in C that could be used in the php
> script as if it was defined in the php script.

    IIAGR, check out the dir functions

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #14112 Updated: sprintf_array()

[Zak Greant]

On November 19, 2001 05:04 am, Sterling Hughes wrote:
> > ID: 14112
> > Updated by: zak
> > Reported By: [EMAIL PROTECTED]
> > Status: Open
> > Bug Type: Feature/Change Request
> > Operating System: Linux
> > PHP Version: 4.1.0RC1
> > New Comment:
> >
> > I would guess that implementing it as a native PHP
> > function would be at least 2x as fast.
> >
> > I suppose the issue now is finding out if the core PHP
> > developers consider the function to have enough value to
> > add it.
> >
> > My personal, non-core developer, opinion is that I don't
> > like the idea of adding this function.
> >
> > Perhaps instead we could overload the current
> > implementations of printf and sprintf so that they can
> > accept a single-dimension array as the second parameter
> > (and in this case, final, parameter)?
>
> vsprintf and vprintf don't work for you?

~zing~ e... apparently, I don't read the NEWS file that
often. :)

I will go document these now...

--zak


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Additional ENV Vars with Apache 2.0.28 and PHP 4.1.0 RC2

[Zak Greant]

On November 17, 2001 12:13 am, Sebastian Bergmann wrote:
> Zak Greant wrote:
> > This is not the right forum for support questions - please use
> > PHP-General instead.
>
>   I think this is the right forum for this, since the Apache2Filter
> is still under development. AFAIK it currently does not export most
> of the common variables.

Erk. Missed the full subject line. My apologies - this probably 
is the right place. :)

    Thanks Sebastian!

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Additional ENV Vars with Apache 2.0.28 and PHP 4.1.0 RC2

[Zak Greant]

On November 16, 2001 11:02 pm, you wrote:
> Hi all,
>
> Doing some playing around with new stuff and I have a question.  How
> do I access variables like HTTP_USER_AGENT with the above
> combination?  Is it PHP or Apache that is hiding it from me?  I know
> some things changed in 4.1 but I thought this stuff would still be
> accessible.

This is not the right forum for support questions - please use PHP-
General instead.  

To briefly answer your question, there are configuration directives
that control how environment variables, post variables, get variables,
etc. are presented to the user.  Review the manual section on 
configuration for more information.

You can see where things are located using the phpinfo() function. :)

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

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

[Zak Greant]

On November 16, 2001 10:33 pm, Deepak Kumar Vasudevan wrote:
> Learning PHP

You won't need a cvs account to do this. A CVS account allows you work 
on the PHP documentation, PHP source code or PHP web site.

Please read the introductory page on CVS accounts again. :)

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] XSLT Extension and paths

[Zak Greant]

On November 16, 2001 06:16 am, Sebastian Bergmann wrote:
>   'lo there,
>
>   I have a test.php script in the same directoy under htdocs as both
> a test.xml and a test.xsl file.
>
>  $p = xslt_create();
> $res = xslt_process($p, 'test.xml','test.xsl');
> if(!$res) echo xslt_error($p);
> echo $res;
> xslt_free($p);
> ?>
>
>   On Windows, the XSLT extension tries to find the test.xml and
> test.xsl files not in the directory as test.php is in, but in the
> direcory where the php.exe is located.

How are you running PHP under Win - CGI, ISAPI, 
Apache Mod??

What does getcwd() output?

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #14062 Updated: Wrong filetype displayed

[Zak Greant]

Ack. I missed the second, modified code... definitely bogus.

--zak

On November 15, 2001 12:15 am, [EMAIL PROTECTED] wrote:
...
> Then it's not a bug. Filetype works from the current directory, not
> from the directory you used with opendir().
...


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP extension

[Zak Greant]

On November 14, 2001 05:07 am, Andrey Hristov wrote:
> There is a book from the people who make www.phpwizard.net. The price
> is from $30 to $40 depending on the bookstore you use(Amazon has
> lowest price). The other way is to get it in PDF. on #bookwarez
> channel on irc.nullus.net, you can find it.

The "PHP Developer's Cookbook" also has a good section on developing 
PHP extensions.

--zak


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] pow() showing odd long/float boundary case characteristics

[Zak Greant]

On November 13, 2001 06:13 am, Rasmus Lerdorf wrote:
> The pow() regression test is failing due to this strange
> characteristic:
[...]

I just grabbed the new test and ran it against the latest RC. 
The pow test still fail, but the simple math tests work. : )

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] read "include" part of a file, I have a script problem??

[Zak Greant]

On November 5, 2001 11:57 am, OntheAve wrote:
> Hi,
> I have my file: begin.inc, from which I want to include a part in my
> php page. I have included this part between the tags:
> ""  &
> "", but I can't have my loop working.
> Here is What I have written:
>
> $FileName = "begin.inc";
> $Content = file($FileName);
> $BeginIt = "";
> $EndIt = "";
>
> do {
>  if ($Key == $BeginIt) {
>  echo $Val;
>  } elseif  ($Key == $EndIt) {
>  Break;
>  }
> } while(list($Key,$Val) = each($Content) );
>
> What is wrong with my script?

It looks like you are missing a newline at the end of the $BeginIt and 
$EndIt strings. 

Also, the dev list is generally for discussing issues regarding the 
development of PHP -- for general PHP questions, please post to the PHP 
General mailing list. See php.net/support.php for more information.

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: Minor addition to http://php.net/anoncvs.php?

[Zak Greant]

On October 1, 2001 02:16 pm, Jeroen van Wolffelaar wrote:
> > Does anyone object to me modifying the anoncvs.php webpage to
> > include the following note? Does anyone have anything to add -
> > Jeroen? :)
>
> There's a typo in it, but that's not what you meant :-)
>
> I wouldn't name that SuSE thing, it's way to specific for indicating
> that something DOESN'T work. I'd just name the combination which
> _does_ work. I've put a suggestion below, but it's just that -- a
> suggestion.
>
[...]
>  There seem to be problems with libtool 1.4.2, it is suggested that
> you use libtool 1.4, along with the most current autoconf and
> automake. Make sure you install there three tools in the same
> directory. The following combination is known to work: autoconf 2.52,
> automake 1.5 and libtool 1.4.

Good point - thanks for the feedback! :)
I will make the changes shortly.

--zak

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Patch for define() / zend_builtin_functions.c

[Zak Greant]

On October 2, 2001 02:40 am, Andi Gutmans wrote:
> It might be the fact that I just woke up but why can't constants have
> the same name as function names or class names?

err... ummm... good point. I can't think of any situations where they 
could collide.  Oh well, I still had fun writing the patch. :)

> Secondly, I wouldn't put in the check for the reserved words. People
> have managed without it up to today and any check would slow it down
> a bit (*and* it would be another hard coded place to update reserved
> words when added).

~shrug~ It would be nice - but that's about it. 

> BTW, quicker ways of doing this check is having a
> sorted list and doing a binary search or putting them in a hash table
> and searching for them. But I wouldn't do any of these.

Thanks :)

--zak

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Patch for define() / zend_builtin_functions.c

[Zak Greant]

On October 2, 2001 01:55 am, Derick Rethans wrote:
> On Tue, 2 Oct 2001, Zak Greant wrote:
> > Bug report 13505 got me thinking about the behavior of define() -
> > if you try to define a constant name that is a reserved word, or an
> > existing function or class name, no warning is generated.
> >
> > This could have  been a conscious decision - a case where it was
> > decided that some safety could be traded for a bit of extra speed.
> > If it wasn't, then here is a patch to check that the constant name
> > does not clash with a reserved work, function name or class name.
> >
> > I used an array of reserved words and a for loop to handle finding
> > conflicting reserved words. Is there a better way to do this.
> > AFAICT the other methods for handling reserved word conflicts are
> > handled at the parser level. i.e. Trying to define 'function and
> > (){}' generates a parser error.
> >
> > Anyhoo, perhaps someone could take a look at the patch? :)
>
> The idea looks ok, but the looping through the reserved words array
> would be very slow. However, keeping the first two checks in place it
> would be good IMO.

Hi Derick,

Thanks for taking a look! :) Attached is the fixed patch.

Perhaps tying the keyword checking to a certain error level would do 
the trick? Say perhaps if E_NOTICE is enabled, then do the checks? 

Also is there a faster way to do the search? My knowledge of C is still 
rather rudimentary. :o)

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

Index: zend_builtin_functions.c
===
RCS file: /repository/Zend/zend_builtin_functions.c,v
retrieving revision 1.103
diff -u -r1.103 zend_builtin_functions.c
--- zend_builtin_functions.c	2001/08/11 15:57:07	1.103
+++ zend_builtin_functions.c	2001/10/02 07:54:43
@@ -380,7 +380,22 @@
 ZEND_FUNCTION(define)
 {
 	zval **var, **val, **non_cs;
-	int case_sensitive;
+	char *lcname;
+	char *reserved_words[] = {
+		"and",  "isset","break","case",
+		"class","continue", "default",  "die",
+		"do",   "echo", "else", "elseif",
+		"empty","endfor",   "endforeach",   "endif",
+		"endswitch","endwhile", "exit", "extends",
+		"for",  "foreach",  "function", "global",
+		"if",   "include",  "include_once", "list",
+		"new",  "not",  "or",   "parent",
+		"print","require",  "require_once", "return",
+		"static",   "stdClass", "switch",   "var",
+		"virtual",  "while","xor",  "__sleep",
+		"__wakeup", "__file__",		"__line__",		""
+	};
+	int case_sensitive, index;
 	zend_constant c;

 	switch(ZEND_NUM_ARGS()) {
@@ -420,8 +435,38 @@
 			break;
 	}
 	convert_to_string_ex(var);
+
+
+	/* Ensure that the constant will not conflict with existing function or class names */
+lcname = estrndup((*var)->value.str.val, (*var)->value.str.len);
+zend_str_tolower(lcname, (*var)->value.str.len);
+
+if (zend_hash_exists(EG(function_table), lcname, (*var)->value.str.len+1)) {
+efree(lcname);
+zend_error(E_WARNING,"Constant names must not conflict with function names");
+RETURN_FALSE;
+}
+
+if (zend_hash_exists(EG(class_table), lcname, (*var)->value.str.len+1)) {
+efree(lcname);
+zend_error(E_WARNING,"Constant names must not conflict with class names");
+RETURN_FALSE;
+}
+
+for (index = 0; *reserved_words[index]; ++index) {
+if (strcmp (reserved_words[index], lcname) == 0) {
+efree(lcname);
+zend_error(E_WARNING, "Constant names must not conflict with reserved words");
+RETURN_FALSE;
+}
+}
+
+
+efree(lcname);

+
 	c.value = **val;
+
 	zval_copy_ctor(&c.value);
 	c.flags = case_sensitive; /* non persistent */
 	c.name = zend_strndup((*var)->value.str.val, (*var)->value.str.len);


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Patch for define() / zend_builtin_functions.c

[Zak Greant]

On October 2, 2001 01:22 am, Zak Greant wrote:
> Bug report 13505 got me thinking about the behavior of define() - if
> you try to define a constant name that is a reserved word, or an
> existing function or class name, no warning is generated.
>
> This could have  been a conscious decision - a case where it was
> decided that some safety could be traded for a bit of extra speed. If
> it wasn't, then here is a patch to check that the constant name does
> not clash with a reserved work, function name or class name.
>
> I used an array of reserved words and a for loop to handle finding
> conflicting reserved words. Is there a better way to do this. AFAICT
> the other methods for handling reserved word conflicts are handled at
> the parser level. i.e. Trying to define 'function and (){}' generates
> a parser error.
>
> Anyhoo, perhaps someone could take a look at the patch? :)

    ...or not - let me fix the patch first. :)

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Patch for define() / zend_builtin_functions.c

[Zak Greant]

Bug report 13505 got me thinking about the behavior of define() - if 
you try to define a constant name that is a reserved word, or an 
existing function or class name, no warning is generated.

This could have  been a conscious decision - a case where it was 
decided that some safety could be traded for a bit of extra speed. If 
it wasn't, then here is a patch to check that the constant name does 
not clash with a reserved work, function name or class name.

I used an array of reserved words and a for loop to handle finding 
conflicting reserved words. Is there a better way to do this. AFAICT 
the other methods for handling reserved word conflicts are handled at 
the parser level. i.e. Trying to define 'function and (){}' generates a 
parser error.

Anyhoo, perhaps someone could take a look at the patch? :)

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

Index: zend_builtin_functions.c
===
RCS file: /repository/Zend/zend_builtin_functions.c,v
retrieving revision 1.103
diff -u -r1.103 zend_builtin_functions.c
--- zend_builtin_functions.c2001/08/11 15:57:07 1.103
+++ zend_builtin_functions.c2001/10/02 07:06:21
@@ -380,7 +380,22 @@
 ZEND_FUNCTION(define)
 {
zval **var, **val, **non_cs;
-   int case_sensitive;
+   char *lcname;
+   char *reserved_words[] = {
+   "and",  "isset","break","case",
+   "class","continue", "default",  "die",
+   "do",   "echo", "else", "elseif",
+   "empty","endfor",   "endforeach",   "endif",
+   "endswitch","endwhile", "exit", "extends",
+   "for",  "foreach",  "function", "global",
+   "if",   "include",  "include_once", "list",
+   "new",  "not",  "or",   "parent",
+   "print","require",  "require_once", "return",
+   "static",   "stdClass", "switch",   "var",
+   "virtual",  "while","xor",  "__sleep",
+   "__wakeup", "__file__", "__line__", ""
+   };
+   int case_sensitive, index;
zend_constant c;

switch(ZEND_NUM_ARGS()) {
@@ -420,8 +435,38 @@
break;
}
convert_to_string_ex(var);
+
+
+/* Ensure that the constant will not conflict with existing function or class names */
+lcname = estrndup((*var)->value.str.val, (*var)->value.str.len);
+zend_str_tolower(lcname, (*var)->value.str.len);
+
+if (zend_hash_exists(EG(function_table), lcname, (*var)->value.str.len+1)) {
+efree(lcname);
+zend_error(E_WARNING,"Constant names must not conflict with function names.");
+RETURN_FALSE;
+}
+
+if (zend_hash_exists(EG(class_table), lcname, (*var)->value.str.len+1)) {
+efree(lcname);
+zend_error(E_WARNING,"Constant names must not conflict with class names.");
+RETURN_FALSE;
+}
+
+for (index = 0; *reserved_words[index]; ++index) {
+if (strcmp (reserved_words[index], lcname)) {
+efree(lcname);
+zend_error(E_WARNING, "Constant names must not conflict with reserved words");
+RETURN_FALSE;
+}
+}
+
+
+efree(lcname);

+
c.value = **val;
+
zval_copy_ctor(&c.value);
c.flags = case_sensitive; /* non persistent */
c.name = zend_strndup((*var)->value.str.val, (*var)->value.str.len);

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] namespaces ambiguity

[Zak Greant]

On October 1, 2001 04:51 am, Andi Gutmans wrote:
> At 12:46 PM 10/1/2001 +0200, Stig Sæther Bakken wrote:
[snip]
> >I still think Zeev's suggestion (HTML::Table) is very good, if it
> >doesn't impose too much runtime overhead.
>
> I don't like Zeev's suggestion because it does impose an extra hash
> lookup (usually it'll be two) and probably some more logic too. I
> don't think that new features we add today should suffer from
> run-time overhead some constructs from the past have had to suffer.
> By the way, it also has some ambiguities. Is foo::bar() a function in
> class foo or in namespace foo. No one said you can't have a namespace
> foo when you have a class foo.
> I think the best way to go is to go with ':' and live with the
> ambiguity. Many languages have such ambiguities and it's probably not
> such a big deal. In light of :: also having ambiguities why not go
> with :?
>
> Andi

This may be a ~very~ daft question, but what effect would having 
classes behave as read-only namespaces have? Would that alleviate any
problems?

Just my one cent (not willing to put a whole two cents on this one. ;)

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] namespaces ambiguity

[Zak Greant]

On October 1, 2001 04:46 am, Stig Sæther Bakken wrote:
> [Zak Greant <[EMAIL PROTECTED]>]
>
> > On September 30, 2001 06:15 pm, Wez Furlong wrote:
> > > What about "." then (Java/Delphi)?
> > >
> > > --Wez.
> >
> > Wouldn't that conflict with the concatenation operator?
> >
> > Unless I am mistaken, it looks like only the following single
> > symbols are available: % * | \ (outside of quotes at least)
>
> Uhm, % and * are taken for modulo and multiplication.

Errr... I just threw those in to make you and Wez
feel better about . and \\ - really ;D

> So how do these look:
>
>   HTML\Table  - looks too 1980
>   HTML|Table  - hmm, weird

Agreed.

> I still think Zeev's suggestion (HTML::Table) is very good, if it
> doesn't impose too much runtime overhead.

+1 - seems nice and natural to me. :)

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Minor addition to http://php.net/anoncvs.php?

[Zak Greant]

Does anyone object to me modifying the anoncvs.php webpage to include 
the following note? Does anyone have anything to add - Jeroen? :)

--

 
Certain combinations of autoconf, automake and libtool may cause the 
buildconf script to fail.
 

 
Under SuSE 7.1 (Linux kernal 2.2.18 i686) autoconf version 2.13, 
automake version 1.4 (ok) and libtool version 1.4.2 are suspected not 
to work.
 

 
libtool 1.4.2 may not work with any current (as of 2001/09/30) versions 
of autoconf and automake.
 

-- 

Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug in autoconf report

[Zak Greant]

On September 30, 2001 07:03 pm, you wrote:
> I installed brand new autoconf, automake and libtool into my $HOME.
> That solved the problem.
>
> However, I still don't know what the problem was, probably there were
> some library files not well installed. Anyway, I'm not the
> administrator of that computer, so I couldn't do much more than
> bugging sysop and/or install those tools in my homedir. The former
> one didn't help, the latter one did.
>
> The server I tried on was Debian, and in my original mail you can
> find the versions I had at that time. Currently, it is:
> buildconf: checking installation...
> buildconf: autoconf version 2.52 (ok)
> buildconf: automake version 1.5 (ok)
> buildconf: libtool version 1.4 (ok) <-- on purpose, read somewhere
> that some version was giving trouble, so I played on safe.
> rebuilding Makefile templates

It looks like the older versions of autoconf and automake
don't play nicely with newish versions of libtool. It also 
seems that the newest version of libtool does not play 
nicely with anyone (or something like that - like I have 
~any~ clue what is actually going on. ;)

I had installed autoconf 2.52, automake 1.4 and libtool 1.4.2
This worked somewhat better than my previous setup, but
failed on trying to run the buildconf in the Zend directory.

Rolling back to libtool 1.4 seemed to fix the problem - I am
now the proud host of a cgi build of 4.0.8-dev  :))

Thanks for the help!

--zak

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug in autoconf report

[Zak Greant]

Hi Jeroen,

Did you ever get the problem sorted out? Has anyone encountered the 
same difficulty?

I just encountered the same issue in almost the same circumstances. In 
my case, automake and libtool both live in /usr/bin. 

% cd php4
% ./buildconf
buildconf: checking installation...
buildconf: autoconf version 2.13 (ok)
buildconf: automake version 1.4 (ok)
buildconf: libtool version 1.4.2 (ok)
rebuilding Makefile templates
rebuilding configure
autoconf: Undefined macros:
***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF
configure.in:162:AC_MSG_RESULT([$PHP_SAPI])
configure.in:182:AC_MSG_RESULT([$php_cv_cc_dashr])
[output truncated for brevity's sake]

I am updating all of my Autotools - will try again when that is done.

--zak

On September 25, 2001 11:53 am, Jeroen van Wolffelaar wrote:
> > On Tue, 25 Sep 2001, Jeroen van Wolffelaar wrote:
> > > 
> > >
> > > Note: after I solved that warning about automake & libtool not
> > > being in the same dir, the error remainded the same. (I copied
> > > the automake executable to the same dir as the libtool
> > > executable)
> >
> > Ok, but it's still a problem with your build tools, it works fine
> > here. You re-ran buildconf I guess?
>
> Yes, retrieving the whole CVS again takes quite some time again...
> what's the command to clean all files that are not from CVS, so that
> I've got a really clean tree again? make clean / make distclean? (But
> they don't yet work before you run configure...)
>
> So you think libtool is mal-installed? Could be possible...
>
> > Derick
>
> --Jeroen

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] namespaces ambiguity

[Zak Greant]

On September 30, 2001 06:15 pm, Wez Furlong wrote:
> What about "." then (Java/Delphi)?
>
> --Wez.

Wouldn't that conflict with the concatenation operator?

Unless I am mistaken, it looks like only the following single symbols 
are available: % * | \ (outside of quotes at least)

-- 
Zak Greant

PHP Quality Assurance Team
http://qa.php.net/

"We must be the change we wish to see." - M. K. Ghandi

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[Zak Greant]

Jim wrote:
> Zak Greant <[EMAIL PROTECTED]> wrote:
> > :) I should have chosen the symbols more carefully. 
> > They seem to have generated more comments than the original proposal...
> > 
> > Does anyone have any comments pertaining to the *concept*? :)
> 
> i was trying to drive at the point that you've just restated a
> slightly weaker form of the apache project guidelines.

Not quite. I was just describing a tool to help in browsing
the accumulated opinions.

> (now, a tool to make it easier to implement those guidelines may be a
> good idea. but i see that as distinct from the process itself. and i
> think anything that moves discussion out of email is doomed to fail.)

Possibly... given how many discussions fail (or are doomed to some
sort of unlife - like the function renaming discussion) I don't
see how it could hurt to try. :)
 
> the real problem is determining who gets to vote.

I am not even worried about votes, etc. I just want a way to more
easily keep track of what is going on. :)

The rating were just there to provide a quick way to track general
opinion.

--zak


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[Zak Greant]

:) I should have chosen the symbols more carefully. 
They seem to have generated more comments than the original proposal...

Does anyone have any comments pertaining to the *concept*? :)

--zak

- Original Message - 
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, August 14, 2001 9:05 PM
Subject: Re: [PHP-DEV] Setting up RFC


> Sterling Hughes <[EMAIL PROTECTED]> wrote:
> >Actually, (+-) 0 are really terms and votes, in other projects I've
> >been involved in, there interpreted as "I don't like it, but I won't
> >stop you" and "I like it, but its not something I think is
> >absolutely necessary"
> 
> right.
> 
> http://dev.apache.org/guidelines.html is probably worth reading for
> folks not familiar with the apache project's process.
> 
> this presentation is worth checking out, too:
> 
>   http://www.ics.uci.edu/~fielding/talks/apache98/index.htm
> 
> jim
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
> 


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[Zak Greant]

Joey wrote:
> > Are you doing a new O'Reilly book, PHP-DEV in a nutshell?

Subtitled: A Rogues Gallery ;)

> > -Sterling
> 
> I especially enjoy the idea of "positive zero" and "negative
> zero". :)

I think that +/-0 would accurately portray the sometimes
odd nature of support for proposals. ;)

--zak


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Setting up RFC

[Zak Greant]

Jeroen wrote:
> They should _not_ be too technical, _not_ too long, but yet as simple as
> possible, but exactly as precise enough to be relatively unambigious if
you
> know about the PHP conventions. For example like that zend engine 2 white
> paper.
>
> But they need to be updated, and not discarded.
>
> They shouldn't be too hard to create, and definitely not too hard to grok.
A
> simple template could help achieving this.
>
> All of the above IMHO,

I think that the most basic problems that we encounter are:

The information from a given discussion becomes more and more
difficult to access as time passes.

We perform additional work due to the above problem.

If we can have a simple system that is easy to browse and use for
discussing
these issues, I think that would be perfect...

The system would work something like this:

Each person has an account in the system.
Someone makes a proposal.

i.e.

Proposal: Foo
-
Incorporate feature foo into the Zend engine.

Abstract

The foo feature would do bar and baz.

Details
---
...

Other developers would respond to the proposal.

All interested developers could discuss the issue on a mailing list or
threaded forum - however all interested developer would have to simply
and
explicitly state their current position on their account.

i.e.

Zak Greant

Proposal Foo

Position: [x] Strongly Support
  [ ] Support
  [ ] Neutral
  [ ] Oppose
  [ ] Strongly Oppose

Position statement (one or two sentences)
[ I believe that foo would elegantly solve problem x, while
remaining
  true to the PHP idiom ]


A status page would report on the proposals and positions of the various
people:


Something like:
[--- choose a proposal --][+]

Once a proposal had been chosen, you would see a list like:

Proposal: Foo*
--
...
Rasmus +0This should help fix issue x and bug y.
Richard -
Sascha +0This proposal supports RFC 10921 in a good way.
Sterling   -0RFC 10921 is kind of strange.
Torben -1There is already too much foo in the language.
Zak+1Proposal foo must be obeyed
Zeev   -0We don't need foo, we can just modify bar.

* "The characters and opinions portrayed and the names used herein are
fictitious and any
resemblance to the names, character, or history of any person is
coincidental and unintentional!" ;)

+1: Strongly Support
+0: Support
 0: Neutral
-0: Oppose
-1: Strongly Oppose

 -: Have not commented


We would still be able to have good, detailed discussions without being
too formal
or losing data. We could easily see what was going on with a discussion
without having
to dig through %$^&-loads of email. Plus everything would be archived
for future ref.

For really important stuff, we can do an RFC after the discussion.

--zak





-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]