Re: [PHP-DEV] Xdebug extension availability

[php4]

Addressed to: Derick Rethans <[EMAIL PROTECTED]>
  PHP Developers Mailing List <[EMAIL PROTECTED]>

** Reply to note from Derick Rethans <[EMAIL PROTECTED]> Wed, 1 May 2002 16:20:52 
+0200 (CEST)

I just looked at the message I just sent, and in a few places 
I see /configure where I swear I typed ./configure.







Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

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

Re: [PHP-DEV] Xdebug extension availability

[php4]

Addressed to: Derick Rethans <[EMAIL PROTECTED]>
  PHP Developers Mailing List <[EMAIL PROTECTED]>

** Reply to note from Derick Rethans <[EMAIL PROTECTED]> Wed, 1 May 2002 16:20:52 
+0200 (CEST)
>   
> Hello,
>   
> I'm happy to announce the availability of the xdebug extension. This 
> extension modifies the php error handler to show stack traces. With
> this  you can exactly see how the current function was called, even the
>  parameters show up (if they are constants). I'm still working on
> variable  parameters. 

Does this require 4.2.0 or something?  I just tried to apply this to
4.1.2 and I get:

/configure enable-xdebug

..
..
..

checking whether to enable eXtended debugging support... yes, shared
/configure: line 902 syntax error near unexpected token
'PHP_NEW_EXTENSION(xdebug,'
/configure: line 902 '  PHP_NEW_EXTENSION(xdebug, xdebug.c srm_list.c,
$ext_shared)'

I also tried to use this module static by adding the cdebug directory in
php4/ext/, running ./buildconf then ./configure.  I get the same errors
on a different line of configure.

(I prefer an all static build for my servers.)


Thanks,
Rick


Who still hopes to see this a standard part of PHP as soon as possible!



Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

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

Re: [PHP-DEV] Re: Xdebug extension availability

[php4]

Addressed to: [EMAIL PROTECTED]
  PHP Developers Mailing List <[EMAIL PROTECTED]>

** Reply to note from [EMAIL PROTECTED] Wed, 1 May 2002 16:50:37 +0200 (CEST)
>   
> On Wed, 1 May 2002, Yasuo Ohgaki wrote:
>   
> > Nice extension. I was thinking to make a similar one.
> > 
> > Can you put it into PECL?
>   
> I can, but I don't want it yet. I want to wait until the extension 
> stabilized some more, and PECL is more ready.

Please, Please, Please when this is ready put it in ext/.  I've wanted
this for a long time, and I've seen enough requests from others to know
I'm not the only one.  Having a stack trace available will be a great
help in debugging!


Thanks,

Rick

Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

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

Re: [PHP-DEV] bugs: try newer version (?)

[php4]

Addressed to: "fabwash" <[EMAIL PROTECTED]>
  <[EMAIL PROTECTED]>

