Re: [PHP-DEV] compiling PHP_4_3

[Rasmus Lerdorf]

Did you actually check out version 4.3?

  cvs co -r PHP_4_3 php4

Check your CVS/Entries file.  You should see the branch name after each
file.

-Rasmus

On Thu, 13 Mar 2003, Corne' Cornelius wrote:

> Hi,
>
> I compiled CLI version of PHP_4_3 this morning and it gave the following:
>
> php4/main/main.c:225: undefined reference to `zend_disable_class'
> php4/main/main.c:239: undefined reference to `zend_disable_class'
>
> Is this right ? won't PHP_4_3 compile with Zend version 1 anymore ?
>
> Corne'
> !Exclude Disclaimer!
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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

Re: [PHP-DEV] Moderate PHP-DEV

[Rasmus Lerdorf]

> > We don't lose anything by giving the first two items some
> > time to prove their usefullness.  On the other hand, it is
> > very likely that we will lose useful input, if we implement
> > the third item prematurely.
>
> I disagree. Anyone here can handle replying because we already have the
> anti-spam protection. The only thing we're doing is adding to the message
> an explanation of the post ethics.
> I wouldn't call this drastic at all.

I am not overly confident that the system works though.  The problem right
now is that we have not been in any way tracking peoples' failed attempts
to send something to the addresses currently protected by the system.  It
is only when a clueful person, like Dirk recently, persisted and emailed
me privately with the 3 messages he had tried dilligently to get to us but
ultimately failed, that we get a hint that something along the way didn't
work.

I have no idea if the problem was on our end or on Dirk's end.  Dirk knows
what the hell he is doing and he said he turned off any spam-catching
filters and whatever else might have prevented him from getting the
confirmation email he was supposed to reply to in order to verify his
emails.  Whatever the reason, the system didn't work for him, and who
knows how many others it has failed for as well.  Dirk was listed in the
'pending' stage meaning supposedly a confirmation email had been sent, but
he said he never got it.  There are many other addresses listed as
pending.  I'd like to get a better idea of what happened to Dirk's
confirmation email and also whether the other people on the list received
such an email.

If we are going to deploy this on a much wider scale, before doing so
someone has to volunteer to track how it is working currently so we have a
sense of whether it works at all and under which circumstances it falls
over.  Blindly enabling what may or may not be a shaky solution on
something as important as php-dev is a very bad idea.

-Rasmus

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

Re: [PHP-DEV] PHP Lists not hiding email address

[Rasmus Lerdorf]

On Tue, 11 Mar 2003, Ryan wrote:

> Hi,
> 
> I'm getting a lot of spam leading from some of the pages on
> zend.com/lists/php-dev/
> 
> The bug edit pages hide the email address. But the static archives like
> http://www.zend.com/lists/php-dev/200110/msg02161.html
> don't hide them.
> 
> Could you fix this?

Why in the world are you posting this to php-dev?  That is a matter for 
[EMAIL PROTECTED] and has nothing to do with the PHP project.

-Rasmus


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

Re: [PHP-DEV] Language Auto Detection / www.php.net

[Rasmus Lerdorf]

> What browser denies you from setting this accept-language thing?
> You do have control over it, and it is far more general then
> having a cookie in the browser. Which is also not that flexible,
> as we would probably only store one language code.

Gabor, the problem is that you can't override it.  If you are unlucky
enough to be speaking a language for which the PHP documentation is
crappy, but you still want to set your accept-language to that language
for use on other sites, then you are out of luck on php.net.

-Rasmus

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

Re: [PHP-DEV] CVS access

[Rasmus Lerdorf]

Unless I am missing something, I don't see how this stuff belongs in PHP
CVS at all.  Could you explain why you think this needs to be in the core
language CVS?

-Rasmus

On Mon, 10 Mar 2003, [iso-8859-2] Ján Šuňavec wrote:

> I need CVS access into PHP CVS repository. I have project with code
> name DotPHP. See CVS repository in http://sourceforge.
> net/projects/webcomp. I want add this directory into PHP directory...
>
>
>
>
>
>
>  Akelavlk
>
> == REKLAMA =
> Vyrazne zlavy pocitacov a prislusenstva
> Toshiba Pocket PC e740 v cench u? od 24.300,- Sk bez DPH
> Navstivte nas na adrese http://www.somi.sk/akcie.php
> 
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

Re: [PHP-DEV] Re: #22527 [Opn->Bgs]: Modulus returned negative value

[Rasmus Lerdorf]

On Tue, 4 Mar 2003, Sascha Schumann wrote:

> > Well, Perl can lean the other way as well actually.  Try this:
> 
> Is there some documentation why the default is as it is?

All I could find was this description of the Perl modulus operator:

  Binary ``%'' computes the modulus of two numbers. Given integer operands
  $a and $b: If $b is positive, then $a % $b is $a minus the largest
  multiple of $b that is not greater than $a. If $b is negative, then $a %
  $b is $a minus the smallest multiple of $b that is not less than $a 
  (i.e. the result will be less than or equal to zero). Note than when use 
  integer is in scope, ``%'' give you direct access to the modulus 
  operator as implemented by your C compiler. This operator is not as well 
  defined for negative operands, but it will execute faster.

-Rasmus


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

Re: [PHP-DEV] Re: #22527 [Opn->Bgs]: Modulus returned negative value

[Rasmus Lerdorf]

Well, Perl can lean the other way as well actually.  Try this:

  use integer;
  print -27%7;

You will see it gives you -6.  Like I said, it comes down to which way you 
truncate.  Programmers tend to think that something like (int)(-3.4) 
should result in -3.  If that is what you expect, then I think you also 
have to expect -27%7 to return -6.  

-Rasmus

On Tue, 4 Mar 2003, George Schlossnagle wrote:

> Interesting.
> 
> I don't know what the ISO standard say, but mathematically a a % b will 
> always return you an integer 0 <= a%b < b (since there are no negative 
> numbers in canonical representation of Z/bZ).  I guess perl/python/tcl 
> ddecided to adhere to the mathematical definition.
> 
> 
> On Tuesday, March 4, 2003, at 02:37  AM, Rasmus Lerdorf wrote:
> 
> > This is actually an interesting question.  Should we be truncating 
> > towards
> > zero?  I'd say yes, but then I tested Perl, Python and Tcl, and they 
> > all
> > say that -27 % 7 is 1 which means they truncate towards negative 
> > infinity.
> 
> 
> 


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

[PHP-DEV] Re: #22527 [Opn->Bgs]: Modulus returned negative value

[Rasmus Lerdorf]

This is actually an interesting question.  Should we be truncating towards
zero?  I'd say yes, but then I tested Perl, Python and Tcl, and they all
say that -27 % 7 is 1 which means they truncate towards negative infinity.

Too late to change at this point in the game, but perhaps it calls for a
modulus() function which leans the other way?

-Rasmus

On Mon, 4 Mar 2003 [EMAIL PROTECTED] wrote:

>  ID:   22527
>  Updated by:   [EMAIL PROTECTED]
>  Reported By:  jaypedhskr at aol dot com
> -Status:   Open
> +Status:   Bogus
>  Bug Type: Math related
>  Operating System: Unix
>  PHP Version:  4.2.3
>  New Comment:
>
> Modulus has never been well-defined for negative values in computer
> languages.  It all comes down to whether the language truncates towards
> zero or towards negative infinity.  Computers have traditionally
> truncated towards zero, whereas mathematicians tend to truncate towards
> negative infinity.  Some languages like Fortran and Ada actually have
> two different modulus operators for this reason.  PHP just has one, and
> it truncates towards zero as has been the traditional and expected
> thing for programming languages to do.
>
> So, given that, let's look at your numbers.  Modulus has to satisfy the
> relation: (a/b)*b + a%b = a
> where a/b is an integer division where our truncation direction comes
> in.
>
>   (-27/7) * 7 + -27%7 = -27
>   ( -3  ) * 7 + -27%7 = -27
> -21 + -27%7   = -27
>   -27%7   = -27+21
>   -27%7   = -6
>
> In fact, the ISO standard for the C programming language, in which PHP
> is written, defines integer division and modulus operators to perform
> truncation towards 0 and not towards negative infinity.  We don't
> really have a strict language definition for PHP, but if we did, we
> would most likely follow the lead of languages like Fortran, C and C++
> and specify truncation towards zero to be as consistent as possible
> with other languages.
>
>
>
> Previous Comments:
> 
>
> [2003-03-03 22:29:46] jaypedhskr at aol dot com
>
> Hi,
>
> I had the following result from a PHP script, as seen from printing
> output variables:
>
> -27 % 7 == -6
>
> My understanding of the modulus function is that it returns the
> remainder from division, and that the remainder can never be negative.
>
> I believe that is the standard mathematical definition.
>
> So I think what should have been returned is 1 instead of -6.
>
> That is
>
>   -27 = 7*(-4) + 1
>
> instead of
>
>   -27 = 7*(-3) -6
>
> I got around this by adding the the modulus value if the result was
> less than zero.  But I think a result of less than zero shouldn't
> occur.
>
> Code snippet that ran into this:
>
>   $T5 = $D + $T1 + $Y + $T2 + $T3 - $T4;
>   $weekday = $T5 % 7;
>
> Added code to handle this:
>   if ($weekday < 0) {
>   $weekday += 7;  // -27 % 7 = -6 case
>   }
>
> Specific problem case:
> $T5 = 3 + 2 + 3 + 5 + 0 - 40; // -27
> $weekday = %T5 % 7; // -27 % 7 = -6
>
> Thanks!
>
> -Jay Pedersen
>
>
> 
>
>
> --
> Edit this bug report at http://bugs.php.net/?id=22527&edit=1
>

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