** Reply to note from "fabwash" <[EMAIL PROTECTED]> Mon, 29 Apr 2002 06:56:47 -0400
>   
> I can't get them to upgrade my server to 4.1.2 because I share my box
> with 255 other > websites and they won't upgrade until the next
> Scheduled batch unless it's an emergency.
>   
> I don't know if it's good or bad to not commit patches for older
> branches, but I will try to make my patches work on older releases and
> document them accordingly. However, if QA doesn't run tests on older
> releases (I don't know if they do or not), then it could be dangerous.

I would guess that if your ISP won't upgrade a server except in a batch
they won't apply patches unless they are an emergency.  My guess
upgrade means any kind of chages to the server at all.  If that is true
patches to a previous version are a waste of time for everyone involved.


Rick

Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

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

Re: [PHP-DEV] Who vote for this? (was Re: [PHP-DEV] Discourage use

[php4]

** Reply to note from Yasuo Ohgaki <[EMAIL PROTECTED]> Sun, 28 Apr 2002 12:03:48 
+0900

> discussion.
>   
> short_tag option should be kept. Most of us agree, it seems. Should we
> keep double standard _forever_ and have
>   
> ' ?>
>   
> as standard syntax for XML files preprocessed by PHP?
>   
> I can't think of better way. If there are, Please let me know. I'll
> document it.


'?>





Rick



P.S.  Seriously, I think your example _is_ the best choice for creating XML
documents from PHP.
   

 

Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

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

Re: [PHP-DEV] Re: Discourage use of short tags

[php4]

Addressed to: Yasuo Ohgaki <[EMAIL PROTECTED]>
  [EMAIL PROTECTED]

** Reply to note from Yasuo Ohgaki <[EMAIL PROTECTED]> Sun, 28 Apr 2002 09:24:21 
+0900
>   
> It's Zeev's version. Everyone happy with this?
>   
>   Using short tags should be avoided when developing
> applications or  libraries that are meant for redistribution, or
> deployment on PHP  servers which are not under your control, because
> short tags may not be  supported on the target server. For portable,
> redistributable code, be  sure not to use short tags.  


+1



In answer to your question about why I prefer short tags, PHP is my
template engine.  I write two distinct styles of PHP code.  One is mostly
code, in which having one  /  alternate syntax in these files extensively
because they result in more compact code that doesn't obscure the HTML
content I'm trying to paint.

My complaint isn't so much about having to type four more characters each
time as it is about making lines longer causing them to break, and having
to scroll around the source code more when trying to understand it.  



Rick


Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

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

Re: [PHP-DEV] Discourage use of short tags

[php4]

** Reply to note from Zeev Suraski <[EMAIL PROTECTED]> Sat, 27 Apr 2002 05:52:11 +0300
>   
> I don't think we should do it in PHP 5 either. 


I strongly agree!



Rick

Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

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

Re: [PHP-DEV] Discourage use of short tags

[php4]

Addressed to: Yasuo Ohgaki <[EMAIL PROTECTED]>
  [EMAIL PROTECTED]

** Reply to note from Yasuo Ohgaki <[EMAIL PROTECTED]> Sat, 27 Apr 2002 07:47:08 
+0900
>   
> I've changed basic-syntax.xml a little. The manual list short tag first,
> even if it recommends
> Anyway, I would like to add something like
>   
>   Use of short tag is strongly discouraged. It not only
> non-portable and non-XML compliant, but also a obsolete feature. 
> 
>   
> There are too many hosting services that enable short tag by default. In
> many case, user cannot do anything..
>   
> Any comments?

-maxint!


IM(ns)HO  There aren't enough hosting services that support short tags!  

If you don't like them don't use them, but don't force me to follow your
programming rules.  Short tags have been available for a long time, and
work just fine, thank you.


I also strongly prefer http://www.developersdesk.com

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

Re: [PHP-DEV] feature request for __LINE__, __FILE__ and trigger_error

[php4]

Addressed to: [EMAIL PROTECTED]
  [EMAIL PROTECTED]

** Reply to note from [EMAIL PROTECTED] Wed, 24 Apr 2002 21:06:41 +0200 (CEST)
>   
> Hello Michael,
>   
> I'm working (80% done) on an extension for this. It should be finished in
>  a few days. It doesn't feature the __C*__ things yet, but I can add a 
> function for that too.
>   
> I'll keep you posted,




Thanks, I've wished for this for a long time!


Rick

Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

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

RE: [PHP-DEV] codenames (Was:Preview version of Zend Engine 2 powered

[php4]

** Reply to note from [EMAIL PROTECTED] Sun, 31 Mar 2002 13:06:11 +0200 (CEST)
>   
> On Sat, 30 Mar 2002 [EMAIL PROTECTED] wrote:
>   
> > > > Codenames are cool, but using our own names is no-so-cool.  We should
> > > > pick a theme though, but please not Australian wildlife (we're already
> > > > using that for the alltheweb.com frontend ;-).
> > 
> > -1 on code names at all.
> > 
> > What came first woody or potatoe?  You can't tell from the name.  There
> > is no doubt 4.2.0 is newer than 4.1.6.  Why introduce unneeded
> > ambiguity for those who don't follow PHP closely.
>   
> Oh come on... some people just don't have any sense of humur at all.
> Of  couurse we wouldn't remove the version numbers altogether.

That's fine as long as version numbers get mentioned along with the
code name. Every reference to Debian I see talks about just the code
name which doesn't mean a thing to me.  I've lost all interest in
Debian because of it.

Rick

Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

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

RE: [PHP-DEV] codenames (Was:Preview version of Zend Engine 2 powered PHP)

[php4]

Addressed to: "Lukas Smith" <[EMAIL PROTECTED]>
  <[EMAIL PROTECTED]>

** Reply to note from "Lukas Smith" <[EMAIL PROTECTED]> Sat, 30 Mar 2002 11:45:13 +0100
>   
> > >
> > >   PHP 4.1.0 was released on Derick's birthday, so it should've been
> > >   ''Codename Derick'', ... :-)
> >=20
> > Codenames are cool, but using our own names is no-so-cool.  We should
> > pick a theme though, but please not Australian wildlife (we're already
> > using that for the alltheweb.com frontend ;-).

-1 on code names at all.

What came first woody or potatoe?  You can't tell from the name.  There
is no doubt 4.2.0 is newer than 4.1.6.  Why introduce unneeded
ambiguity for those who don't follow PHP closely.


Rick

Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

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

Re: [PHP-DEV] CLI & max_execution_time

[php4]

** Reply to note from Rasmus Lerdorf <[EMAIL PROTECTED]> Tue, 26 Mar 2002 01:41:59 
-0800 (PST)

> > Complete agree here. This is the sensible thing to do, albeit
> > somehow aethetically disturbing. :-)
>   
> Depends how you look at it. To me, this is a PHP script:
>   
> Hello World
>   
> Unlike any other scripting language, PHP gets out of the way of the
> most common operation, that of outputting stuff. It also means that
> PHP has the absolute shortest and simplest Hello World you can have.

Please don't change this.  I have a number of scripts that use this
feature to great advantage.


Rick

 

Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

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

Re: [PHP-DEV] CLI & max_execution_time

[php4]

** Reply to note from Kristian =?iso-8859-1?Q?K=F6hntopp?= <[EMAIL PROTECTED]> Mon, 25 Mar 
2002 10:45:04 +0100


> A CLI version of PHP is a kind of scripting shell at the same level
> as awk, perl and other scripting languages are. It should not behave
> webbish at all, but shelly instead. 

> It should not output a content type by default (automatic -q option), 

+1

> it should read /etc/php.ini and $HOME/.php.ini.

+maxint


Of course if you specify a php.ini file location when you ./configure
that should override /etc/php.ini.


Rick
 

Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

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

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

[php4]

** Reply to note from Markus Fischer <[EMAIL PROTECTED]> Fri, 11 Jan 2002 
12:48:15 +0100
>   
> What other way do we have to specify arbitray optional parameters
> without an ordering? Teh disadvantage of optional parmeters is when
> you need to only set the last one, you'll have to define all
> preceding optional parameters too.


Consider allowing this:



function foo( $one=1, $two=2, $three=3 ) {

echo "$one $two, $three";
}

foo( ,,5 );   # prints: 1 2 5



No value between commas in the parm list says take the default.
Required params must be filled in, but not specifying a value for an
optional parm takes the default from the function header.

It still requires the parms to be in the correct order, but you can
pick and chose which optional parms you want non-default values for.
The disadvantage is having to have the right number of commas before
your values, but at least you don't have to list all the defaults. (and
prevent yourself from being able to change a default just by changing
the function itself.)

The idea is stolen from HP's MPE operating system which I was sorry to
see depreciated recently.


Rick

Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

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

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

[php4]

Addressed to: Markus Fischer <[EMAIL PROTECTED]>
  [EMAIL PROTECTED]

** Reply to note from Markus Fischer <[EMAIL PROTECTED]> Thu, 3 Jan 2002 
22:00:27 +0100

> > Because not everyone wants to use *(#$&ing objects in a simple script!
>   
> Why?

Count me as one of the people who would not be using PHP if it forced
me to always use objects.  I think object oriented programming is
over-rated, especially the purist version.  You know, the people who
don't think they can live without private methods and have a heart
attack if you directly access a variable in an object.

That does not mean that I never use objects, I have a few things in my
library where they come in very handy.  Mostly as a way of providing a
place to store data outside of the global scope, but available to many
functions.

If you are going to use objects you need to think about them quite a
bit before you start coding.  After all re-use is supposed to be one of
the big reasons for OOP.  Sometimes it just isn't worth it.  

I certainly see no advantage in writing the following program with OOP:




It doesn't make the job easier, and it certainly isn't easier to
understand the source code.



I don't even see an advantage here:




Database Dump



   Field1
   Field2
   Field3




   
   
   









A lot of web programming doesn't take much more that this.  Why make it
more complicated by using objects?  A few well thought out functions
(Query, UnpackQuery) in a library (mysql.plib) can go a long way
towards creating simple but robust programs in a lot of cases.  



Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

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

Re: [PHP-DEV] Always building command line PHP

[php4]

** Reply to note from Jon Parise <[EMAIL PROTECTED]> Thu, 3 Jan 2002 16:39:20 -0500
>   
> I agree that it's sometimes necessary to have different configuration
> files, but I don't consider it a necessity.

I do.


> It should still be possible to build a separate CGI executable with a
> different php.ini path for those sites that require it.
>   

Don't get too stuck on the idea that PHP at the command line is only
for CGI.  In fact I don't do CGI any more.  I am phasing out ALL perl
CGI scripts because after seeing PHP as a module I can't stand the
extra time it takes to execute the external program.  PHP CGI has the
same problem. I just say NO to all CGI.

I've also quit using PERL for system programming, and moved most of the
existing perl scripts I have written over to PHP.  I haven't written a
new PERL script since php 4 came out, and may never do it again.  There
isn't much I've done in PERL that I can't do in PHP, and it is quite
annoying to try to remember all the syntax differences. There is
substantial truth to the statement that PERL is a "write only"
language.  I can still understand my PHP code six months later, unlike
a lot of PERL code.

> Your suggestion of a separate php-cli.ini has merit, but who will the
> php binary know when it's being used for CLI purposes and not as a
> CGI?

None of the apache related environment variables will be set?  You
could pick one and switch based on its existance.


I still think that there are three distinct ways to use PHP:

   Apache Module

   CGI executable

   Command line

and the differences justify separate ./configure options.  Maybe Module
and CGI are close enough to share a configuration, I don't do CGI so I
can't say.  Certainly there are drastic differences between module and
command line.




 

Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

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

Re: [PHP-DEV] Always building command line PHP

[php4]

Addressed to: [EMAIL PROTECTED]
  [EMAIL PROTECTED]

** Reply to note from J Smith <[EMAIL PROTECTED]> Thu, 03 Jan 2002 16:26:38 -0500

> I would prefer separate php.ini files, maybe something like
>  php-cli.ini for the default CLI file and and php.ini for the
> Apache/web  server module default. If php-cli.ini doesn't exist, the
> CLI can always  fall back on php.ini, which would be the default in
> any case.

That would work for php.ini, I guess.  If it comes to that I would like
to have separate paths for the files as I consider my apache module php
to be part of apache and keep its .ini file in /web/conf with
httpd.conf and such.  /usr/local/bin/php is a system program which
keeps its .ini file in /etc.

It still doesn't account for the fact that I use drasticly different
/configure options for the two versions.


 

Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

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

Re: [PHP-DEV] Always building command line PHP

[php4]

** Reply to note from Jon Parise <[EMAIL PROTECTED]> Thu, 3 Jan 2002 15:36:32 -0500
>   
> On Wed, Jan 02, 2002 at 04:39:24PM +, [EMAIL PROTECTED]
> wrote:
>   
> > One thing to consider, at least the php.ini location needs to be
> > different between the module and command line compiles.  I suspect most
> > people will have quite a few other differences in ./configure options
> > between them too.  I know I do.
>   
> I don't see the necessity of requiring different php.ini files.
>   
> You can specify the php.ini by using the -c option to the php binary,
> as well.
>  

Yes, but I'm too lazy to have to type it into every program I write,
and if I do put it in every program I have to change it in each if I
decide to move the .ini file.


Also note that I said "at least" the .ini location.  I find my
/configure options to be quite different between the apache module and
the command line builds. I don't use PHP as a CGI, all my command line
programming is run from shell scripts or cron.

Rick

Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

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

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

[php4]

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

Because not everyone wants to use *(#$&ing objects in a simple script!



Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

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

Re: [PHP-DEV] Always building command line PHP

[php4]

** Reply to note from Jon Parise <[EMAIL PROTECTED]> Wed, 2 Jan 2002 15:32:58 -0500
>   
> On Wed, Jan 02, 2002 at 09:33:32PM +0200, Andi Gutmans wrote:
>   
> > Creating a CLI sapi module w/o all of the CGI crap is extremely easy.
> > What might be more challenging is fixing the build so that it always builds 
> > the cli.
>   
> Let's focus on the best way to do this before addressing the plethora
> of other issues related to bringing PEAR up to par.


One thing to consider, at least the php.ini location needs to be
different between the module and command line compiles.  I suspect most
people will have quite a few other differences in ./configure options
between them too.  I know I do.

Maybe just changing the INSTALL instructions from "here is how you can
compile the command line version" to "now you should compile the
command line version" is the best bet.


Rick 

Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

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

Re: [PHP-DEV] Question: Should exit() print out the integer exit-status?

[php4]

Just a thought...

---
void exit ( [mixed message[, int return_value]])


Note: This is not a real function, but a language construct. 

The exit() function terminates execution of the script. Message
must be a string or an int.  If a non-null message is given it is
printed just before exiting. If return_value is given the exit status
of the program is set to this value.  To set an exit status without
printing anything, pass "" as message.


exit(); end program, print nothing, return 0

exit( "message" );  end program, print message, return 0

exit( 5 );  end program, print 5,   return 0

exit( "messge", 5 );end program, print message, return 5

exit( 6, 5 );   end program, print 6,   return 5

exit( "", 5 );  end program, print nothing, return 5

NOTE: The last example does not print _anything_.  No 's no \n's...
nothing.  

---

That should preserve BC and let those of us who are using php for shell
scripting to have a reasonably simple way to return program status with
or without printing message.



Rick


Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

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

[PHP-DEV] Bug #13355 Updated: reproduceable Apache Bomb w/ xslt

[php4]

ID: 13355
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: XSLT related
Operating System: 
PHP Version: 4.0CVS-2001-09-17
New Comment:

yeah, yeah. I know, there are typos in the xml string line... it's late. My fingers 
aren't working all that well.

The code I'm using is a damned-near copy of what's in ext/xslt/README.BACKENDS

cheers.

Previous Comments:


[2001-09-17 18:12:16] [EMAIL PROTECTED]

sheesh. forgot to add offending script:

My Data $xml, "/_xsl" => $xsl);

$data = xslt_process($xh, "arg:/_xml", "arg:/_xml", NULL, $args);

xslt_free($xh);

print $data;

?>



[2001-09-17 18:05:28] [EMAIL PROTECTED]

having compiled php4.0.7RC2 w/
--enable-xslt --with-xslt-sablot
using sablot .65.1, here is my lovely backtrace, please help, Sir Sterling,
Program received signal SIGSEGV, Segmentation fault.
0x4040f370 in zif_xslt_error () from /usr/lib/apache/1.3/libphp4.so
(gdb) bt
#0  0x4040f370 in zif_xslt_error () from /usr/lib/apache/1.3/libphp4.so
#1  0x4035fc19 in execute () from /usr/lib/apache/1.3/libphp4.so
#2  0x4036e376 in zend_execute_scripts () from /usr/lib/apache/1.3/libphp4.so
#3  0x4037c1f6 in php_execute_script () from /usr/lib/apache/1.3/libphp4.so
#4  0x4037802e in apache_php_module_main () from /usr/lib/apache/1.3/libphp4.so
#5  0x40378b2e in php_restore_umask () from /usr/lib/apache/1.3/libphp4.so
#6  0x40378b95 in php_restore_umask () from /usr/lib/apache/1.3/libphp4.so
#7  0x08054244 in ap_invoke_handler (r=0x840d064) at http_config.c:517
#8  0x080630ac in process_request_internal (r=0x840d064) at http_request.c:1307
#9  0x08063108 in ap_process_request (r=0x840d064) at http_request.c:1323
#10 0x0805cc69 in child_main (child_num_arg=0) at http_main.c:4299
#11 0x0805cdfc in make_child (s=0x809af84, slot=0, now=1000763166) at http_main.c:4412
#12 0x0805cf19 in startup_children (number_to_start=5) at http_main.c:4494
#13 0x0805d3d5 in standalone_main (argc=2, argv=0xb894) at http_main.c:4782
#14 0x0805da9d in main (argc=2, argv=0xb894) at http_main.c:5124
#15 0x400e364f in __libc_start_main () from /lib/libc.so.6





Edit this bug report at http://bugs.php.net/?id=13355&edit=1


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

[PHP-DEV] Bug #13355 Updated: reproduceable Apache Bomb w/ xslt

[php4]

ID: 13355
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: XSLT related
Operating System: 
PHP Version: 4.0CVS-2001-09-17
New Comment:

sheesh. forgot to add offending script:

My Data $xml, "/_xsl" => $xsl);