[PHP-DEV] Re: [PHP] 'make' PHP4.3.1 returns the use of function`tempnam' isdangerous --- WHY?

[Rasmus Lerdorf]

> When I tried to 'make' PHP-4.3.1, it returns warning message and died.  I am
> using RH8.0 + Apache 2.0.44

It didn't die, that is simply the end of the build.  Warnings aren't 
fatal.

(Please do not cc all the lists)

-Rasmus


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

Re: [PHP-DEV] magic_quotes on the environment?

[Rasmus Lerdorf]

> I'm not convinced that escaping environment data is the correct thing to 
> do in the first place, and I would like to change php to not escape env 
> vars if magic_quotes_gpc is on.  Any opinions on this?

This changed somewhere along the line then.  Originally magic quotes only 
touched GPC data.  I never noticed it also did it to the environment and 
I'd consider that to be a bug.

-Rasmus


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

Re: [PHP-DEV] Tie'ing variables

[Rasmus Lerdorf]

> Analyzing PHP's routines a bit, it seems that the slowest part of a
> "generic" request is populating the special arrays, $_ENV, $_GET, etc.

Do you have any profiling evidence of this?  Everything I have looked at 
points squarely at the parts of PHP that requires a system call.  Reducing 
system calls gives you a lot more bang for the buck than optimizing 
elsewhere.

-Rasmus


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

Re: [PHP-DEV] [PATCH] - fix for 64 bit issues with OnUpdateInt

[Rasmus Lerdorf]

On Fri, 28 Feb 2003, Andi Gutmans wrote:

> At 04:50 PM 2/28/2003 +0100, Sascha Schumann wrote:
> > I think that simply adding OnUpdateLong and deprecating
> > OnUpdateInt is fine while retaining its current semantics.  I
> > just don't see any value in changing the meaning of
> > OnUpdateInt; at least that's how I interpreted Andi's
> > message.
>
> That's also an option but I think OnUpdateInt() is confusing and how do we
> stop ppl from using it in new extensions which who's commit messages aren't
> followed via php-cvs?

You can't really, but at least their extensions won't compile in future
PHP versions and they will be forced to go and address the issue as
opposed to continuing to propogate extensions that aren't 64-bit friendly.
If we could force a compiler warning/error on a type mismatch to the
OnUpdateInt/Long then that might be a solution too.

-Rasmus

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

Re: [PHP-DEV] New extension: netfilter

[Rasmus Lerdorf]

On Fri, 28 Feb 2003, Corne' Cornelius wrote:
> Can i code a netfilter extension for PHP or don't you guys see the need
> for it ?
> It could result in some great firewall frontends in PHP

Go for it.  Assuming the netfilter library is not under the GPL.  LGPL is
fine.

-Rasmus

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

Re: [PHP-DEV] Flex never-interactive mode

[Rasmus Lerdorf]

On Wed, 26 Feb 2003, Andi Gutmans wrote:

> At 12:48 PM 2/26/2003 -0800, Rasmus Lerdorf wrote:
> >I think we can add "%option never-interactive" to the ini-scanner lexer to
> >speed it up a tiny little bit.  Speeding up the ini scanner might be
> >important for the folks running the cgi version.  More importantly, to me
> >anyway, when we know we are not interactive, should we not
> >programmatically set is_interactive to false for the language scanner as
> >well?  I did this here and the ioctl syscalls that come from the isatty()
> >calls in the lexer dropped away speeding things up nicely.
> 
> Do you have any figures? (req/s wise)
> I think we can set it to false when we know we're not interactive. It 
> shouldn't be a problem.

Not really.  I've hacked and slashed a bunch of things and this is just
one of them.  I could pull out just this change and try to time it, I
guess.  But it can't help but be faster just by looking at the syscall
profiles before and after the change.  On a simple Hello World script
before the change you have this: (PHP 4.2 with realpath turned off)

 83757 apache  0.10 CALL  __getcwd(0x9fbfe674,0xfff)
 83757 apache  0.10 RET   __getcwd 0
 83757 apache  0.10 CALL  chdir(0x9fbfe614)
 83757 apache  0.30 RET   chdir 0
 83757 apache  0.23 CALL  open(0x167588,0,0x1b6)
 83757 apache  0.31 RET   open 5
 83757 apache  0.09 CALL  __getcwd(0x9fbfdc14,0x400)
 83757 apache  0.32 RET   __getcwd 0
 83757 apache  0.31 CALL  ioctl(0x5,TIOCGETA,0x9fbfe4e4)
 83757 apache  0.10 RET   ioctl -1 errno 25 Inappropriate ioctl for device
 83757 apache  0.34 CALL  fstat(0x5,0x9fbfd42c)
 83757 apache  0.10 RET   fstat 0
 83757 apache  0.08 CALL  read(0x5,0x148000,0x2000)
 83757 apache  0.23 RET   read 42/0x2a
 83757 apache  0.08 CALL  read(0x5,0x148000,0x2000)
 83757 apache  0.13 RET   read 0
 83757 apache  0.46 CALL  ioctl(0x5,TIOCGETA,0x9fbfd4c0)
 83757 apache  0.09 RET   ioctl -1 errno 25 Inappropriate ioctl for device
 83757 apache  0.20 CALL  close(0x5)
 83757 apache  0.10 RET   close 0
 83757 apache  0.53 CALL  setitimer(0,0x9fbfe29c,0x9fbfe28c)
 83757 apache  0.14 RET   setitimer 0
 83757 apache  0.59 CALL  setitimer(0,0x9fbfe29c,0x9fbfe28c)
 83757 apache  0.09 RET   setitimer 0
 83757 apache  0.26 CALL  chdir(0x9fbfe674)
 83757 apache  0.30 RET   chdir 0

The 3rd column there is the time it took for the call.  A failed ioctl is
one of the heavier syscalls and both of the ioctls disappear for this
request when you turn off is_interactive.  The ioctls are the same in 4.3.  
Here is what I am currently down to in 4.3.  I still need to get rid of 
that one lseek and am hoping to nuke the fstat as well.  I also need to 
figure out why setitimer is being called more in 4.3 than it was in 4.2.

 88046 apache  0.09 CALL  __getcwd(0x9fbfe654,0xfff)
 88046 apache  0.13 RET   __getcwd 0
 88046 apache  0.09 CALL  chdir(0x9fbfe5f4)
 88046 apache  0.32 RET   chdir 0
 88046 apache  0.10 CALL  setitimer(0x2,0x9fbfe63c,0)
 88046 apache  0.08 RET   setitimer 0
 88046 apache  0.08 CALL  setitimer(0x2,0x9fbfe61c,0)
 88046 apache  0.06 RET   setitimer 0
 88046 apache  0.28 CALL  sigaction(0x1b,0x9fbfe5b4,0x9fbfe59c)
 88046 apache  0.08 RET   sigaction 0
 88046 apache  0.07 CALL  sigprocmask(0x2,0x9fbfe60c,0)
 88046 apache  0.06 RET   sigprocmask 0
 88046 apache  0.30 CALL  open(0x12ce0c,0,0x1b6)
 88046 apache  0.33 RET   open 5
 88046 apache  0.21 CALL  lseek(0x5,0,0,0,0)
 88046 apache  0.08 RET   lseek 0
 88046 apache  0.43 CALL  fstat(0x5,0x9fbfd40c)
 88046 apache  0.13 RET   fstat 0
 88046 apache  0.09 CALL  read(0x5,0x13f000,0x2000)
 88046 apache  0.22 RET   read 42/0x2a
 88046 apache  0.06 CALL  read(0x5,0x13f000,0x2000)
 88046 apache  0.15 RET   read 0
 88046 apache  0.66 CALL  close(0x5)
 88046 apache  0.15 RET   close 0
 88046 apache  0.47 CALL  setitimer(0,0x9fbfdf7c,0x9fbfdf6c)
 88046 apache  0.12 RET   setitimer 0
 88046 apache  0.43 CALL  setitimer(0,0x9fbfdf7c,0x9fbfdf6c)
 88046 apache  0.09 RET   setitimer 0
 88046 apache  0.21 CALL  chdir(0x9fbfe654)
 88046 apache  0.31 RET   chdir 0

-Rasmus


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

[PHP-DEV] Flex never-interactive mode

[Rasmus Lerdorf]

I think we can add "%option never-interactive" to the ini-scanner lexer to
speed it up a tiny little bit.  Speeding up the ini scanner might be
important for the folks running the cgi version.  More importantly, to me
anyway, when we know we are not interactive, should we not
programmatically set is_interactive to false for the language scanner as
well?  I did this here and the ioctl syscalls that come from the isatty()
calls in the lexer dropped away speeding things up nicely.  

-Rasmus


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

Re: [PHP-DEV] Re: Announcement: Next generation ext_skel

[Rasmus Lerdorf]

The current one does, so it better...

On Wed, 19 Feb 2003, l0t3k wrote:

> Hartmut,
>   will this also generate zend_parse_parameters calls based on prototype ?
>
> l0t3k
> "Hartmut Holzgraefe" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> >
> > i've just added the first working results of a replacement for the good
> > old ext_skel script in php/scripts/ext_skel_ng
>
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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

Re: [PHP-DEV] Performance degradation part 2 the module version

[Rasmus Lerdorf]

> I'm sure we can eliminate those seeks.  Are there any other areas in the
> streams code that you can see that could do with a syscall tune-up?

Ok, found two more.  In _php_stream_fopen() we fstat() the script to be 
opened:

realpath = expand_filepath(filename, NULL TSRMLS_CC);

fp = fopen(realpath, mode);

if (fp) {
/* sanity checks for include/require */
if (options & STREAM_OPEN_FOR_INCLUDE && (fstat(fileno(fp), &st) == -1 || 
!S_ISREG(st.st_mode))) {
#ifdef PHP_WIN32
/* skip the sanity check; fstat doesn't appear to work on
 * UNC paths */
if (!IS_UNC_PATH(filename, strlen(filename)))
#endif
goto err;
}
ret = php_stream_fopen_from_file_rel(fp, mode);


That sequence of code is a trainwreck.  The expand_filepath() ends up 
doing an lstat() on every component of the path and then the file itself, 
and then we fstat() the file.  I can't afford the realpath() here, so I 
turn it off in expand_filepath(), but I don't think the fstat() is needed 
there.

Then right after that in _php_stream_fopen_from_file() we have:

#ifdef S_ISFIFO
/* detect if this is a pipe */
if (self->fd >= 0) {
struct stat sb;
self->is_pipe = (fstat(self->fd, &sb) == 0 && S_ISFIFO(sb.st_mode)) ? 1 : 0;
}
#endif

which does yet another fstat() on the file.  At the very least, this one 
should use the result of the previous one.  Basically if these checks are 
still needed, we need a stat cache here.  

There is a 3rd fstat() after that, but I can't really make any sense of 
the backtrace to it:

#0  0x202d0c58 in fstat () from /usr/lib/libc.so.4
#1  0x202e42e6 in __swhatbuf () from /usr/lib/libc.so.4
#2  0x202e4236 in __smakebuf () from /usr/lib/libc.so.4
#3  0x202d454f in __srefill () from /usr/lib/libc.so.4
#4  0x202b3ea6 in fread () from /usr/lib/libc.so.4
#5  0x203f9bb4 in yy_get_next_buffer () at Zend/zend_language_scanner.c:5359
#6  0x203f98cd in lex_scan (zendlval=0x9fbfd770) at Zend/zend_language_scanner.c:5193
#7  0x20401814 in zendlex (zendlval=0x9fbfd76c) at 
/homes/rasmus/php4/Zend/zend_compile.c:2459
#8  0x203f38e8 in zendparse () at /home/y/share/bison.simple:432
#9  0x203f6685 in compile_file (file_handle=0x9fbff758, type=2) at 
/homes/rasmus/php4/Zend/zend_language_scanner.l:348
#10 0x2040b3a6 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at 
/homes/rasmus/php4/Zend/zend.c:860
#11 0x203e41ce in php_execute_script (primary_file=0x9fbff758) at 
/homes/rasmus/php4/main/main.c:1591
#12 0x204235d6 in apache_php_module_main (r=0xdc040, display_source_mode=0)
at /homes/rasmus/php4/sapi/apache/sapi_apache.c:55
#13 0x2042419e in send_php (r=0xdc040, display_source_mode=0, filename=0x0)
at /homes/rasmus/php4/sapi/apache/mod_php4.c:617
#14 0x204241fe in send_parsed_php (r=0xdc040) at 
/homes/rasmus/php4/sapi/apache/mod_php4.c:632
#15 0x48e84 in ap_invoke_handler (r=0xdc040) at http_config.c:518
#16 0x59cec in process_request_internal (r=0xdc040) at http_request.c:1352
#17 0x59d47 in ap_process_request (r=0xdc040) at http_request.c:1368
#18 0x52977 in child_main (child_num_arg=0) at http_main.c:5229
#19 0x52b18 in make_child (s=0xa4930, slot=0, now=1046217441) at http_main.c:5400
#20 0x52c49 in startup_children (number_to_start=25) at http_main.c:5498
#21 0x53165 in standalone_main (argc=2, argv=0x9fbffa80) at http_main.c:5859
#22 0x538ec in main (argc=2, argv=0x9fbffa80) at http_main.c:6246

-Rasmus


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

Re: [PHP-DEV] Performance degradation part 2 the module version

[Rasmus Lerdorf]

> Admittedly, when opening the file for the first time, we do not need to
> seek - so we can avoid it by passing a flag (OR'd with the REPORT_ERRORS
> flag).
> 
> I'm sure we can eliminate those seeks.  Are there any other areas in the
> streams code that you can see that could do with a syscall tune-up?

Those are the only ones I have seen so far that stood out as being 
extraneous.  

I think we should do our best to add whatever shortcuts are necessary to
ensure the most common execution path is as fast as we can possibly get
it.  If it takes getting a little ugly passing in flags, so be it.  I'd
like to get 4.3 up to the same level as 4.2.  I still need to hack and
slash away code for Yahoo! on top of that since syscall thrashing is our
limiting factor at this point.

There is other ugliness hiding in there.  For example, include_once on a 
file that has already been included will still stat() (many times) and 
open() the file.  Only later on does it go and check the included_list to 
see if it should actually have done that.  Not quite on the primary 
execution path, but still.  If you have a case where that scenario happens 
a lot, it is actually mesurably faster to do manual multiple include 
prevention with a PHP-level flag.  The _once stuff was added distinctly to 
prevent that kind of ugly code, but we stuffed it up.

-Rasmus


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

Re: [PHP-DEV] Performance degradation part 2 the module version

[Rasmus Lerdorf]

On Sun, 23 Feb 2003, Wez Furlong wrote:
> This double seeking is most probably due to the fact that the stdio
> layer does one set of seeking, whereas streams needs to do another.
> 
> This can be solved by moving away from using stdio for streams, and just
> using the "raw" descriptors instead.  (already made a start on this in
> PHP 5).

I had a closer look at this.  The seeks are not coming from the stdio 
layer, they are coming directly from PHP.  The first, SEEK_CUR +0 comes 
from an ftell() call here in _php_stream_fopen_from_file():

if (stream) {
if (self->is_pipe) {
stream->flags |= PHP_STREAM_FLAG_NO_SEEK;
} else {
stream->position = ftell(file);
}
}

We should be able to skip that ftell() call on a script or include file we 
have just opened, right?

And here is the backtrace for the second one:

#0  0x202e6c0f in lseek () from /usr/lib/libc.so.4
#1  0x203ef154 in php_stdiop_seek (stream=0xd640c, offset=0, whence=0, 
newoffset=0x9fbfdcbc)
at /homes/rasmus/php4/main/streams.c:1493
#2  0x203ef868 in _php_stream_cast (stream=0xd640c, castas=-1073741824, 
ret=0x9fbfdcf0, show_err=8)
at /homes/rasmus/php4/main/streams.c:1952
#3  0x203f04d6 in _php_stream_open_wrapper_as_file (path=0xddad8 
"/home/y/share/htdocs/test.php", mode=0x2043a223 "rb",
options=141, opened_path=0x9fbff328) at /homes/rasmus/php4/main/streams.c:2506
#4  0x203e3b4e in php_fopen_wrapper_for_zend (filename=0xddad8 
"/home/y/share/htdocs/test.php", opened_path=0x9fbff328)
at /homes/rasmus/php4/main/main.c:727

The php_stdiop_seek() does a direct lseek() call.  I don't really see why
this is needed either at this point.  In
_php_stream_open_wrapper_as_file() what are you trying to guard against
with that stream_cast call?

if (php_stream_cast(stream, 
PHP_STREAM_AS_STDIO|PHP_STREAM_CAST_TRY_HARD|PHP_STREAM_CAST_RELEASE,
(void**)&fp, REPORT_ERRORS) == FAILURE)
{
php_stream_close(stream);
if (opened_path && *opened_path)
efree(*opened_path);
return NULL;
}

We have already stat()'ed the file to death.  We know it is there, that we 
are allowed to open it, etc.  What could go wrong that the open call just 
above it wouldn't have caught?  Is it just a case of getting too general 
and we need a special-case simpler function for the most common operation 
of simply opening script files?

-Rasmus


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

Re: [PHP-DEV] patch for binary-safe strip_tags()

[Rasmus Lerdorf]

Looks fine to me.  

On Tue, 25 Feb 2003, Moriyoshi Koizumi wrote:

> Hi,
> 
> Attached is the patch for binary-safe strip_tags().
> Although it doesn't appear to be harmful anyhow, I think it needs
> review since it modifies rather sensitive part.
> 
> Any objections?
> 
> Moriyoshi
> 
> 


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

Re: [PHP-DEV] Performance degradation part 2 the module version

[Rasmus Lerdorf]

> Have you been testing PHP_4_3 from CVS or the actual 4.3.0 release?
> You might find the situation slightly better using the latest (I tidied
> up some seek related issues the other day).

The straces are from PHP_4_3 HEAD as of this morning.

I thought originally that these issues were just a hassle for me at Yahoo!
where performance is super-critical and that the average PHP user wouldn't
really care.  But I am seeing normal users switching back to 4.2 from 4.3
now because of these issues.

We can probably live with the seek overhead if I can get rid of the rest.
If I can eliminate that one getcwd() call that was also in 4.2, perhaps we
can get back to being on par.

-Rasmus

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

[PHP-DEV] extra realpath() found

[Rasmus Lerdorf]

Hey Sander, you fixed a problem back in July where you introduced a second
realpath() call into the main execute_script() function.  I understand
what you were trying to achieve, but realpath() is way way too expensive
to toss around like that, especially since we already do the realpath on
the fopen of the script file.

The bug in question was http://bugs.php.net/17720 and your fix was
http://cvs.php.net/diff.php/php4/main/main.c?login=2&r1=1.461&r2=1.462&ty=u

php_fopen_primary_script() calls expand_filepath() which does the realpath
before we get to execute_script.  Why not add the path to the
included_files list at that point instead?

Let me know if you feel like playing with it, otherwise I will.

-Rasmus

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

Re: [PHP-DEV] Performance degradation

[Rasmus Lerdorf]

On Sun, 23 Feb 2003, Shane Caraveo wrote:

> Rasmus Lerdorf wrote:
> > So, I am just starting out down the path to figure out why PHP 4.3 has
> > gotten so much slower than 4.2.  "strace -c" provides the first clue.  A
> > straight "./configure --enable-inline-optimization && make" command-line
> > build for 4.2, 4.3 and 5.0 run on a simple hello world script reveals that
> > we have gone from 219 system calls in 4.2 to 233 in 4.3 to 236 in 5.0.
> > This is a bad trend and we really need to make an effort to reverse this.
> >
> > 4.2 Hello World from command-line:
> >
>
> CGI, right?  Part of this may be from the path_info handling I've added.
>   There is a stat call in there to determine if the path provided by the
> webserver includes path_info also, if it does have path_info (stat
> failed), it walks up the path doing a stat to determine the script
> filename and path_info correctly.  the ini setting cgi.fix_pathinfo
> turns this on or off.  It also uses a handfull putenv and getenv calls
> in straightening things out.  I'm sure this adds some of that, but I
> don't think it would add as much an increase as you are seeing, unless
> you're using some long path_info paths.

The extra realpath() and fstat() calls are not cgi specific, so if what
you added only affects cgi, then that isn't the big problem.

-Rasmus

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

Re: [PHP-DEV] Performance degradation part 2 the module version

[Rasmus Lerdorf]

On Sun, 23 Feb 2003, Jim Jagielski wrote:

> Rasmus Lerdorf wrote:
> >
> > Even in 4.2, I think we can optimize it.  Assuming chdir() doesn't return
> > an error, we shouldn't need that second getpwd() call since we just did
> > the chdir() and we should know where we are.
> >
>
> Not necessarily... In a threaded environment, if threadA does
> chdir(/tmp) and then threadB does chdir(/var), then the actual
> process is in /var for the remainder of threadA (IIRC).
> chdir() is process scoped.

That's true, but in threaded mode we don't do the chdir() at all.  This is
specifically for non-threaded.

-Rasmus

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

[PHP-DEV] Performance degradation part 2 the module version

[Rasmus Lerdorf]

A little bit harder to get clean output on this one.  The numbers in the
<>'s are the times for the system call.  Here is a 4.2 hello world
request:

accept(24, {sin_family=AF_INET, sin_port=htons(57198), 
sin_addr=inet_addr("10.0.1.254")}}, [16]) = 3 <4.035087>
rt_sigaction(SIGUSR1, {SIG_IGN}, {0x40035250, [], SA_INTERRUPT|0x400}, 8) = 0 
<0.09>
getsockname(3, {sin_family=AF_INET, sin_port=htons(80), 
sin_addr=inet_addr("10.0.1.253")}}, [16]) = 0 <0.09>
setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0 <0.11>
alarm(300)  = 0 <0.10>
read(3, "GET /index.php HTTP/1.0\r\nUser-Ag"..., 4096) = 106 <0.18>
rt_sigaction(SIGUSR1, {SIG_IGN}, {SIG_IGN}, 8) = 0 <0.08>
time(NULL)  = 1046024055 <0.08>
alarm(300)  = 300 <0.09>
alarm(0)= 300 <0.08>
stat64("/html/index.php", {st_mode=S_IFREG|0644, st_size=58, ...}) = 0 <0.23>
alarm(300)  = 0 <0.09>
umask(077)  = 022 <0.07>
umask(022)  = 077 <0.08>
setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={30, 0}}, NULL) = 0 <0.08>
rt_sigaction(SIGPROF, {0x40690508, [PROF], SA_RESTART|0x400}, {0x40690508, [PROF], 
SA_RESTART|0x400}, 8) = 0 <0.08>
rt_sigprocmask(SIG_UNBLOCK, [PROF], NULL, 8) = 0 <0.08>
getcwd("/usr/sbin", 4095)   = 10 <0.12>
chdir("/html")  = 0 <0.14>
open("/html/index.php", O_RDONLY)   = 4 <0.19>
getcwd("/html", 4095)   = 6 <0.09>
lstat64("/html", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0 <0.12>
lstat64("/html/index.php", {st_mode=S_IFREG|0644, st_size=58, ...}) = 0 <0.11>
ioctl(4, SNDCTL_TMR_TIMEBASE, 0xbfffe1a0) = -1 ENOTTY (Inappropriate ioctl for device) 
<0.09>
fstat64(4, {st_mode=S_IFREG|0644, st_size=58, ...}) = 0 <0.08>
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x402ba000 
<0.27>
read(4, "\n\n
read(4, "", 4096)   = 0 <0.08>
read(4, "", 8192)   = 0 <0.08>
ioctl(4, SNDCTL_TMR_TIMEBASE, 0xbfffd160) = -1 ENOTTY (Inappropriate ioctl for device) 
<0.08>
close(4)= 0 <0.10>
munmap(0x402ba000, 4096)= 0 <0.13>
alarm(300)  = 300 <0.09>
alarm(0)= 300 <0.08>
chdir("/usr/sbin")  = 0 <0.19>
setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 <0.09>
umask(022)  = 022 <0.07>
alarm(0)= 0 <0.08>
select(4, [3], NULL, NULL, {0, 0})  = 0 (Timeout) <0.10>
write(3, "HTTP/1.1 200 OK\r\nDate: Sun, 23 F"..., 232) = 232 <0.34>
time(NULL)  = 1046024055 <0.08>
write(39, "10.0.1.254 - - [23/Feb/2003:10:1"..., 94) = 94 <0.24>
alarm(30)   = 0 <0.09>
shutdown(3, 1 /* send */)   = 0 <0.24>
select(4, [3], NULL, NULL, {2, 0})  = 1 (in [3], left {2, 0}) <0.000775>
read(3, "", 512)= 0 <0.14>
close(3)= 0 <0.27>
alarm(0)= 30 <0.08>
rt_sigaction(SIGUSR1, {0x40035250, [], SA_INTERRUPT|0x400}, {SIG_IGN}, 8) = 0 
<0.09>
alarm(0)= 0 <0.08>

This is just from accept-to-accept, so it doesn't include any Apache/PHP
startup calls at all.  A couple of these syscalls are from Apache but
starting with the alarm(300) call (I think) we are in PHP.  The only thing
that looks slightly off to me in this set of calls are the consecutive
umask() calls.  Might be something worth tracking down to see if one can
be eliminated.  The point here however is to compare to 4.3:

accept(24, {sin_family=AF_INET, sin_port=htons(57262), 
sin_addr=inet_addr("10.0.1.254")}}, [16]) = 3 <8.485988>
rt_sigaction(SIGUSR1, {SIG_IGN}, {0x40035250, [], SA_INTERRUPT|0x400}, 8) = 0 
<0.09>
getsockname(3, {sin_family=AF_INET, sin_port=htons(80),
sin_addr=inet_addr("10.0.1.253")}}, [16]) = 0 <0.10>
setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0 <0.12>
alarm(300)  = 0 <0.10>
read(3, "GET /index.php HTTP/1.0\r\nUser-Ag"..., 4096) = 106 <0.16>
rt_sigaction(SIGUSR1, {SIG_IGN}, {SIG_IGN}, 8) = 0 <0.08>
time(NULL)  = 1046024677 <0.08>
alarm(300)  = 300 <0.08>
alarm(0)= 300 <0.08>
stat64("/html/index.php", {st_mode=S_IFREG|0644, st_size=58, ...}) = 0 <0.22>
alarm(300)  = 0 <0.09>
umask(077)  = 022 <0.08>
umask(022)  = 077 <0.07>
setitimer(ITIMER_PROF, {it_interval={0, 0},

Re: [PHP-DEV] Performance degradation

[Rasmus Lerdorf]

On Sun, 23 Feb 2003, Stanislav Malyshev wrote:

> RL>> So, obviously these opens don't really affect the module version
> RL>> since they only happen on startup, but they still don't seem right.
> RL>> I understand ./php-cgi.ini, but .//php-cgi.ini and .//php.ini?
> RL>> Looks like a missing check there.
>
> If this is only for CGI/startup, it is indeed not so important, IMHO.
> After all, CGI is not a performance-star anyway.

True, but that doesn't mean we should be doing stupid things like trying
to open the same file twice or calling realpath() twice on the same path.
And obviously something similar is happening to the module case because we
are 10-15% slower in the module version.

> Either increased memory usage or substantial change in memory usage
> pattern (e.g., allocation of one big object, than freeing and allocation a
> number of small objects with the same size should generate less brk's then
> allocating small ones first and then large one).

The script I tested was simply:

  
  
  
  
  

Hopefully executing this should not have caused a big change in memory
usage between 4.2 and 4.3.

-Rasmus

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

[PHP-DEV] Performance degradation

[Rasmus Lerdorf]

So, I am just starting out down the path to figure out why PHP 4.3 has
gotten so much slower than 4.2.  "strace -c" provides the first clue.  A
straight "./configure --enable-inline-optimization && make" command-line
build for 4.2, 4.3 and 5.0 run on a simple hello world script reveals that
we have gone from 219 system calls in 4.2 to 233 in 4.3 to 236 in 5.0.
This is a bad trend and we really need to make an effort to reverse this.

4.2 Hello World from command-line:

% time seconds  usecs/call callserrors syscall
-- --- --- - - 
 21.860.000266  1617 3 open
 19.060.000232  29 8   write
 15.690.000191  1118   read
 12.570.000153   285   brk
 10.440.000127   524   old_mmap
  4.110.50  10 5   munmap
  3.370.41   7 6   mmap2
  2.960.36   5 8   mprotect
  2.550.31   215   fstat64
  2.380.29   214   close
  0.740.09   5 2   lstat64
  0.660.08   4 2   rt_sigaction
  0.660.08   8 1   getcwd
  0.490.06   3 2 2 ioctl
  0.490.06   6 1   uname
  0.410.05   3 2   setitimer
  0.410.05   3 2   fcntl64
  0.330.04   4 1   chdir
  0.250.03   2 2   getpid
  0.250.03   3 1   _llseek
  0.160.02   2 1   time
  0.080.01   1 1   gettimeofday
  0.080.01   1 1   rt_sigprocmask
-- --- --- - - 
100.000.001217   219 5 total

4.3 Hello World from command-line:

% time seconds  usecs/call callserrors syscall
-- --- --- - - 
 21.550.000292  1520 7 open
 18.300.000248  28 9   write
 14.610.000198  1217   read
 13.060.000177   295   brk
  8.340.000113   522   old_mmap
  6.350.86  22 4   lstat64
  3.690.50  10 5   munmap
  3.030.41   7 6   mmap2
  2.580.35   5 7   mprotect
  2.360.32   214   fstat64
  2.210.30   213   close
  0.590.08   2 4   setitimer
  0.590.08   3 3   rt_sigaction
  0.590.08   8 1   getcwd
  0.370.05   5 1   chdir
  0.370.05   5 1   uname
  0.300.04   2 2 2 ioctl
  0.300.04   2 2   fcntl64
  0.220.03   2 2   getpid
  0.150.02   2 1   time
  0.150.02   2 1   gettimeofday
  0.150.02   2 1   _llseek
  0.150.02   1 2   rt_sigprocmask
-- --- --- - - 
100.000.001355   233 9 total

5.0 Hello World from command-line:

% time seconds  usecs/call callserrors syscall
-- --- --- - - 
 21.700.000288  1420 7 open
 18.990.000252  28 9   write
 15.070.000200   297   brk
 14.920.000198  1217   read
  8.290.000110   522   old_mmap
  5.430.72  12 6   munmap
  3.540.47   7 7   mmap2
  2.490.33   5 7   mprotect
  2.190.29   213   close
  2.030.27   214   fstat64
  1.430.19   5 4   lstat64
  0.680.09   3 3   rt_sigaction
  0.600.08   2 4   setitimer
  0.600.08   8 1   getcwd
  0.380.05   5 1   uname
  0.300.04   4 1   chdir
  0.300.04   2 2   fcntl64
  0.230.03   2 2   getpid
  0.230.03   3 1 1 ioctl
  0.230.000

Re: [PHP-DEV] file_put_contents() / file_add_contents() ?

[Rasmus Lerdorf]

On Fri, 21 Feb 2003, Ilia A. wrote:
> On February 21, 2003 09:38 am, Sascha Schumann wrote:
> > > implode) and fclose. However, IMO this wrapper is very useful since it
> > > simplifies commonly used code a great deal and even makes it slightly
> > > faster since the wrapper is in C rather then in PHP.
> >
> > Oh, come on.  Put it into a utility library; this does not
> > belong into the core of PHP.  Or is your argument "we already
> > have so much bloat, a bit more is ok, too"?
> 
> This is merely a proposal, which anyone can support or not. Your choice is 
> obviously the latter and that's fine, I do want to make it clear why I do 
> want to see is part of PHP, whether my reasoning has merit or not is up to 
> each person to decide for themselves. If other developers feel the same way 
> you do, then this will definitely not be added and we'll have a precedent in 
> the event someone else notices file_get_contents() and decides to write a 
> function with opposing functionality.

This isn't quite the same as file_get_contents().  That function replaces 
this typical newbie PHP blurb:

  $file = file($filename);
  $str = implode('',$file);

Which is amazingly inefficient.  Of course, the correct PHP implementation 
is:

  $fp = fopen($filename,'r');
  $string = fread($filename,filesize($filename));
  fclose($fp);

but even that is pretty verbose.

I do agree with Sascha that file_put_contents() as it is currently 
proposed is useless.  People aren't currently writing inefficient code to 
emulate this behaviour so we aren't fixing a file/implode fiasco here.  We 
do not need a core function to replace fopen(); fputs(); fclose().

Now, as Sascha said, if file_put_contents() was actually smart and was 
able to atomically create a file with the given contents and handle common 
error conditions intelligently, then I am all for it.

-Rasmus


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

Re: [PHP-DEV] Re: [PHP] Threading

[Rasmus Lerdorf]

On Tue, 18 Feb 2003, Greg Donald wrote:
> On Tue, 18 Feb 2003, Bruce Miller wrote:
> 
> >Will PHP allow multiple-thread execution?
> 
> PHP4 does not have thread support.

Well, except for pear/PECL/threads, of course.

-Rasmus


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

Re: [PHP-DEV] [PATCH] Apache 2.0 Handler module

[Rasmus Lerdorf]

You guys have CVS access, and thus you make the call on what gets accepted 
or not.  There is no higher power here, you guys know the Apache2 stuff 
better than most.  You only start getting pushback if you start changing 
existing code that might break stuff.

-Rasmus

On Tue, 11 Feb 2003, Ian Holsman wrote:

> On Mon, 10 Feb 2003 22:37:44 -0800, Justin Erenkrantz wrote:
> 
> > FWIW, I think I had a minor bug in how it called ap_sub_req_lookup_uri in
> > my copy of php_functions.c.  I posted an updated copy of that file on my
> > apache.org space.  And, I tested virtual('test.html') and it does work
> > fine.
> > 
> > Regardless, there are now two versions of a filterless SAPI (done
> > independently!) for httpd-2.0.  I'd hope one of them gets accepted.  --
> > justin
> 
> 
> ok..
> I just tried, and I have CVS write access ;-)
> 
> I'll checkin my version (with your fixes justin)
> and we'll go from there.
> 
> BTW. I am disabling the 'virtual()' function for the mean time until we
> have a workaround calling a php page from withing a php page.
> 
> The workaround is to use mod-include's SSI functionality.
> 
> 
> Regards
> Ian
> 
> 


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

Re: [PHP-DEV] Reducing the number of system calls for includes

[Rasmus Lerdorf]

> Don't you have any FreeBSD kernel hackers in Y!?  You could probably
> convince/bully one of them to fix it, that's what we always do with ours
> here ;-)

Turns out that one of the problems is that the standard 0x80 way of doing 
a syscall is rather slow on the P4 chip.  P3 and Athlon chips are much 
faster.  As of Linux kernel 2.5.57 or so they are now using sysenter which 
is much quicker, but FreeBSD is still using 0x80 on the P4.  This article 
has some interesting info on the subject:

   http://lwn.net/Articles/18411/

In the end it looks like I am simply going to turn off realpath() 
completely in virtual_file_ex() which means of course that if 
include_once/require_once is used to access the same file through two 
different paths due to a symlink, things will break.  And you can symlink 
your way out of an open_basedir restriction.  I'll happily trade those 
things for the extra 40-50 req/sec this is likely to give me.

-Rasmus


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

Re: [PHP-DEV] Reducing the number of system calls for includes

[Rasmus Lerdorf]

> I think the best solution to this problem, without breaking functionality, 
> is to use a cache for realpath() in virtual_file_ex().
> This should solve the performance problems and not effect BC at all. As 
> TSRM always passes a full path to the realpath() call there, it should 
> always work.

Perhaps make it configurable because on Linux there already is a dcache 
right in the kernel which is likely to be faster than anything we can do.  
As far as I know, Linux is the only OS with such a kernel-level cache.

-Rasmus


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

Re: [PHP-DEV] Reducing the number of system calls for includes

[Rasmus Lerdorf]

> >Another idea would be to try to streamline the normal case for an absolute
> >pathname.  How about doing a readlink() on it.  If that tells us that it
> >is a link, then we know there is something funky and we can do a realpath,
> >otherwise we just assume it is canonical assuming there are no . .. or //
> >in the filename in which case we fall back to a realpath() as well.
> 
> Hmm I'm not sure this would give you what you're looking for. I think it 
> only works if the last element of the path is a symbolic link but I might 
> be wrong. I'm not quite sure of the semantics of readlink().

You are right.  Somehow I had it in my head that readlink() would catch 
any part of the path being a link.

-Rasmus


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

Re: [PHP-DEV] Reducing the number of system calls for includes

[Rasmus Lerdorf]

> The question here is whether it's worthwhile to optimize for
> the case where you have 30+ includes per page.  Is it that
> common?

In my particular case just 2 or 3 includes puts me over the top actually.  
stat() is amazingly slow on freebsd and having 3 includes of files in a 
directory 8 levels below the root is going to do 27 stat()'s.  27 stats on 
my freebsd box here takes 24ms to execute.  That's a long time to be 
sitting around stat'ing things.  And heaven help me if the path is not 
absolute and I have to try different include paths.  And if open_basedir 
is also enabled you might as well go for a coffee while you wait through 
some 80+ syscalls for every include.  

-Rasmus


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

Re: [PHP-DEV] Reducing the number of system calls for includes

[Rasmus Lerdorf]

> That said, we could possibly have a fast mode and use fstat() to get some 
> device information on the open file. I am worried about functionality 
> though. I'm not sure it's worth breaking.

Yes, fstat() is fast.  And perhaps it isn't worth breaking functionality 
across the board, but in my particular case I don't really have a choice.  
It is simply too slow to handle the loads that it needs to handle and 
either I need to get twice as many machines or I need to lose some 
functionality.

Another idea would be to try to streamline the normal case for an absolute 
pathname.  How about doing a readlink() on it.  If that tells us that it 
is a link, then we know there is something funky and we can do a realpath, 
otherwise we just assume it is canonical assuming there are no . .. or // 
in the filename in which case we fall back to a realpath() as well.  

Or, the really straightforward dumbass solution, have some hint we can
pass along that tells the parser to treat what follows as a canonical
filename.

  include "\001/home/rasmus/foo/u2.inc";

A bit too hacky I guess.  Perhaps something like:

  include_canonical "/home/rasmus/foo/u2.inc"; 

And we would simply assume that this is a canonical filename and skip all 
the checks.  This last one is probably what I will need to do, but I will 
do some tests on the readlink() optimization and see if that buys me 
anything.

-Rasmus


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

Re: [PHP-DEV] Reducing the number of system calls for includes

[Rasmus Lerdorf]

> Weird.  That was totally contrary to the way I remember it working.  In 
> trying to figure out why I remembered incorrectly, I realized the 
> reason why you (in general) want to resolve the path to a canonical 
> path is that you can seriously break include_once and require_once if 
> you dont.  Otherwise require_once wont correctly work if you do
> 
> require_once("/home/george/foo.php");
>require_once("/home/george/../george/foo.php");
> ?>

Right, but guarding against this edge case is costing us a lot on the 
normal case.

100,000 realpath() calls on Linux on file /home/rasmus/foo/u2.inc:
real0m1.286s
user0m0.190s
sys 0m1.030s

100,000 stat() calls on Linux on file /home/rasmus/foo/u2.inc:
real0m0.421s
user0m0.070s
sys 0m0.290s

The deeper the directory hierachy, the larger the difference.

On FreeBSD we get slammed!  Looks like they don't have the same 
dcache-like thing that Linux has.

100,000 realpath() calls on /home/rasmus/foo/u2.inc on FreeBSD:
real0m51.274s
user0m6.752s
sys 0m26.478s

100,000 stats() calls on the same file on FreeBSD:
real0m8.873s
user0m0.165s
sys 0m8.042s

So yes, it does look like we don't need to worry too much on Linux, but 
clearly on FreeBSD avoiding stat() calls and calls that create cascading 
stat()'s are to be avoided at all costs.

-Rasmus


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

Re: [PHP-DEV] Reducing the number of system calls for includes

[Rasmus Lerdorf]

> Eliminating realpath for fully qualified paths make sense to me.
> 
> But...  don't you Y! guys use php-a?  Shouldn't this hide that overhead 
> completely from you by completely eliminating all the stats on a 
> require/include after the initial compilation?  Or is this just a 

It doesn't eliminate it at all, no.  These checks are still done even on 
accelerated includes in both zend cache and ioncube.

-Rasmus


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

Re: [PHP-DEV] Reducing the number of system calls for includes

[Rasmus Lerdorf]

On Sat, 25 Jan 2003, Andi Gutmans wrote:
> At 04:32 PM 1/24/2003 -0800, Rasmus Lerdorf wrote:
> > > I can't really think of any way of getting around this. include_once() and
> > > require_once() are basic language constructs and they require this.
> >
> >Well, they require us to be able to uniquely identify a file, they do not
> >necessarily require us to know the canonical filename.  This could be done
> >in a single stat where we grab the device number and inode.
> 
> Yeah but on broken systems single stat's also stat each directory (AFAIK). 
> I don't think it's any faster or at least not noticably.

Which broken systems?  Certainly not on FreeBSD or Linux.  A little test:

  #include 
  #include 
  #include 
  int main(void) {
  struct stat sb;

  stat("/home/rasmus/foo/u2.inc",&sb);
  printf("%d:%d\n",sb.st_dev, sb.st_ino);
  }

That ends up doing just a single stat on FreeBSD:

stat("/home/rasmus/foo/u2.inc",0x9fbffa0c)   = 0 (0x0)

and on Linux:

stat64("/home/rasmus/foo/u2.inc", {st_mode=S_IFREG|0644, st_size=12, ...}) = 0

-Rasmus


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

Re: [PHP-DEV] Reducing the number of system calls for includes

[Rasmus Lerdorf]

> I can't really think of any way of getting around this. include_once() and 
> require_once() are basic language constructs and they require this.

Well, they require us to be able to uniquely identify a file, they do not 
necessarily require us to know the canonical filename.  This could be done 
in a single stat where we grab the device number and inode.

-Rasmus


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

Re: [PHP-DEV] Reducing the number of system calls for includes

[Rasmus Lerdorf]

> >As for numbers, I basically doubled the req/sec rate of a box by
> >eliminating a bunch of system calls caused by include_path and
> >open_basedir stat'ing, so in my particular situation here eliminating as
> >many syscalls as I can is having a direct effect.
> 
> What OS are you running on? Are you running over NFS?

FreeBSD and no.

-Rasmus


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

Re: [PHP-DEV] Reducing the number of system calls for includes

[Rasmus Lerdorf]

On Sat, 25 Jan 2003, Sascha Schumann wrote:

> > files list.  It's handy and nice to normalize the path here, but it is
> > really really expensive!
> 
> ..only on systems with ultra slow syscall setup procedures
> (e.g. Solaris) or lack of directory cache.
> 
> > Due to our current implementation, if you have a lot of includes, you
> > really should put all your include files in / and you will see some
> > impressive improvements.
> 
> Can you put some numbers on that?  I've done quite a lot of
> benchmarking and those calls never appeared on the radar.

Well, take an app that has 30 includes in a directory 5 levels deep.  
Just the realpath() call is going to do 180 stats every time that script
is hit.  Not sure how that wouldn't show up on the radar regardless of the
OS.  You probably don't have anything that has 30 includes, but people out
there write code like that.

> 5. Looking at Linux's syscall implementation and implementing
> the good ideas in FreeBSD.

Well yes, but fixing the os is pretty drastic.  For now I will be patching 
things here to short-circuit all that stuff, but I think it is also 
something we should look at in general for PHP.  

As for numbers, I basically doubled the req/sec rate of a box by 
eliminating a bunch of system calls caused by include_path and 
open_basedir stat'ing, so in my particular situation here eliminating as 
many syscalls as I can is having a direct effect.

-Rasmus


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

[PHP-DEV] Reducing the number of system calls for includes

[Rasmus Lerdorf]

Take this script:

 

So, a simple include with an absolute pathname to avoid any include_path 
searching and all safe_mode and open_basedir checking turned off.  The 
latter of course being an absolute killer.  We still need a lot of system 
calls to handle this include:

getcwd("/home/rasmus", 4096)= 13
lstat64("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/home/rasmus", {st_mode=S_IFDIR|0777, st_size=45056, ...}) = 0
lstat64("/home/rasmus/foo", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/home/rasmus/foo/u2.inc", {st_mode=S_IFREG|0644, st_size=12, ...}) = 0
open("/home/rasmus/foo/u2.inc", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=12, ...}) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=12, ...}) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=12, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4002c000
_llseek(3, 0, [0], SEEK_CUR)= 0
lseek(3, 0, SEEK_SET)   = 0

The 4 lstat64() calls here are due to calling realpath() which causes 
every dir leading up to the filename to be stat'ed to check if it is a 
link so we can normalize the filename before adding it to the included 
files list.  It's handy and nice to normalize the path here, but it is 
really really expensive!  And this overhead doesn't go away with opcode 
caches either as they still need to go through this step to determine if 
the included file has been cached or not.  I also don't see the point of 
those three fstat64() calls that I guess are a result of the sanity 
checking we do after the fopen.

Due to our current implementation, if you have a lot of includes, you
really should put all your include files in / and you will see some
impressive improvements.  This is annoying, but I am not sure how to fix
it.  A couple of things crossed my mind:

 1. Don't normalize the path names, but instead do a single stat on the
file and record the device and inode of it and use that to match it
up later to check for multiple inclusion and the various opcode
caches would use that as a cache key.

 2. Add a fast_include directive, or something equally lame-sounding, 
which skips the getcwd(), realpath() and sanity checks and just
includes the file.

 3. For absolute paths, don't call realpath() to normalize, just strip
out multiple /'s and any .'s or whatever we think is necessary to
try to normalize it short of having to stat every single dir leading 
up to the file.

 4. Do some sort of caching on this info so it doesn't happen on every 
include on every request.

-Rasmus


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

Re: [PHP-DEV] roadmap of PHP - where? PHP 5 - when?

[Rasmus Lerdorf]

On Thu, 23 Jan 2003, Zeev Suraski wrote:
> Ok, I can't be bothered to fight a mailing list that was supposed to trim 
> down endless discussions. I'm not the one that asked for the list, but I 
> definitely supported it, as unlike most of the members on this list, I 
> remember the pre-v4 days, and what kind of mountains we had to push in 
> order to get it released half a year after it was ready.  But as you said, 
> no matter what valid reasons there are for having this list, we got to a 
> situation where the fuzzy feeling will always outweigh the logic, and 
> nobody will ever be able to persuade anybody otherwise.  Whatever, let's 
> end the list.

You should have learned this by now.  Perception and warm fuzzies is an 
extremely important part of a large open source project that relies 
heavily on a large number of volunteers.  Messing with that is playing 
with fire.  I believe we can get work done on php-dev, especially if 
people can hold back on replying to trolls.

-Rasmus


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

RE: [PHP-DEV] roadmap of PHP - where? PHP 5 - when?

[Rasmus Lerdorf]

On Thu, 23 Jan 2003, John Coggeshall wrote:

> The reason I ask is that Shane Caraveo and I were working on the thread
> saftey issue, but we couldn't talk about it because we weren't invited
> to the PHP5-DEV list

I had nothing to do with that limited php5 list.  I thought that was
completely bogus myself and argued against it.

-Rasmus


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

Re: [PHP-DEV] roadmap of PHP - where? PHP 5 - when?

[Rasmus Lerdorf]

> I would like to know in advance when PHP 5 will be released.

So would we.  We have no idea.  Sometime in the next 4-18 months.  How's 
that?

> Can I find a sort of "roadmap" somewhere? 

We are well past the roadmap and into the TODO stage now.  Our trusted 
secretary, Sebastian, has been maintaining it:

http://www.sebastian-bergmann.de/TODO-PHP5.txt

> Where should I look at regularly to know if it is going
> to be released soon?

This list is fine.

> Can somebody tell me approximately when it will happen? 3 months? Year?

Nope, and if someone does tell you it is pure speculation and you can add 
or subtract 6 months to/from the answer you get.

-Rasmus


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

Re: [PHP-DEV] request data filter

[Rasmus Lerdorf]

>I cannot agree more. There is only so much you can do outside
>the PHP (as I do in mod_security).

I've finished the code.  I'll run it through its paces here and commit it 
soon.

-Rasmus


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

Re: [PHP-DEV] 4.3.1 (was: [PHP-CVS] cvs: php4(PHP_4_3) /main SAPI.h)

[Rasmus Lerdorf]

> > Who said that we're not going to release a 4.3.1 or 4.3.n? I'm just not
> > favoring new code going into the PHP_4_3 branch, but only bugfixes. I'd
> > like to see new functionality going into HEAD, for PHP 5.
> 
> You might favor that, but I don't pretend that PHP 5.x will
> become useful immediately for my purposes.  I need something
> to rely on and that is PHP 4 at this time.

I completely agree.  We can't stall all new development waiting for PHP 5.  
For example, my little user data filter hook thing would be considered a 
new feature that I really can't wait for PHP 5 for.  

-Rasmus


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

Re: [PHP-DEV] request data filter

[Rasmus Lerdorf]

> You could have your custom C extension be called as one of the hooks.

I suppose I could munge with the apache tables directly in a hook before
the data is read by the standard treat_data hook, although for post data I
am not sure I have any way to get in there before the
ap_get_client_block() call and change what data ap_get_client_block() is
going to see.  I also need to make the raw data available via either a
special superglobal or an access function.  This doesn't seem 
straightforward to do through an apache_hook and it would tie something 
that is not inherently Apache-specific to Apache.  A general-purpose 
user-data filter hook would work across all sapi modules.

The main goal here, in case it wasn't obvious, is to prevent
cross-site-scripting problems by forcing all user-originating data to be
cleaned automatically and providing a hoop to jump through in case the
developer really does want the raw uncleaned data.  It isn't something
that belongs in PHP directly as every site that would be interested in
this would likely have different security policies, but I do think a 
general hook is something that would be useful to all of PHP.

A huge number of web apps today are extremely vulnerable to
cross-site-scripting attacks.  Occasionally developers remember to clean
their data before displaying it, but for the most part they don't.  Take
half and hour and find yourself a collection of sites where you can enter
data that is somehow displayed back to you.  Shopping carts that ask for
your name and phone number, or half of php.net's own stuff.  Stick a bit
of javascript in your phone number and watch.

-Rasmus


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

Re: [PHP-DEV] request data filter

[Rasmus Lerdorf]

On Wed, 15 Jan 2003, George Schlossnagle wrote:

> You consider running the apache_hooks code?  This should be simple 
> there.

You mean do the filtering straight from a PHP script that gets called from 
a hook?  That's a lot of looping through a bunch of arrays.  This has to 
happen on every request on the busiest site in the world; it needs to be 
written in C.  

-Rasmus


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

[PHP-DEV] request data filter

[Rasmus Lerdorf]

In trying to implement a security policy I need to pass all user-supplied
data (GET/POST/Cookie) through a filter function which implements this
security.  This isn't all that hard to implement as an extension through
new 4.3 treat_data and post_handler hooks, however it gets messy when you
throw mbstring into the mix as that extension also uses those hooks.

The cleanest way I can think of doing this is to add a function pointer to 
SAPI for the filtering function that will be run right before the 
php_register_variable_safe() call.  Currently we are always calling 
php_url_decode() on the data before registering the variable, so I propose 
that we make php_url_decode() the default that an extension can then 
override.

Anybody see any reason not to make this simple change?  Without that I 
will need to somehow detect whether mbstring is present and then filter 
the data after it has already been registered by mbstring's 
treat_data/post_handler hooks.  That's a big mess!

-Rasmus


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

Re: [PHP-DEV] variables_order annoyance

[Rasmus Lerdorf]

> Check out this bug report:
> 
>   http://bugs.php.net/16155

Ah thanks, that's where I remember the discussion from.  I do disagree 
with one part:

   (c) It shouldn't be possible to prevent $_GET, $_POST,
   $_COOKIE, and $_FILES from being populated.

Why in the world not?  I explicitly need to be able to prevent $_COOKIE
from being populated and showing up in $_REQUEST here at Yahoo because we
have access functions that we want to force people to go through to fetch
cookie data.

I think we should just have a completely clean separation of variable 
ordering priority and superglobal array population.  Before 
register_globals it made sense to just have one setting for this as you 
couldn't have one without the other, but today it doesn't make sense 
anymore.

-Rasmus


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

[PHP-DEV] variables_order annoyance

[Rasmus Lerdorf]

Guys, I think this was brought up before, and I somehow had the impression
that we fixed it, but we didn't.  Currently if variables_order does not
contain a certain type then that type will not be populated in the $_FOO
superglobal.  So, if you set variables_order = "GP" because you only want
Get and Post data in your $_REQUEST array, perhaps, and you have
register_globals off, then $_COOKIE, $_ENV, $_SERVER will not be 
populated.  This is a pain in the ass!  The two concepts should be 
separate.

-Rasmus


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

RE: [PHP-DEV] Re: [PHP-WIN] PHP 4.3.0 no gif support?

[Rasmus Lerdorf]

It's gif read-only, so you only have imagecreatefromgif()

On Mon, 6 Jan 2003, Brian Weil wrote:

> Thanks a million,
>
> Can you tell me which gif functions are available in this build?
>
> Thanks Again,
> Brian
>
> -Original Message-
> From: Edin Kadribasic [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, January 05, 2003 5:59 PM
> To: Brian Weil; Rasmus Lerdorf
> Cc: PHP developer list
> Subject: Re: [PHP-DEV] Re: [PHP-WIN] PHP 4.3.0 no gif support?
>
>
> Hello,
>
> Read-only GIF support has now been enabled in the windows version of the
> bundled GDLIB. Fixed version of php_gd2.dll compatible with PHP 4.3.0
> will be available from
> http://snaps.php.net/win32/php4-win32-STABLE-latest.zip in approx. 8
> hours.
>
> Edin
>
> - Original Message -
> From: "Brian Weil" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Sunday, January 05, 2003 6:31 PM
> Subject: [PHP-DEV] Re: [PHP-WIN] PHP 4.3.0 no gif support?
>
>
> > So...
> >
> > WIll gif support ever be available on win32? Can a patched gd.dll be
> > found somewhere with readonly gif support or will we have to
> > re-install php when the binary is updated? I've been (patiently)
> > waiting for this since GD1.6.
> >
> > Thanks,
> > Brian
> >
> > "Rasmus Lerdorf" <[EMAIL PROTECTED]> wrote in message
> > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > > Hrm..  Whoever built the Windows binary didn't define
> > > HAVE_GD_GIF_READ I guess.  Or perhaps it should go into
> > > main/config.w32.h.in assuming we
> are
> > > always going to build the windows binary against the bundled gd
> > > library.
> > >
> > > -Rasmus
> > >
> > > On Fri, 3 Jan 2003, Zac Barton wrote:
> > >
> > > > hi all, i thought php 4.3 was ment to have read-only access to gif
> > images?
> > > >
> > > >
> > > > all i get via phpinfo(); is:
> > > >
> > > > GD Support  enabled
> > > > GD Version  bundled (2.0 compatible)
> > > > FreeType Support  enabled
> > > > FreeType Linkage  with freetype
> > > > JPG Support  enabled
> > > > PNG Support  enabled
> > > > WBMP Support  enabled
> > > >
> > > > wheres the gif read support?
> > > >
> > > > php 4.3 d/loaded via www.php.net so its the correct version.. what
>
> > > > am
> i
> > > > missing?
> > > >
> > > > does gif read support mean i can load a gif image then output it
> > > > as a
> > PNG?
> > > >
> > > > many thanks in advance
> > > >
> > > > zac barton
> > > >
> > > > --
> > > > PHP Windows Mailing List (http://www.php.net/)
> > > > To unsubscribe, visit: http://www.php.net/unsub.php
> > > >
> >
> >
> >
> > --
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> >
>
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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

Re: [PHP-DEV] new database extension

[Rasmus Lerdorf]

All the extensions are under ext/

Those two specifically are ext/pgsql and ext/oci8

On Fri, 3 Jan 2003, Chandler, Jacob R wrote:

> I want to write a new extension specific to the MIMER database
> (www.mimer.com). This will be similar to the extensions for PostgreSQL,
> Oracle, etc. and will allow native connection as an option instead of
> using ODBC. However, I'm not exactly sure where to start and wanted to
> look at those specific extensions. Can someone tell me where I might
> find this within the PHP source?
>
>
> Jacob Chandler
> Programmer/Analyst I
> Computer Services
> Sam Houston State University
> [EMAIL PROTECTED]
> 936 294-3160
>
>
>
>

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

[PHP-DEV] Re: [PHP-WIN] PHP 4.3.0 no gif support?

[Rasmus Lerdorf]

Hrm..  Whoever built the Windows binary didn't define HAVE_GD_GIF_READ I
guess.  Or perhaps it should go into main/config.w32.h.in assuming we are
always going to build the windows binary against the bundled gd library.

-Rasmus

On Fri, 3 Jan 2003, Zac Barton wrote:

> hi all, i thought php 4.3 was ment to have read-only access to gif images?
>
>
> all i get via phpinfo(); is:
>
> GD Support  enabled
> GD Version  bundled (2.0 compatible)
> FreeType Support  enabled
> FreeType Linkage  with freetype
> JPG Support  enabled
> PNG Support  enabled
> WBMP Support  enabled
>
> wheres the gif read support?
>
> php 4.3 d/loaded via www.php.net so its the correct version.. what am i
> missing?
>
> does gif read support mean i can load a gif image then output it as a PNG?
>
> many thanks in advance
>
> zac barton
>
> --
> PHP Windows Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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

Re: [PHP-DEV] ZE2 + php 4.4.0

[Rasmus Lerdorf]

If it was stable we would release it.  So no, stick with the released
code.

-Rasmus

On Fri, 3 Jan 2003, Tularis wrote:

> would this combination be considered 'stable enough' to use (win32) in a
> small test environement? Or should I just use ZE1 + php4.3
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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

Re: [PHP-DEV] Update: Quoting behaviour exposed

[Rasmus Lerdorf]

Sascha, we need to give you something constructive to work on...

-Rasmus (top-posted with lots of quoted text just for you)

On Sat, 28 Dec 2002, Sascha Schumann wrote:

> After looking at a few messages again, I noticed that my
> script also considered signatures (personal and the mailing
> list's) as "original" lines.
>
> Once these are kicked out, we see a far worse picture (the
> ratios almost double):
>
>  1%: >= 34.60
>  5%: >= 12.50
> 10%: >= 6.75
> 15%: >= 4.50
>
> And the top 10 again (messages with a ratio >= 3):
>
> Jani Taskinen  avg of 18.86 in  3 postings
> John Coggeshallavg of 14.12 in 10 postings
> Xavier Spriet  avg of 12.71 in  8 postings
> Ilia A.avg of 12.22 in  7 postings
> Marcus Börger  avg of 12.03 in 22 postings
> George Schlossnagleavg of 11.78 in  4 postings
> Moriyoshi Koizumi  avg of 10.44 in 14 postings
> Andi Gutmans   avg of 10.22 in 22 postings
> Markus Fischer avg of  9.42 in  5 postings
> Wez Furlongavg of  8.97 in  4 postings
>
> - Sascha
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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

Re: [PHP-DEV] option to start in PHP mode

[Rasmus Lerdorf]

We do already have -r, but I haven't changed my mind on this one either.
Why introduce 2 different kinds of PHP files?

On Fri, 27 Dec 2002, Andi Gutmans wrote:

> I don't think it's beneficial to PHP to have two modes especially as the
> cli more you're talking about would support ?> followed by a  you're saving is the opening tag. I think any PHP programmer can handle it.
> Let's keep things similar across the board.
> Andi
>
> At 02:11 PM 12/27/2002 -0500, Andrei Zmievski wrote:
> >We've talked about this in the past, but let's bring it up again. It is
> >a bit awkward to use CLI when it requires those  tags. We
> >should probably have a command-line option that tells the parser to
> >start in PHP mode instead of HTML/text. Any thoughts on this?
> >
> >-Andrei   http://www.gravitonic.com/
> >* What were the first 15 billion years of the universe like for you? *
> >
> >--
> >PHP Development Mailing List 
> >To unsubscribe, visit: http://www.php.net/unsub.php
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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

[PHP-DEV] Re: [PHP] XML-Presentationsystem from the Conf2002

[Rasmus Lerdorf]

Check it out of cvs.  It is in the pres2 directory.

On Fri, 27 Dec 2002, Tobias Schlitt wrote:

> Hi folks!
>
> I saw the nice-looking presentationsystem, written in PHP and using XML, on
> the PHP-Conference this year. I liked that very much and think it's must for
> every PHP-related presentation. So, can anyone tell me, where to download
> the system? Has anyone got it at home and could send me a quick tar-ball of
> it per mail??
>
> Thanks for your help! Hope you all had merry X-Mas!
>
> Regards,
> Toby
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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

Re: [PHP-DEV] $scalar{index} syntax

[Rasmus Lerdorf]

You mean $string{2} ?  That's the more correct way to do $string[2] to
make it clear that it is a character offset.  This has been supported for
years and will not go away.

-Rasmus

On Tue, 10 Dec 2002, Brad Bulger wrote:

>
> trying to fix bugs in some PEAR code, i noticed the person used a way
> of getting at the individual characters in a string:
>
> $string{2} === substr($string,2,1)
>
> is that old syntax or something? is there any reason to expect it to work
> in future versions?
>
> thanks
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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

Re: [PHP-DEV] Java extension fixes

[Rasmus Lerdorf]

Not that I know much about JVM's, but your patches look reasonable to me.
Go to php.net/php-cvs.php and fill in the little form to get a CVS account
and you can commit these changes yourself.

-Rasmus

On Mon, 25 Nov 2002, Tony J. White wrote:

>
> I'm made a stability fix to the PHP Java extension.  A full description of the
> changes as well as the updated java.c file (and patch) can be found here:
>
> http://tjw.org/php_java/
>
> Can someone please add this to CVS or should I contact Sam Ruby (the orignal
> author) to do it?
>
> -Tony
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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

Re: [PHP-DEV] Patch for gd.c

[Rasmus Lerdorf]

I have committed this, sort of anyway.  I moved the check up as there is
really no reason to go through and even try to do the deallocate on a
truecolour image.

-Rasmus

On Sat, 23 Nov 2002, Moriyoshi Koizumi wrote:

> Hi,
>
> This tiny patch prevents the warnings when applying imagecolordeallocate()
> on true colour values. I suppose this new behaviour would be more
> consistent because we can use imagecolorallocate() with true colour images.
>
> Then what do you guys think about this issue?
>
> Moriyoshi
>
>


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

Re: [PHP-DEV] apache_hooks

[Rasmus Lerdorf]

Apache_hooks is an Apache 1.3 SAPI module which lets you execute PHP code
at every stage of the Apache request handling cycle instead of just the
content handling hook that the normal apache sapi module uses.  It was a
super experimental thing I put together ages ago that George and Lukas
have now cleaned up/rewritten to be much more efficient and complete.

-Rasmus

On Tue, 19 Nov 2002, Stanislav Malyshev wrote:

> What is apache_hooks SAPI module? It looks like it produces errors in
> my build... And no docs there. What's that?
>
> --
> Stanislav Malyshev, Zend Products Engineer
> [EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.109
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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

Re: [PHP-DEV] getimagesize() broken in HEAD

[Rasmus Lerdorf]

It is one I created for a presentation.  Just about to give a tutorial at
Apachecon here in Vegas and the slide with this image on it was broken
because of this bug.  I swear that my 100-slide PHP talk is one of the
best regression test cases we have for PHP.  ;)

-Rasmus

On Mon, 18 Nov 2002, Marcus Börger wrote:

> Fixed.
> Are you on a online book or where does the image come from?
>
> marcus
>
> At 16:23 18.11.2002, Rasmus Lerdorf wrote:
> >Try grabbing this image: lerdorf.com/serverside.png
> >And do a getimagesize() on it.  I am getting a negative value for the
> >width.
> >
> >-Rasmus
> >
> >On Mon, 18 Nov 2002, Marcus Börger wrote:
> >
> > > At 11:20 18.11.2002, Derick Rethans wrote:
> > > >On Mon, 18 Nov 2002, Rasmus Lerdorf wrote:
> > > >
> > > > > getimagesize() works ok in the 4.3 branch, but in HEAD it is returning
> > > > > weird data.  streams problem?  too tired to track it down right now.
> > > >
> > > >It might have something to do with this patch:
> > > >
> > > >http://cvs.php.net/diff.php/php4/ext/standard/image.c?login=2&r1=1.72&r
> > 2=1.73&ty=h
> > > >
> > > >Derick
> > >
> > > But i applied the same patch to 4.3 and branch.
> > > For me both 4.3 and branch are working.
> > >
> >
> >
> >--
> >PHP Development Mailing List <http://www.php.net/>
> >To unsubscribe, visit: http://www.php.net/unsub.php
>


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

Re: [PHP-DEV] getimagesize() broken in HEAD

[Rasmus Lerdorf]

Try grabbing this image: lerdorf.com/serverside.png
And do a getimagesize() on it.  I am getting a negative value for the
width.

-Rasmus

On Mon, 18 Nov 2002, Marcus Börger wrote:

> At 11:20 18.11.2002, Derick Rethans wrote:
> >On Mon, 18 Nov 2002, Rasmus Lerdorf wrote:
> >
> > > getimagesize() works ok in the 4.3 branch, but in HEAD it is returning
> > > weird data.  streams problem?  too tired to track it down right now.
> >
> >It might have something to do with this patch:
> >
> >http://cvs.php.net/diff.php/php4/ext/standard/image.c?login=2&r1=1.72&r2=1.73&ty=h
> >
> >Derick
>
> But i applied the same patch to 4.3 and branch.
> For me both 4.3 and branch are working.
>


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

[PHP-DEV] getimagesize() broken in HEAD

[Rasmus Lerdorf]

getimagesize() works ok in the 4.3 branch, but in HEAD it is returning
weird data.  streams problem?  too tired to track it down right now.

-Rasmus


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

Re: [PHP-DEV] error handling

[Rasmus Lerdorf]

Well, I certainly don't want errors handled this way for my web apps.  And
you would be hard pressed to find 2 people on this list that agree exactly
how to do it which is why PHP provides you with the tools to do it any way
you want.

-Rasmus

On Mon, 18 Nov 2002, Mattia wrote:

> I think in a modern web application the error handling function should do
> the following:
> in case of error (any: parse error, internal application error,)
>
> 1. a message should be shown to the user sayng that an error has occured
> like "an internal error has occured. the webmaster has been notified via
> email"
> 2. a more detailed message should be logged in a generic system ErrorLog, or
> notified via email or fax, or telephone, or SMS. Depending on the severity
> of the error (warning, fatal,...)
>
> All this done with PHP error handling function (this is not to male
> distinction between PHP error and application internal error), and the
> ErrorLog kept via system/server methods (like syslogd). The message shown to
> the user should be accompained by an HTTP 500 (or more) error. This to make
> clear to human users that an error has occured therefore the request cannot
> be fulfilled, and if the cliens is another computer (robot,...) to make it
> as well (computer look at error codes rather than at things written for
> humans.
>
> I know this is possible now, but not within the error handling function of
> PHP, or without setting a custom error handler.
>
> Mattia Cazzola
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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

Re: [PHP-DEV] Re: #20461 [Opn->Bgs]: Unable to access $PHP_AUTH_USERor $PHP_AUTH_PW

[Rasmus Lerdorf]

> > But why do you assume that the documentation was right and the code was
> > wrong and not the other way around?
>
> Because it was working like documented before. (When the documentation
> was written). Anyway, not sure what to do with this one...

I don't have the energy to do a cvs check, but I remember adding this
restriction years ago (php2 days) and then removing it (by commenting out
the check) ages ago as well. I'm not sure PHP4 ever had this check turned
on (the commented out check was ported to php4), so the documentation has
not reflected reality in a very long time.

-Rasmus


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

Re: [PHP-DEV] Re: #20461 [Opn->Bgs]: Unable to access $PHP_AUTH_USERor $PHP_AUTH_PW

[Rasmus Lerdorf]

On Mon, 18 Nov 2002, Derick Rethans wrote:

> On Sun, 17 Nov 2002, Rasmus Lerdorf wrote:
>
> > I'm still not overly convinced that this isn't a restriction that should
> > only kick in when safe_mode or open_basedir is active.  This change is
> > going to break working code and it is not a security fix on non-shared
> > servers.
>
> True, but it was clearly documented that it shouldn't work. Do we really
> have to make a feature out of every bug? I'd say no...

But why do you assume that the documentation was right and the code was
wrong and not the other way around?




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

[PHP-DEV] Re: #20461 [Opn->Bgs]: Unable to access $PHP_AUTH_USER or $PHP_AUTH_PW

[Rasmus Lerdorf]

I'm still not overly convinced that this isn't a restriction that should
only kick in when safe_mode or open_basedir is active.  This change is
going to break working code and it is not a security fix on non-shared
servers.

-Rasmus

On 18 Nov 2002 [EMAIL PROTECTED] wrote:

>  ID:   20461
>  Updated by:   [EMAIL PROTECTED]
>  Reported By:  [EMAIL PROTECTED]
> -Status:   Open
> +Status:   Bogus
>  Bug Type: Apache related
>  Operating System: Linux 2.4.8
>  PHP Version:  4CVS-2002-11-17
>  New Comment:
>
> Then that is an external auth mechanism and means this
> is not a bug in PHP:
>
> From: http://www.php.net/manual/en/features.http-auth.php
>
> "In order to prevent someone from writing a script which
> reveals the password for a page that was authenticated
> through a traditional external mechanism, the
> PHP_AUTH variables will not be set if external
> authentication is enabled for that particular page. In this
> case, REMOTE_USER can be used to identify the
> externally-authenticated user. So, $_SERVER['REMOTE_USER'].
>
> Configuration Note: PHP uses the presence of an AuthType
> directive to determine whether external authentication is in
> effect. Remember to avoid this directive for the context
> where you want to use PHP authentication (otherwise each
> authentication attempt will fail).
> "
>
> There was a bug in previous PHP 4 versions which let the
> external authenticated usernames and passwords to be revealed for
> scripts. This is fixed in PHP 4.3.0.
>
> (btw. you really should upgrade your apache to 1.3.27! And forget
> Apache2, it really is not ready for production use)
>
>
>
>
> Previous Comments:
> 
>
> [2002-11-17 22:45:43] [EMAIL PROTECTED]
>
> forgot to answer your other question.. using apache 1.3.20 -- been
> wanting to upgrade to 2.0 but have had a whole different set of
> problems w/ that, so taking things one step at a time...
>
> 
>
> [2002-11-17 22:43:25] [EMAIL PROTECTED]
>
> tried using $_SERVER already, no dice.
>
> i meant using the mod_auth module in apache to protect certain
> directories.. when those directories are accessed, the browser pops up
> a window for the user to enter in their username/password for that
> resource...
>
> 
>
> [2002-11-17 22:23:00] [EMAIL PROTECTED]
>
> I can not reproduce this, it works fine here.
> Try accessing the variables through $_SERVER variable:
>
> $_SERVER['PHP_AUTH_USER']
> $_SERVER['PHP_AUTH_PW']
>
> And what Apache version are you using?
> What do you mean with "regular http authentication through apache" ??
>
>
> 
>
> [2002-11-17 22:09:27] [EMAIL PROTECTED]
>
> not using any external auth... simply using regular http authentication
> through apache... certain directories on the webserver are protected,
> and so it pops up the box asking the user for username/password.. and
> then rather then ask them AGAIN for a login for some of my web-based
> apps, i simply pass the http auth info (via $PHP_AUTH_USER and
> $PHP_AUTH_PW) along to these apps.  the only problem is, those 2
> variables don't seem to exist anymore for me.  nothing has changed in
> my configuration except for the fact that i'm now using the cvs version
> of php as opposed to 4.2.3 (if you read in my original bug report it
> explains why).
>
> 
>
> [2002-11-17 20:13:05] [EMAIL PROTECTED]
>
> Are you using some external auth mechanism?
>
>
> 
>
> The remainder of the comments for this report are too long. To view
> the rest of the comments, please view the bug report online at
> http://bugs.php.net/20461
>
> --
> Edit this bug report at http://bugs.php.net/?id=20461&edit=1
>


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

Re: [PHP-DEV] PHP and Threading

[Rasmus Lerdorf]

Nope, that is unlikely to happen.  The way to do this correctly is with a
socket_select() anyway.

-Rasmus

On Thu, 14 Nov 2002, Arjen Brouwer wrote:

> Hi,
>
> I was wondering, is PHP in future going to support threading? This would be
> a very nice feature.
> I'am currently working on this project of mine, a FTP Server build in PHP
> which serve MySQL database records. It actually does work very nice, also
> multiple clients at the same time. It supports passive and active FTP.
> But my problem here is that the FTP server only can handle one file transfer
> at a time. Threading would be the solution. Are there any plans implementing
> it?
>
> Cheers,
> Arjen
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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

[PHP-DEV] Re: #20441 [Opn->Bgs]: PHP_AUTH_USER isn't set

[Rasmus Lerdorf]

That's not true.  At least the "From the beginning of time" part.  This
used to be a restriction, then it was lost, now it is back.  You can go
scour cvs for the exact versions affected.

I am personally not entirely happy about this change either.  It is
definitely a security issue for shared server environments, and as such
perhaps the restriction should only be triggered when safe-mode is on.

-Rasmus

On Fri, 15 Nov 2002, Edin Kadribasic wrote:

> Well actually you could. From the beginning of time up to 4.3.0. I
> expect to see a lot of bug reports similar to this one.
>
> Edin
>
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, November 15, 2002 10:10 AM
> Subject: #20441 [Opn->Bgs]: PHP_AUTH_USER isn't set
>
>
> > ID:   20441
> >  Updated by:   [EMAIL PROTECTED]
> >  Reported By:  [EMAIL PROTECTED]
> > -Status:   Open
> > +Status:   Bogus
> >  Bug Type: Apache related
> >  Operating System: Redhat Linux 7.1 kernel 2.4.2-2
> >  PHP Version:  4.3.0-pre2
> >  New Comment:
> >
> > You need to decide if you are using an external auth mechanism or
> http
> > auth from php.  You can't do both.
> >
> >
> > Previous Comments:
> > --
> --
> >
> > [2002-11-15 02:58:24] [EMAIL PROTECTED]
> >
> > I've upgraded PHP 4.2.3 to the beta 4.3.0-pre2 and I've set
> register
> > globals on in php.ini.
> >
> > My Apache version is 1.3.24.
> > PHP configure:
> > ./configure --with-apxs=/usr/local/apache/bin/apxs
> > --with-mysql=/usr/local/mysql --enable-ftp --with-openssl
> >
> > The script is using this .htaccess-file
> >
> > AuthType Basic
> > AuthName 'Urenregistratie'
> > AuthUserFile /htpasswd/urenreg
> > require valid-user
> >
> > I am sure that Apache is setting the PHP_AUTH_USER because the
> > following script gives the correct output:
> >
> > // begin dirty hack
> > $headers = apache_request_headers();
> > foreach ($headers as $header => $value) {
> > if ($header == "Authorization")
> > {
> >$value = str_replace(" ", "", $value);
> >$value = str_replace("Basic", "", $value);
> >$userArray = explode(":", base64_decode($value));
> > $PHP_AUTH_USER = $userArray[0];
> > }
> > }
> > echo $PHP_AUTH_USER;
> > // end dirty hack
> >
> > If I echo $PHP_AUTH_USER or $_SERVER["PHP_AUTH_USER"] above this
> script
> > I am getting a empty result.
> >
> > Note: the script was functioning 100% properly with php 4.2.3
> >
> >
> >
> >
> > --
> --
> >
> >
> > --
> > Edit this bug report at http://bugs.php.net/?id=20441&edit=1
> >
> >
> >
>


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

Re: [PHP-DEV] strpos() suggestion

[Rasmus Lerdorf]

The reason the functions are the way they are is because they directly
mirror the underlying C functions.  strrpos() calls strrchr() directly.
But yes, some sort of new php_memnstr() based string searcher could
probably be written.

-Rasmus

On 13 Nov 2002, Monte Ohrt wrote:

> Hi,
>
> I had a little problem to solve today, and couldn't find any easy way to
> do it without some extra steps slicing things up.
>
> What I wanted to do is take an arbitrary point in a string, and find the
> position of the first '[' on the left of it, and the first ']' on the
> right of it.
>
> Finding the ']' was easy, I use strpos() to find the first occurance of
> ']' after my given point.
>
> Finding '[' however is not so easy. strrpos() was my first guess, but it
> does not work like strpos() at all. There is no optional third
> parameter, and on an unrelated note it only works with a single
> character, not a string. inconsistant ;-) My best solution was to slice
> the string at my point, then get the position of '[' with strrpos().
>
> I'm not sure of the most intuitive way to solve this. One way would be
> to add a feature to strpos(); if you supply a negative third parameter,
> it gives you the position of the first occurance to the _left_ of that
> point. I'm not sure if the number should represent the position from the
> end or beginning of the string. Another way, add a third parameter to
> strrpos() to start at a given point from the end of the string.
>
> I'd try submitting a patch, but I'm not sure of which way would be best,
> and my C is a bit rusty, I'd probably do more damage than help ;-)
>
> Thoughts?
> Monte
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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

[PHP-DEV] #20374 [NEW]: Performance enhancment for php_mysql_do_connect. (fwd)

[Rasmus Lerdorf]

Seems like a good idea to me.  Any volunteers?  Zak?

-- Forwarded message --
Date: 11 Nov 2002 23:45:38 -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: #20374 [NEW]: Performance enhancment for php_mysql_do_connect.

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.2.2
PHP Bug Type: MySQL related
Bug description:  Performance enhancment for php_mysql_do_connect.

While investigating server performance I noticed that my queries per second
was unusually high, as well as my SHOW STATUS commands in MySQL.  After
investigating through the source, I found the function
php_mysql_do_connect, which of course does connections.  Within there,
line 602 of php_mysql.c for 4.2.2, I found a mysql_stat() where the MySQL
connection was tested, and upon failure would reconnect.  My suggestion
for PHP, and what I am placing into my own source, is instead of a
mysql_stat, a mysql_ping is ran, if the API library is above 3.22.3
(http://www.mysql.com/documentation/mysql/bychapter/index.html#News-3.22.3)
 Per the MySQL documentation:

http://www.mysql.com/documentation/mysql/bychapter/manual_Clients.html#mysql_ping


int mysql_ping(MYSQL *mysql)

8.4.3.164 Description
Checks whether the connection to the server is working. If it has gone
down, an automatic reconnection is attempted.

This function can be used by clients that remain idle for a long while, to
check whether the server has closed the connection and reconnect if
necessary.

8.4.3.165 Return Values
Zero if the server is alive. Non-zero if an error occurred.



Since the libmysqlclient API will already reconnect, there is no need for
PHP to do this internally.  If the API version is equal to or above
3.22.3, run a mysql_ping and upon failure, remove the connection from the
zend_hash and return failure.  If it is below 3.22.3 (which is 3 years
old), run the old source.  I know this is not a huge change, but it does
make alittle difference in performance.  Below is a test.c example of how
this functions:


#include 
#include 
#include 
#include 

int main (void) {
MYSQL mysql_connect;
MYSQL_RES *mysql_result;
MYSQL_ROW mysql_row;
my_ulonglong id;
int c;

mysql_init(&mysql_connect);
mysql_real_connect(&mysql_connect,"localhost","root","inT99hB$",
"mysql", 0, NULL, 0);
for (c = 0; c < 3; c++) {
sleep(2);

mysql_ping(&mysql_connect);
printf("Error: %s\n", mysql_error(&mysql_connect));

if (mysql_real_query(&mysql_connect,"SELECT
CONNECTION_ID()",sizeof("SELECT CONNECTION_ID()"))) {
printf("Error querying: %s\n",
mysql_error(&mysql_connect));
} else {
mysql_result =
mysql_store_result(&mysql_connect);
mysql_row = mysql_fetch_row(mysql_result);

id = strtoul(mysql_row[0], NULL, 0);
mysql_free_result(mysql_result);

printf("Id is %lu\n", id);
mysql_kill(&mysql_connect, id);
}
}
}



Example of php_mysql.c
#if MYSQL_VERSION_ID > 32230 /* let mysql_ping check connection and auto
reconnect */
if(mysql_ping(le->ptr)) {
php_error(E_WARNING, "MySQL:  Link to
server lost, unable to reconnect");
zend_hash_del(&EG(persistent_list),
hashed_details, hashed_details_length+1);
efree(hashed_details);
MYSQL_DO_CONNECT_RETURN_FALSE();
}
#else

... normal code...

#endif


Bests,

nickg
-- 
Edit bug report at http://bugs.php.net/?id=20374&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20374&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=20374&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=20374&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20374&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=20374&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20374&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=20374&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20374&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20374&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=20374&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20374&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=20374&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=20374&r=isapi


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

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

[Rasmus Lerdorf]

Linux

On Mon, 11 Nov 2002, Dave Viner wrote:

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


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

Re: [PHP-DEV] Re: apache_hooks

[Rasmus Lerdorf]

Hrm..  That's not a bad idea.  An ApacheHooks SAPI module sounds like the
right approach to me.

-R

On Sun, 10 Nov 2002, George Schlossnagle wrote:

> While most of the code in main/ is changed minimally, the changes to
> the SAPI/apache stuff are pretty extensive.  It may make sense to ifdef
> the changes in main and create a new SAPI module for this.  I bend to
> the majority though.  :)
>
>
> On Sunday, November 3, 2002, at 03:49 AM, Rasmus Lerdorf wrote:
>
> > Well, since 99% of the code is the same, I'd be worried about people
> > remembering to merge fixes across.  At least if it is ifdef'ed people
> > see
> > the code.  But yes, I agree, that's not pretty either.
> >
> > -R
> >
> > On Sun, 3 Nov 2002, George Schlossnagle wrote:
> >
> >> Either way works for me.  Psychologically, I think it may get higher
> >> exposure if it is #ifdef'd, but I have style reservations about doing
> >> that.  How has this sort of thing been done in the past?  Is it
> >> undesirable to fork the apache sapi into a new 'apache_hooks' sapi?
> >> That may be easiest.
> >>
> >> George
> >>
> >> On Saturday, November 2, 2002, at 05:58 PM, Rasmus Lerdorf wrote:
> >>
> >>> What do you think would be the best way to make the apache_hooks code
> >>> more
> >>> accessible to people?  A tarball with the relevant files that
> >>> overwrites
> >>> the standard files, or perhaps it is time to #ifdef it into the main
> >>> branch?
> >>>
> >>> -Rasmus
> >>>
> >>>
> >> // George Schlossnagle
> >> // Principal Consultant
> >> // OmniTI, Inc  http://www.omniti.com
> >> // (c) 240.460.5234   (e) [EMAIL PROTECTED]
> >> // 1024D/1100A5A0  1370 F70A 9365 96C9 2F5E 56C2 B2B9 262F 1100 A5A0
> >>
> >
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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

Re: [PHP-DEV] $HTTP_RAW_POST_DATA

[Rasmus Lerdorf]

Hrm..  Ok, actually Hartmut changed this recently.  See:

http://cvs.php.net/diff.php/php4/main/php_content_types.c?login=2&r1=1.21&r2=1.22&ty=u

It works when you turn on always_populate_raw_post_data, right?

-Rasmus

On Sun, 10 Nov 2002, Kjartan Mannes wrote:
> Using telnet and raw http
>
> REQUEST
>   POST /test_post_data.php HTTP/1.0
>   Host: www.example.com
>   Content-type: spam/spam
>   Content-length: 17
>
>   data=Test&op=Post
>
> PHP 4.2.3 REPLY
>   HTTP/1.1 200 OK
>   Date: Sun, 10 Nov 2002 13:42:26 GMT
>   Server: Apache/1.3.27 (Unix) PHP/4.2.3
>   X-Powered-By: PHP/4.2.3
>   Connection: close
>   Content-Type: text/html
>
>   $_POST:
>   array(0) {
>   }
>   $HTTP_RAW_POST_DATA
>   string(17) "data=Test&op=Post"
>
> PHP 4.3-dev REPLY
>   HTTP/1.1 200 OK
>   Date: Sun, 10 Nov 2002 13:40:17 GMT
>   Server: Apache/1.3.27 (Unix) PHP/4.3.0-dev
>   X-Powered-By: PHP/4.3.0-dev
>   Connection: close
>   Content-Type: text/html
>
>   $_POST:
>   array(0) {
>   }
>   $HTTP_RAW_POST_DATA
>   NULL
>
>
> Since $_POST isn't populated I am assuming neither version of PHP
> recognizes my spam/spam content type, but the current cvs version fails
> to populate $HTTP_RAW_POST_DATA. So either my request is wrong and 4.2.3
> is accepting invalid input, or something has changed in PHP and it isn't
> handling the POST request as expected anymore.
>
> --
> Kjartan <[EMAIL PROTECTED]> (http://natrak.net/)
> :: "Bad Command or File Name. Good try, though."
>


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

Re: [PHP-DEV] $HTTP_RAW_POST_DATA

[Rasmus Lerdorf]

Yes, it has to be a POST request for there to be post data and
$HTTP_RAW_POST_DATA is populated if the mime type of the data is
unrecoginized or if always_populate_raw_post_data is on.

On Sat, 9 Nov 2002, Kjartan Mannes wrote:

> Wednesday, August 28, 2002, 3:15:13 PM, [EMAIL PROTECTED] wrote:
> > is $HTTP_RAW_POST_DATA only filled if REQUEST_TYPE is set to POST?
> > even if 'always_populate_raw_post_data = On'? does anyone have a short
> > info on this? rasmus maybe?
>
> I to would like know when $HTTP_RAW_POST_DATA is supposed to be set. I
> recently upgrade from 4.2.3 to 4.3.0-dev and one of my scripts stopped
> working as $HTTP_RAW_POST_DATA wasn't set when data was POSTed. To fix
> this I had to turn always_populate_raw_post_data on. Any documentation
> on this variable should work?
>
> --
> Kjartan <[EMAIL PROTECTED]> (http://natrak.net/)
> :: "Scandisk is now checking your hard disk. You can start
> praying."
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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

Re: [PHP-DEV] Freeing memory

[Rasmus Lerdorf]

Yup, you will need to FREE_ZVAL() it

On 9 Nov 2002, Tony Leake wrote:

>
> Hi,
>
> I am getting the following output from a php script that calls an
> extension I am writing (I have compiled the extension with
> --enable-debug)
>
>
> /home/phpcvs/php4_head/ext/pipe/pipe.c(245) :  Freeing 0x0822568C (12
> bytes), script=test.php
> /home/phpcvs/php4_head/ext/pipe/pipe.c(244) :  Freeing 0x0822564C (12
> bytes), script=test.php
>
> where lines lines 245 and 244 are:
> MAKE_STD_ZVAL(read);
> MAKE_STD_ZVAL(write);
>
> Does this mean that I need to free the memory from the zvals when the
> script exits, or is this just information?
>
> Thanks for your help
> Tony
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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

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

[Rasmus Lerdorf]

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

On Fri, 8 Nov 2002, Dave Viner wrote:

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


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

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

[Rasmus Lerdorf]

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

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

-Rasmus

On Fri, 8 Nov 2002, Andrei Zmievski wrote:

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


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

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

[Rasmus Lerdorf]

libsmbclient is gpl'ed, correct?  We cannot accept extensions that are
written specifically against a single GPL'ed library.  Sorry.

-Rasmus

On 5 Nov 2002, Martial Rioux wrote:

> Hi,
> I Request CVS account to contribute a new extension base on smbclient from SAMBA. 
>This extension is actualy located in php4/ext/smbc, from my developpement tree.
>
> Supported functions:
> smbc_connect
> smbc_disconnect
> smbc_open
> smbc_close
> smbc_read
> smbc_write
> smbc_seek
>
> I also made basic documentation and samples scripts using this extension.
>
>
> Thanks for any comments or suggestion for adding this extension to the php cvs tree.
>
> PS: By the time your are grant my cvs account other functions will be supported, I 
>Hope! ;-)
>
> Best regards, and thanks for your time
>
> Martial Rioux
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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

Re: [PHP-DEV] MySQL UDF that runs PHP

[Rasmus Lerdorf]

Cool - will play with it a bit here.

On Tue, 5 Nov 2002, David Sklar wrote:

> Based on Edin Kadribasic's PHP "embed" SAPI module, I wrote a MySQL UDF that
> interprets PHP. You can get it here:
>
> --> http://www.sklar.com/myphp-0.1.tar.gz
>
> I'd be curious for any comments or suggestions folks have.
>
> Thanks,
>
> David Sklar
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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

Re: [PHP-DEV] ODBTP, a possible solution for MS-SQL and otherdatabases

[Rasmus Lerdorf]

> So far 3 people have shown interest in ODBTP, however, it is the weekend.  I
> am currently working on packaging it in a tar.gz file.  If the response is
> low I will only release it to those who have shown an interest, and if it
> becomes higher than I will release it to the list.  It is very important to
> me that the people who acquire it actually will use it and provide feedback
> within a reasonable time period.  I do not want to feel like I put it in  a
> "black hole."

I think I am one of the 3 as well, but I am not likely to ever test this.
I am fortunate to never have to deal with anything M$, so you won't get
any test feedback from me. That doesn't mean I don't think this is cool. I
am obviously one that likes new approaches to problems and would encourage
you strongly to keep pushing this. If it works well and solves the
problem, you are going to get traction. People will start contributing
patches and probably extensions for other scripting languages.

-Rasmus


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

[PHP-DEV] Re: apache_hooks

[Rasmus Lerdorf]

Well, since 99% of the code is the same, I'd be worried about people
remembering to merge fixes across.  At least if it is ifdef'ed people see
the code.  But yes, I agree, that's not pretty either.

-R

On Sun, 3 Nov 2002, George Schlossnagle wrote:

> Either way works for me.  Psychologically, I think it may get higher
> exposure if it is #ifdef'd, but I have style reservations about doing
> that.  How has this sort of thing been done in the past?  Is it
> undesirable to fork the apache sapi into a new 'apache_hooks' sapi?
> That may be easiest.
>
> George
>
> On Saturday, November 2, 2002, at 05:58 PM, Rasmus Lerdorf wrote:
>
> > What do you think would be the best way to make the apache_hooks code
> > more
> > accessible to people?  A tarball with the relevant files that overwrites
> > the standard files, or perhaps it is time to #ifdef it into the main
> > branch?
> >
> > -Rasmus
> >
> >
> // George Schlossnagle
> // Principal Consultant
> // OmniTI, Inc  http://www.omniti.com
> // (c) 240.460.5234   (e) [EMAIL PROTECTED]
> // 1024D/1100A5A0  1370 F70A 9365 96C9 2F5E 56C2 B2B9 262F 1100 A5A0
>


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

[PHP-DEV] apache_hooks

[Rasmus Lerdorf]

What do you think would be the best way to make the apache_hooks code more
accessible to people?  A tarball with the relevant files that overwrites
the standard files, or perhaps it is time to #ifdef it into the main
branch?

-Rasmus


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

Re: [PHP-DEV] Console Behavior

[Rasmus Lerdorf]

Running your code here gives me:

8:27am thinkpad:~> ./foo


Attach code? > 12345


12345


8:27am thinkpad:~>

Seems to work fine.

-Rasmus

On 31 Oct 2002, Adam Voigt wrote:

> Now I have this, same behavior as before, maybe I'm using the flush
> function incorrectly but the manual seems to suggest this
> is the way to use it:
>
> #!/usr/local/php_4.2.3/bin/php -q
> 
> error_reporting(E_ALL);
>
> echo "\n\nAttach code? > ";
>
> flush();
>
> $f = fopen("php://stdin","r");
> $data = fread($f,5);
> fclose($f);
>
> echo "\n\n$data\n\n";
>
> ?>
>
> On Thu, 2002-10-31 at 10:21, Rasmus Lerdorf wrote:
> > flush()
> >
>


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

Re: [PHP-DEV] Console Behavior

[Rasmus Lerdorf]

flush()

On 31 Oct 2002, Adam Voigt wrote:

> Is this normal?
> I have:
>
> #!/usr/local/php_4.2.3/bin/php -q
> 
> error_reporting(E_ALL);
>
> echo "\n\nAttach code? > ";
>
> $f = fopen("php://stdin","r");
> $data = fread($f,5);
> fclose($f);
>
> echo "\n\n$data\n\n";
>
> ?>
>
> And it refuses to echo "Attach code?" until after
> I hit 5 keys on the console and hit enter, when infact
> it is supposed to be a prompt for the 5 keys (ie,
> display before you enter the keys) Is this expected?
> If yes, any workaround?.
>
> Adam Voigt
> [EMAIL PROTECTED]
>
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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

RE: [PHP-DEV] php/ext/xslt and TSRM

[Rasmus Lerdorf]

Well, in the threaded case you avoid a rather expensive ts_resource_ex()
function call, so what you gain is performance.  Functionality should be
the same.

-Rasmus

On Wed, 30 Oct 2002, David Viner wrote:

> perhaps i'm a bit slow... what is the gain by moving the TSRMLS_FETCH() from
> functions to having the TSRM params in the php_xslt struct?  that is, what
> functionality or benefit is brought to the extension or the code? Is there
> something that the extension does not handle properly as it stands?  or is
> the idea simply to remove lots of TSRMLS_FETCH() calls?
>
> btw - we should move this discussion from php-dev to sab-php.  that's where
> we're trying to maintain all php/sablotron maintanence issues.
>
> dave
>
>
> -Original Message-
> From: Marcus Boerger [mailto:marcus.boerger@;t-online.de]
> Sent: Wednesday, October 30, 2002 7:38 AM
> To: Melvyn Sopacua
> Cc: Sterling Hughes; [EMAIL PROTECTED]; David Viner
> Subject: Re: [PHP-DEV] php/ext/xslt and TSRM
>
>
> At 15:54 30.10.2002, Melvyn Sopacua wrote:
> >At 15:10 30-10-2002, Marcus Boerger wrote:
> >
> >>What about removing all TSRMLS_FETCH() and instead passing
> >>TSRM parameters in php_xslt struct?
> >
> >Before you do that, I'd rather you wait untill after the weekend - unless
> >there's a compelling reason not too.
> >
> >I'm working on exposure of Sablotron SXP_ functions, and this may alter
> >quite a few things in the files.
> >
> >A complete overhaul of the thread issues is then welcome, but I think David
> >is capable of this also.
>
> When it shall be done by me tell me when i can proceed. I suggest a diff
> to check before comitting would be the way to go with this issue.
>
> marcus
>
>
> >With kind regards,
> >
> >Melvyn Sopacua
> >
> >
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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

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

[Rasmus Lerdorf]

> This is just another example why we should use certain ini.
> I think we agreed to use certain php.ini, such as php.ini-test.
> Not setting one by one.

There was no such agreement.  In fact, for proper testing each test should
explicitly define which ini settings it depends on so that we can test for
bugs caused by unintended ini setting side-effects.  By limiting all tests
to run with a known ini environment we are not performing a real-world
test.

-Rasmus


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

Re: [PHP-DEV] Karma for php4 and bcompiler

[Rasmus Lerdorf]

I'll add the pear karma once I figure out which of his 2 cvs accounts he
uses.

On Wed, 30 Oct 2002, Alan Knowles wrote:

> Ernani helped out with bcompiler - so karma on that is ok.
>
> I think for php4 you will have to send patches to php-dev for the time
> being.  until they get used to you :)
>
> Regards
> Alan
>
> Ernani Joppert Pontes Martins wrote:
>
> >Hi there, with not so much time to dedicate to php improvements and bug
> >fixes I want to have karma to help fix some bugs/improvements into php and
> >into bcompiler for win32 that is my speciallity.
> >
> >I've already did a compile with windows but now I need to add some more
> >functionalities.
> >
> >Alan Knowles already said to me to keep in touch.
> >
> >Thanks,
> >
> >Ernani
> >
> >
> >
> >
> >
>
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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

Re: [PHP-DEV] Re: Forked ext/gd by default

[Rasmus Lerdorf]

Whoa, pigs are flying over the skating rink in hell.  Anybody have some
time to go over this and sync things up?

On Mon, 21 Oct 2002, Peter Neuman wrote:

> Hello,
>
> "Andrei Zmievski" <[EMAIL PROTECTED]>:
> > I think we should use forked version of gd library by default for 4.3.0.
> > From what I hear it is already the best version of any of them out there
> > and if it saves us any more grief, all the better. Objections?
>
> +1
> BTW: Update to gd-2.0.2 final?
> See: http://www.boutell.com/gd/
>
> Cu
> Peter Neuman
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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

Re: [PHP-DEV] php_value vs. php_admin_value

[Rasmus Lerdorf]

admin directives can only be used in the httpd.conf file.  Non-admins can
be used in both httpd.conf and .htaccess.  ie. directives that end-users
should not be able to change themselves should be admin ones.

-Rasmus

On Mon, 21 Oct 2002, Jani Taskinen wrote:

>
> Can someone explain what the difference between
> these 'php_value' and 'php_admin_value' directives is?
> (and same goes of course for php_flag vs. php_admin_flag..)
>
> --Jani
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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

Re: [PHP-DEV] Idea to extend language: Explicitly setting variablescope inside user defined function (longer)

[Rasmus Lerdorf]

How in the world do you know that "code will run faster" ?

Implementing your suggestion would take quite a lot of changes to the
internals of PHP.  Instead of just a global and a current symbol table, we
would now need basically an unlimited number of symbol tables and every
variable lookup would become more complex.  Ergo it would slow things
down.

-Rasmus

On Mon, 21 Oct 2002, NTPT wrote:

> Hi.
> I have some idea and suggestion  how to extend PHP language a bit in some
> way. That may probably lead to increasing of php flexibility, allow more
> modular coding to be done etc
>
>
> My sugestion is simple:
> Allow  PHP programmer to explicitelly  told , WHAT variable scope will be
> used  inside user defined  functions.
>
> In the traditional approach (afaik , i use php 4.2.2 ), as is described in
> the manual of php there a diferent varable scopes for each functions , only
> syntax " global $valuename" ; can lead to use variables global. This aproach
> is traditional and well known and is sufficient for most tasks.(I say
> sufficient, not effective...). My idea is going a bit behind it.
>
> I suggest  to introduce new keyword(s) or function(s)  into the PHP language
> definiton
> (i suggest syntax like  "var_scope scope" or  var_scope("scope") )
>
> That keywords SHOULD be used in user defined  functions to  EXPLICITLY
> define, WHAT kind of variable scope will be used inside this function.
>
> scope can be either
>
> 'local' = it means, that all variables used in this function  have a local
> scope only.(it means like traditional behavior of php and its variable
> scopes until now )
>
> 'global' = each variable used in the function  is from global scope. Similar
> to "global $variable_1,$variable_2... $each variable used in the
> main execution line of the script"
>
> 'caller' or 'inherit' This is MOST USEFUL part of the idea . Function
> variable scope is the SAME as from where the function was called. (if
> functino bar(),with have var_scope set to 'caller', is called from function
> foo() it have the same variable scope as function foo(), almost like the
> code of function bar() was included (by include "something" ) somewhere
> inside foo() )
>
>
> A little example code for demonstrating idea of the syntax and how it should
> work:
> */
> 
> $a=10;
>
> echo "Varaible $a".$a;
> .
> $foo_output =foo();
> echo "value returnded by foo() ".$foooutput;
> echo "value $a after  calling  foo() but before calling bar() ".$a;
>
> $bar_output=bar();
> echo "value returnded by bar() ".$bar_output;
> .
> .
> echo "value $a after  calling  bar() ".$a;
>
> function foo()
>  {
>  $a=20;
>  echo "$a inside function foo() = ".$a
>  /* $bar_inside foo = bar();
>  echo "Variable $a inside function foo() after calling bar()".$a;
>
>  */
>  .
>  .
>
>  return $a;
>
>  }
>
>
> function bar()
>  {
>  var_scope caller // we have the SAME variable scope  as from where we are
> called
>  $a=100;
>  .
>  .
>  .
>  return $a;
>  }
> ?>
> this should return :  (with comments behind // )
>
> Varaible $a" 10
> $a inside function foo() = 20
> value returnded by foo() 20
> value $a after  calling  foo() but before calling bar() 10
> value returnded by bar() 100
> value $a after  calling  bar() 100  //  var_scope is set to 'caller', so $a
> in global scope is modified inside bar() the some way, as if global $a was
> used )
>
> if you uncomment lines in  bar()
>
> Varaible $a" 10
> $a inside function foo() = 20
> Variable $a inside function foo() after calling bar() 100  // var_scope in
> function bar() is set to caller, so $a IN SCOPE of foo() ONLY  is modified
> inside bar().
>
> value returnded by foo() 100
> value $a after  calling  foo() but before calling bar() 10 // var_scope in
> function bar() is set to caller, so $a IN GLOBAL SCOPE is NOT modified
> inside bar().
> value returnded by bar() 100
> value $a after  calling  bar() 100  // var_scope is set to caller, so $a in
> global scope is modified inside bar() the some waz, as if global $a was used
>
>
> For WHAT it could be useful ??
>
>
> for example for writing a  databaze extraction layer of any aplication.
> common  real life situations are similar like in this  example code
> (simplified  and abstracted from real life code of PHP application I
> currently write  )
>
>  .
> .
> .
> .
> do something
> .
> .
> .
> // now you need a call subroutine
>
> $something=foo('cats','dogs','horses');
> .
> $different=bar('mices','meat','gras');
> .
> .
> .
> .
>
> function foo($data_1,$data_2,$data_3)
>  {
>  global $spojeni;
>   .
>   .
>   do something here with $data_1,$data_2,$data_3.
>   .
>   .
>   .
>
>
>  $sqlstring="select * from example_table where mouse_catching='$data1' AND
> sniffing='$data_2' AND riding='$data_3'"
>  $result=pg_exec($spojeni,$sqlstring);
>
>  // code, that validate if db done that we want, if select return exactly
> one line or if there is a some data inconsistrency etc etc. The following
> code (wery simplified snipplet fro

Re: [PHP-DEV] PHP_AUTH_(USER|PW) not set

[Rasmus Lerdorf]

As in any Apache mod_auth module.

On Sun, 20 Oct 2002, Martin Jansen wrote:

> On Sat Oct 19, 2002 at 11:0608AM -0700, Rasmus Lerdorf wrote:
> > You probably have an external auth module operating on the same request.
>
> I don't think so. Could you perhaps be a bit more verbose what you
> mean with "external auth module"?
>
> --
> - Martin   Martin Jansen
> http://martinjansen.com/
>


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

Re: [PHP-DEV] PHP_AUTH_(USER|PW) not set

[Rasmus Lerdorf]

You probably have an external auth module operating on the same request.

On Sat, 19 Oct 2002, Martin Jansen wrote:

> The following script fails with the todays snapshot and with PHP
> 4.3.0-pre1:
>
>  if (!isset($PHP_AUTH_USER)) {
> header("WWW-Authenticate: Basic realm=\"Foobar\"");
> header("HTTP/1.0 401 Unauthorized");
> echo "Access denied.";
> exit;
> } else {
> echo "Hello";
> }
> ?>
>
> I looks like $PHP_AUTH_(USER|PW) are not set
> properly. Register_globals is set to on, but the same problem also
> occurs when setting it to off and using $_SERVER['PHP_AUTH_USER']
> then. (Apache 1.3.26, Linux)
>
> Any clues?
>
> --
> - Martin   Martin Jansen
> http://martinjansen.com/
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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

Re: [PHP-DEV] duplicate string, no dupe, ?

[Rasmus Lerdorf]

On Fri, 18 Oct 2002, Rasmus Lerdorf wrote:

> I'm trying to optimize some code for an *extremely* busy site.  This site
> has a bunch of data in shared memory to make it available across all the
> httpd's.  I need to provide this data in the form of arrays to user-space
> PHP through an extension obviously.  Rather trivial to do, but my problem
> is that I need to estrndup() this stuff to make PHP happy.  This is
> slowing me down.  If I don't dupe the data then PHP will try to efree() it
> which is a no-no since this is an external pointer.
>
> Instead of a normal array_init(return_value) could I zend_hash_init() my
> own hash and still set it to be an array but provide my own DTOR function
> which will not free these pointers?

Never mind, I had made a dumb mistake in my test code.  This approach does
work.

-Rasmus


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

[PHP-DEV] duplicate string, no dupe, ?

[Rasmus Lerdorf]

I'm trying to optimize some code for an *extremely* busy site.  This site
has a bunch of data in shared memory to make it available across all the
httpd's.  I need to provide this data in the form of arrays to user-space
PHP through an extension obviously.  Rather trivial to do, but my problem
is that I need to estrndup() this stuff to make PHP happy.  This is
slowing me down.  If I don't dupe the data then PHP will try to efree() it
which is a no-no since this is an external pointer.

Instead of a normal array_init(return_value) could I zend_hash_init() my
own hash and still set it to be an array but provide my own DTOR function
which will not free these pointers?

-Rasmus


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

Re: [PHP-DEV] short_open_tag

[Rasmus Lerdorf]

On Fri, 18 Oct 2002, Andi Gutmans wrote:

> At 01:09 AM 10/18/2002 +0200, Zeev Suraski wrote:
> >At 18:49 17/10/2002, Rasmus Lerdorf wrote:
> >> has whitespace.
> >
> >And I personally think it's a bit pushing it.  How likely is it for
> >someone to have a function called xml(), and then call it without a space
> >from the  >can safely ignore that one...
>
> I don't see why it's such a big deal for people who are creating xml to
> turn-off short tags?

The big deal is not really XML.  It is XHTML and authoring tools that try
to be too smart and stick an XML character encoding tag at the top of a
file automatically.

-Rasmus


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

Re: [PHP-DEV] short_open_tag

[Rasmus Lerdorf]

> On Thu, Oct 17, 2002 at 09:43:02AM -0700, Rasmus Lerdorf wrote:
> > My main worry with such a hack would be breaking a script like this:
> >
> >> function xml() {
> > echo "Hello World";
> > }
> >   ?>
> >   ...
> >   
> >   ...
>
> The hadler I suggest will no break any old code. Even
>  will continue to work.
> It would only trigger on  has whitespace.


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