$data = xslt_process($xh, "arg:/_xml", "arg:/_xml", NULL, $args);

xslt_free($xh);

print $data;

?>

Previous Comments:


[2001-09-17 18:05:28] [EMAIL PROTECTED]

having compiled php4.0.7RC2 w/
--enable-xslt --with-xslt-sablot
using sablot .65.1, here is my lovely backtrace, please help, Sir Sterling,
Program received signal SIGSEGV, Segmentation fault.
0x4040f370 in zif_xslt_error () from /usr/lib/apache/1.3/libphp4.so
(gdb) bt
#0  0x4040f370 in zif_xslt_error () from /usr/lib/apache/1.3/libphp4.so
#1  0x4035fc19 in execute () from /usr/lib/apache/1.3/libphp4.so
#2  0x4036e376 in zend_execute_scripts () from /usr/lib/apache/1.3/libphp4.so
#3  0x4037c1f6 in php_execute_script () from /usr/lib/apache/1.3/libphp4.so
#4  0x4037802e in apache_php_module_main () from /usr/lib/apache/1.3/libphp4.so
#5  0x40378b2e in php_restore_umask () from /usr/lib/apache/1.3/libphp4.so
#6  0x40378b95 in php_restore_umask () from /usr/lib/apache/1.3/libphp4.so
#7  0x08054244 in ap_invoke_handler (r=0x840d064) at http_config.c:517
#8  0x080630ac in process_request_internal (r=0x840d064) at http_request.c:1307
#9  0x08063108 in ap_process_request (r=0x840d064) at http_request.c:1323
#10 0x0805cc69 in child_main (child_num_arg=0) at http_main.c:4299
#11 0x0805cdfc in make_child (s=0x809af84, slot=0, now=1000763166) at http_main.c:4412
#12 0x0805cf19 in startup_children (number_to_start=5) at http_main.c:4494
#13 0x0805d3d5 in standalone_main (argc=2, argv=0xb894) at http_main.c:4782
#14 0x0805da9d in main (argc=2, argv=0xb894) at http_main.c:5124
#15 0x400e364f in __libc_start_main () from /lib/libc.so.6





Edit this bug report at http://bugs.php.net/?id=13355&edit=1


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

[PHP-DEV] Bug #13355: reproduceable Apache Bomb w/ xslt

[php4]

From: [EMAIL PROTECTED]
Operating system: 
PHP version:  4.0CVS-2001-09-17
PHP Bug Type: XSLT related
Bug description:  reproduceable Apache Bomb w/ xslt

having compiled php4.0.7RC2 w/
--enable-xslt --with-xslt-sablot
using sablot .65.1, here is my lovely backtrace, please help, Sir
Sterling,
Program received signal SIGSEGV, Segmentation fault.
0x4040f370 in zif_xslt_error () from /usr/lib/apache/1.3/libphp4.so
(gdb) bt
#0  0x4040f370 in zif_xslt_error () from /usr/lib/apache/1.3/libphp4.so
#1  0x4035fc19 in execute () from /usr/lib/apache/1.3/libphp4.so
#2  0x4036e376 in zend_execute_scripts () from
/usr/lib/apache/1.3/libphp4.so
#3  0x4037c1f6 in php_execute_script () from
/usr/lib/apache/1.3/libphp4.so
#4  0x4037802e in apache_php_module_main () from
/usr/lib/apache/1.3/libphp4.so
#5  0x40378b2e in php_restore_umask () from
/usr/lib/apache/1.3/libphp4.so
#6  0x40378b95 in php_restore_umask () from
/usr/lib/apache/1.3/libphp4.so
#7  0x08054244 in ap_invoke_handler (r=0x840d064) at http_config.c:517
#8  0x080630ac in process_request_internal (r=0x840d064) at
http_request.c:1307
#9  0x08063108 in ap_process_request (r=0x840d064) at http_request.c:1323
#10 0x0805cc69 in child_main (child_num_arg=0) at http_main.c:4299
#11 0x0805cdfc in make_child (s=0x809af84, slot=0, now=1000763166) at
http_main.c:4412
#12 0x0805cf19 in startup_children (number_to_start=5) at
http_main.c:4494
#13 0x0805d3d5 in standalone_main (argc=2, argv=0xb894) at
http_main.c:4782
#14 0x0805da9d in main (argc=2, argv=0xb894) at http_main.c:5124
#15 0x400e364f in __libc_start_main () from /lib/libc.so.6
-- 
Edit bug report at: http://bugs.php.net/?id=13355&edit=1


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

re: [PHP-DEV] patch to make for better shell scripting

[php4]

Addressed to: [EMAIL PROTECTED]
  "Brian Moon" <[EMAIL PROTECTED]>

> Well, here is my patch finally for enabling a shell mode with the
> command line.

> Mainly this patch adds a -S option that will turn off html errors,
> error_prepend_string, error_append_string, and output buffering.

> This will keep people from having to maintain two ini files.


Please consider adding the function of

   set_time_limit( 0 );

to the -S option, usually when I run PHP from the command line I am not
worried about how long it takes to run.  Long running programs are one
of the common reasons for running PHP from the command line.  If you
want a command line script to time out you can set the time limit in
your program.


Thanks,
Rick



Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

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

Re: [PHP-DEV] Security Issues

[php4]

Addressed to: Rasmus Lerdorf <[EMAIL PROTECTED]>
  <[EMAIL PROTECTED]>

> Or you can simply stop these people from using PHP which is another
> effect turning off register_globals will have.
>   
> Java does not have this problem because Java is so complex that this
> same set of users can not program in Java. Fixing this problem by
> making PHP more complex and eliminating these "problem" users is a bad
> idea as far as I am concerned.


YES!!


As I see it the whole issue revolves around the fact that some people
get used to the fact that undefined variables have a value, and rely on
it.  These are the people who get hit when a hacker slips in his own
value in on such variables.  If the programmer had just initialized
the variable at the top of the program, there would not be a problem.

I think the best thing you could do about this issue is:


1.  ALWAYS report the use of an uninitialized variable, no matter what
level of error checking is in effect.  At the very least send a message
to the error_log for every undefined variable. If the error level allows
it also complain to the browser and send an email to ServerAdmin. That
won't break any existing scripts, but depending on the text of the
email, it could give system administrators incentive to correct problem
scripts. [1]  The 'send email' default should be on in the distribution.


2.  Make it a FATAL error.  Too bad that would break so many scripts...
Maybe it could be a major effect of the E_SECURE bit.  On the other
hand, if you are serious about stamping out the uninitialized variable
problem, this will do it.


Register Globals is very convienent for people who write code with
PHP.  Turning it off would be a great loss.  The problem is not that
values passed to the server appear as variables, it is that some
programmers don't make sure they initialize every variable before they
use it. 



---

[1]:

To: System Administrator <[EMAIL PROTECTED]>
From: [EMAIL PROTECTED]
Subject: Potential Security Problem in a PHP Script

Warning: an undefined variable $I was accessed in  myscript.php  on line
123.  This could be a serious security problem. For more information
see:

   http://www.php.net/manual/en/security.uninitialized.php


In most cases you can correct this error by simply adding  $I = 0;
somewhere before you attempt to use its value.  If line 123 is within a
loop, be sure to initialize the value before the beginning of the loop.
A simple way to handle this is to initialize all variables you get this
warning on at the very top of the script.
 

You can stop these emails by removing E_UNINIT_EMAIL from
error_reporting in your php.ini file. This problem has serious security
implications and should not be ignored.  Please read the web page listed
above before you decide what to do.



Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

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

Re: [PHP-DEV] delete none-empty directory

[php4]

Addressed to: mohammed oda <[EMAIL PROTECTED]>
  <[EMAIL PROTECTED]>

** Reply to note from <[EMAIL PROTECTED]> Mon, 23 Apr 2001 13:30:37 +0200 (CEST)
>   
> On Mon, 23 Apr 2001, mohammed oda wrote:
>   
> > hi
> > can somebody help me how can i delete non-empty directory by  php
> > command(rmdir) or another command.
> > with rmdir i can only delete empty directory.
>   
> system ("rm -rf /");

I know this is not the list for this question (php-general would be much
better) but that answer is vicious.  That command will delete every file
on the system that is writable by the web server, or the user running
php.

It is the right track, the answer is  

   system( "rm -rf /path/to/directory/to/delete" )

Be very careful, if a hacker can trick your program, say by entering:

   Directory to delete: [somedirectory /  ]

and you don't catch it by closely checking your user input you  are
opening a BIG security hole on your system.

Any further questions on this subject should be moved to the php-general
list, php-dev is for the development _of_ php, not developing with it.







Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

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

Re: [PHP-DEV] "Independent" comments on a bug.

[php4]

** Reply to note from Jani Taskinen <[EMAIL PROTECTED]> Sun, 18 Mar 2001 23:33:46 +0100 
(CET)

A few thoughts on this subject...


Anyone should be able to comment on any bug report.


Anyone who comments on a bug report (that is not a developer) should get
an email when the status of the bug changes, or a new comment is posted
to the bug.  The developers list might be subscribers to php-dev.


A special kind of comment, "Add me to the bug's interest list" should
be supported that does not trigger a message, and just adds you to the
list.


Anyone on the interest list for a bug that is declared a duplicate
should be added to the interest list for the bug that it duplicates so
that everyone interested in the problem gets notified when something
happens.  Duplicate email addresses should be eliminated.  An email
should be sent to the interest list of the duplicate telling them that
the bug is a duplicate, what bug it duplicates, and that they will still
be notified when anything changes.




Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

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

Re: [PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] ctype function (re?)naming

[php4]

Addressed to: Distribution list (see below)

** Reply to note from Ron Chmara <[EMAIL PROTECTED]> Thu, 01 Mar 2001 20:36:38 -0700
>   
> Well, then defining "well known" may also become an issue. Well known
> by whom? C programmers? Perl Hackers? Java users? 


Yes!  

If we are importing their concepts or libraries, use the existing terms.


If I do a  man fopen  and get information on how to use fopen, PHP
should call it fopen, not file_open or whatever else we might come up
with. If I read the instructions for library foo and all the
documentation talks about function wordword, then I think the php
function should be

   foo_wordword

because that is what all the foo documentation is going to call it.
Everyone who is familiar with foo will expect the function to be called
wordword, not word_word.  WordWord is not an issue here, php will run it
either way.



> The users of a particular PHP module?

No.  We have control of the PHP side.  We don't have to worry about the
installed base of C programmers who expect fopen, or people who have
used the foo library that expect the function to be called wordword.

That said, be careful naming experimental and future libraries, and be
very slow forcing changes of existing functions.  Remember, this only
aplies to new stuff in PHP.  Importing a library should use the naming
convention of that library with a php defined prefix_ to identify the
library.



Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

Distribution list: [EMAIL PROTECTED]
   Stanislav Malyshev <[EMAIL PROTECTED]>
   PHP Development <[EMAIL PROTECTED]>
   [EMAIL PROTECTED]
   [EMAIL PROTECTED]

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

Re: [PHP-DEV] php_apache.c virtual() enlightment needed

[php4]

Addressed to: =?ISO-8859-1?Q?Andr=E9?= Langhorst <[EMAIL PROTECTED]>
  PHP Development <[EMAIL PROTECTED]>

** Reply to note from =?ISO-8859-1?Q?Andr=E9?= Langhorst <[EMAIL PROTECTED]> Wed, 21 Feb 
2001 21:04:40 +0100
>   
> > That's what I recalled too.  I don't think that this can work today, so 
> > if this check got lost along the way, it should probably be restored.
>   
> hehe, the PHP Mime type check is still there, but why do we shut down
> all buffers? what did it intentionally fix? I still do not get it...
>   



virtual() calls out to apache, which does its own output to the browser,
so before apache gets control php has to close out the buffer and send
everything that has been buffered, or things are displayed out of order.





Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

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

Re: [PHP-DEV] PHP 4.0 Bug #1256 Updated: A suggestion re downloads

[php4]

Addressed to: [EMAIL PROTECTED]
  [EMAIL PROTECTED]

** Reply to note from [EMAIL PROTECTED] 10 Feb 2001 18:13:46 -
> [1999-03-22 04:40:03] [EMAIL PROTECTED] It would be nice if the
> php.net download page had a list of ftp download sites as well as a
> geographical list of locations.

> 

> For those of us like me who run a site remotely (I'm in Australia but
> my servers are in the US), we'd like to be able to ftp the latest
> source from somewhere close to where our servers are. As it stands, I
> have to either search thru the countries on the d/l page for an ftp
> location, or download it via http, then ftp it to my US sites.

May I suggest lynx!  Just ssh or telnet into your server and download
with lynx.  It works great!  


cd to the directory where you want the package


lynx http://www.php.net/downloads.php


Arrow down to the package you want to download.


Type  d  for download


Select   Save to disk


Hit Enter to accept the suggested filename, or change it as you see
fit.


Type  q   for quit, answer y (or enter) to Are you sure.


There it is...





Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

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

Re: [PHP-DEV] safe_mode redesign

[php4]

Addressed to: "Jason Greene" <[EMAIL PROTECTED]>
  <[EMAIL PROTECTED]>

** Reply to note from "Jason Greene" <[EMAIL PROTECTED]> Thu, 1 Feb 2001 14:53:12 
-0600
>   
> * Shared Directories - The ability to specify a list of paths that
> are shared amongst all hosted users. This would allow certain
> extensions (gd, oracle, etc) the ability to access the needed
> datafiles without failing a safe_mode check.
>   

please, Please PLEASE include this idea!  I have a strong need for a
system wide shared code repository for PHP.




Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

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

[PHP-DEV] vchkpw & qmail

[php4]

Is anyone doing anything with PHP and vchkpw?

There isn't much about it in the archives, but I'd hate to wast a bunch
of time and find out there is already something in progress.


I just built a mail server using these packages, and I'm quite
impressed.  I like the way vchkpw only needs a single user/group to
manage unlimited virtual domains.




Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

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

Re: [PHP-DEV] Redirecting output to a file

[php4]

Addressed to: "Malcolm Locke" <[EMAIL PROTECTED]>
  [EMAIL PROTECTED]

** Reply to note from "Malcolm Locke" <[EMAIL PROTECTED]> Wed, 17 Jan 2001 12:07:25 
+
>   
> Please correct me if there is already a facility to do this in place,
> but I have searched the manual and can find no functions. I would
> like the ability to redirect the standard PHP output stream to a file
> temporarily to a file, and return to output to the browser at some
> point in the script. Here is an example of the kind of thing I mean:


You might want to look at the Optput Buffer stuff:

   http://www.php.net/manual/en/html/ref.outcontrol.html




Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

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