[PHP-DEV] Bug #15022: Bison 1.30 seems to cause problems

[ron]

From: [EMAIL PROTECTED]
Operating system: Caldera Linux
PHP version:  4.1.1
PHP Bug Type: *Compile Issues
Bug description:  Bison 1.30 seems to cause problems

When running configure on systems with bison 1.30, the following error is
generated by configure:

checking bison version... ./configure: test: integer expression expected
before -lt

reverting to version 1.28 seems to have solved the problem for now. 

Ron. 
-- 
Edit bug report at: http://bugs.php.net/?id=15022&edit=1


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

[PHP-DEV] Bug #15024: Can't use ParameterPassedByReference()

[ron]

From: [EMAIL PROTECTED]
Operating system: Caldera Linux
PHP version:  4.1.1
PHP Bug Type: *Compile Issues
Bug description:  Can't use ParameterPassedByReference()

I have a few extensions that I've written for PHP, and under 4.1.1, when
linking I get the following error:

modules/php4/libphp4.a(cmtest.o): In function `php3_cm_sendsms':
/php-4.1.1/ext/cmtest/cmtest.c:185: undefined reference to
`ParameterPassedByReference'

I built a minimal extension with ext_skel, and only one simple function
that had contained the code:


if(!ParameterPassedByReference(ht, 2))
{
zend_error(E_WARNING, "Parameter 2 wasn't passed by
reference");
RETURN_NULL();
}

This was just to make sure that none of my other code could have been
causing the problem. This made the problem clearly reproducible. This
exact code works fine under php4.03pl1. (This code was extracted from the
API docs on the zend website, I think). 

Thanks,

Ron. 
-- 
Edit bug report at: http://bugs.php.net/?id=15024&edit=1


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

[PHP-DEV] Bug #12744: Command line option -c failing

[ron]

From: [EMAIL PROTECTED]
Operating system: 
PHP version:  4.0.6
PHP Bug Type: PHP options/info functions
Bug description:  Command line option -c failing

In file sapi/cgi/cgi_main.c

on line 400 the ini search path is set from the code:

if (php_module_startup(&cgi_sapi_module)==FAILURE) {
return FAILURE;
}

but the actual -c option is not read until line 442 from the code:

if (!cgi) {
while ((c=ap_php_getopt(argc, argv, OPTSTRING))!=-1) {
... 
}
...
}

Once I moved the code from line 400 after the -c option was read, it worked
prefectly.

-- 
Edit bug report at: http://bugs.php.net/?id=12744&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 #12771: new_object_array()

[ron]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.0.6
PHP Bug Type: Feature/Change Request
Bug description:  new_object_array()

  I was hoping that the dynamic creation of objects could be extended to
support it's parameters in an array format like the functions
call_user_method_array and call_user_func_array(). This would be great for
test suites.
eg

function test_suite_object_test($class, $args) {
if (!class_exists($class)) error();
else {
$obj = new_object_array($class, $args);
...
futher tests on the object
...
}
}

  This would useful, not having to hard code the constructors parameter
list, with obvious limitations, with something like:

function test_suite_object_test($class, $arg1, $arg2, $arg3, $arg4) {
if (!class_exists($class)) error();
else {
$obj = new $class($arg1, $arg2, $arg3, $arg4);
...
futher tests on the object
...
}
}

-- 
Edit bug report at: http://bugs.php.net/?id=12771&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 #12906: Configure appends extra -l with libjpeg test

[ron]

From: [EMAIL PROTECTED]
Operating system: Caldera Linux
PHP version:  4.0.6
PHP Bug Type: Compile Failure
Bug description:  Configure appends extra -l with libjpeg test


On a clean php-4.0.6 distribution, (untar the file and then cd to the
directory) the following configure command causes problems:

./configure --with-mysql --with-apache=../apache_1.3.12 --enable-track-vars
--with-gd=/usr/local --with-jpeg-dir=/usr/local --with-xpm-dir=/usr/X11R6

checking whether to include GD support... yes
checking whether to enable truetype string function in gd... no
checking for the location of libjpeg... yes
checking for jpeg_read_header in -ljpeg... no
configure: error: libjpeg not found!

Here is the config.log entry:

- CUT HERE --
configure:17964: checking for jpeg_read_header in -ljpeg
configure:17985: gcc -o conftest -g -O2   conftest.c -ljpeg
  -L/usr/local/lib
 -l -lcrypt -lresolv -lm -ldl -lnsl  -lresolv 1>&5
/usr/i386-linux/bin/ld: cannot open -l-lcrypt: No such file or directory
configure: failed program was:
#line 17974 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply.  */
char jpeg_read_header();

int main() {
jpeg_read_header()
; return 0; }

- CUT HERE --

Note the extra -l with no library before -l crypt. This is what is causing
the test to fail, despite the jpeg library having being isntalled
correctly. Compiling the same test program without the extra -l succeeds.


Thanks! 

Ron. 

P.S. Are there any workarounds to this problem? I'm still trying to figure
out which part of the configure command is adding the extra -l. 
-- 
Edit bug report at: http://bugs.php.net/?id=12906&edit=1


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

[PHP-DEV] Bug #12906 Updated: Configure appends extra -l with libjpeg test

[ron]

ID: 12906
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: Compile Failure
Operating System: Caldera Linux
PHP Version: 4.0.6
New Comment:

Thanks Jani - The latest snapshot seems to configure without errors. It whined about 
my IMAP path, but I just used --with-imap, and it seems to have configured OK. 

Ron. 


Previous Comments:


[2001-08-22 13:17:09] [EMAIL PROTECTED]

I fixed something like this in the CVS..but I can't remember
now what and where it was. :(

Please try the latest CVS snapshot from 
http://snaps.php.net/ 

--Jani




[2001-08-22 13:12:17] [EMAIL PROTECTED]


On a clean php-4.0.6 distribution, (untar the file and then cd to the directory) the 
following configure command causes problems:

./configure --with-mysql --with-apache=../apache_1.3.12 --enable-track-vars 
--with-gd=/usr/local --with-jpeg-dir=/usr/local --with-xpm-dir=/usr/X11R6

checking whether to include GD support... yes
checking whether to enable truetype string function in gd... no
checking for the location of libjpeg... yes
checking for jpeg_read_header in -ljpeg... no
configure: error: libjpeg not found!

Here is the config.log entry:

- CUT HERE --
configure:17964: checking for jpeg_read_header in -ljpeg
configure:17985: gcc -o conftest -g -O2   conftest.c -ljpeg
  -L/usr/local/lib
 -l -lcrypt -lresolv -lm -ldl -lnsl  -lresolv 1>&5
/usr/i386-linux/bin/ld: cannot open -l-lcrypt: No such file or directory
configure: failed program was:
#line 17974 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply.  */
char jpeg_read_header();

int main() {
jpeg_read_header()
; return 0; }

- CUT HERE --

Note the extra -l with no library before -l crypt. This is what is causing the test to 
fail, despite the jpeg library having being isntalled correctly. Compiling the same 
test program without the extra -l succeeds. 

Thanks! 

Ron. 

P.S. Are there any workarounds to this problem? I'm still trying to figure out which 
part of the configure command is adding the extra -l. 





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


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

[PHP-DEV] Bug #12906 Updated: Configure appends extra -l with libjpeg test

[ron]

ID: 12906
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Compile Failure
Operating System: Caldera Linux
PHP Version: 4.0.6
New Comment:

I think I spoke too soon... It's still problematic, even with the latest CVS. I think 
the reason it succeeded was because there was no 'ext' subdirectory in the 
snapshot 

Ron

Previous Comments:


[2001-08-22 13:32:02] [EMAIL PROTECTED]

Thanks Jani - The latest snapshot seems to configure without errors. It whined about 
my IMAP path, but I just used --with-imap, and it seems to have configured OK. 

Ron. 




[2001-08-22 13:17:09] [EMAIL PROTECTED]

I fixed something like this in the CVS..but I can't remember
now what and where it was. :(

Please try the latest CVS snapshot from 
http://snaps.php.net/ 

--Jani




[2001-08-22 13:12:17] [EMAIL PROTECTED]


On a clean php-4.0.6 distribution, (untar the file and then cd to the directory) the 
following configure command causes problems:

./configure --with-mysql --with-apache=../apache_1.3.12 --enable-track-vars 
--with-gd=/usr/local --with-jpeg-dir=/usr/local --with-xpm-dir=/usr/X11R6

checking whether to include GD support... yes
checking whether to enable truetype string function in gd... no
checking for the location of libjpeg... yes
checking for jpeg_read_header in -ljpeg... no
configure: error: libjpeg not found!

Here is the config.log entry:

- CUT HERE --
configure:17964: checking for jpeg_read_header in -ljpeg
configure:17985: gcc -o conftest -g -O2   conftest.c -ljpeg
  -L/usr/local/lib
 -l -lcrypt -lresolv -lm -ldl -lnsl  -lresolv 1>&5
/usr/i386-linux/bin/ld: cannot open -l-lcrypt: No such file or directory
configure: failed program was:
#line 17974 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply.  */
char jpeg_read_header();

int main() {
jpeg_read_header()
; return 0; }

- CUT HERE --

Note the extra -l with no library before -l crypt. This is what is causing the test to 
fail, despite the jpeg library having being isntalled correctly. Compiling the same 
test program without the extra -l succeeds. 

Thanks! 

Ron. 

P.S. Are there any workarounds to this problem? I'm still trying to figure out which 
part of the configure command is adding the extra -l. 





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


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

[PHP-DEV] Bug #13922: FORMAT() output in MySQL can't use str_replace

[ron]

From: [EMAIL PROTECTED]
Operating system: Redhat 7.1
PHP version:  4.0.5
PHP Bug Type: MySQL related
Bug description:  FORMAT() output in MySQL can't use str_replace

TO reproduce the problem:

Run a mysql query with the following:

   SELECT FORMAT((1004763843/1800),0) as TimeIndex

This will yeild 558,202. (Including the comma). 

As output from the sample script shows (see below for script):

   Before str_replace = 558,202

This needs to be converted to type int, but doing a settype to integer will
return only 558. So any resourceful (pronounced "lazy") php programmer
would suggest using str_replace to remove the comma. This does not work: 

   After str_replace = 558,202

So doing the settype still yeilds this: 

   After settype = 558

Is there a way to have settype deal with commas (depending on the locale of
course)? Of course the real solution is to use the MYSQL FLOOR, CEILING and
ROUND functions, which I have done, but it was still perplexing as to why
str_replace wouldn't work correctly on this string. The database library
used here is phpDB. 

Script:
$query = "SELECT FORMAT((1004763843/1800),0) as TimeIndex";

echo $query."\n";

$rs = $db->execute($query);

$TimeIndex = $rs->fields["TimeIndex"];
echo "Before str_replace = $TimeIndex \n";
str_replace(",","",$TimeIndex);
echo "After str_replace = $TimeIndex \n";
settype($TimeIndex,"integer");
echo "After settype = $TimeIndex \n";


-- 
Edit bug report at: http://bugs.php.net/?id=13922&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 #13922 Updated: FORMAT() output in MySQL can't use str_replace

[ron]

ID: 13922
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: MySQL related
Operating System: Redhat 7.1
PHP Version: 4.0.5
New Comment:

Oops. Not enough coffee. ;) 

Previous Comments:


[2001-11-04 16:15:49] [EMAIL PROTECTED]

$TimeIndex = str_replace(",","",$TimeIndex);

str_replace doesn't modify the string you give it.





[2001-11-04 16:13:45] [EMAIL PROTECTED]

TO reproduce the problem:

Run a mysql query with the following:

   SELECT FORMAT((1004763843/1800),0) as TimeIndex

This will yeild 558,202. (Including the comma). 

As output from the sample script shows (see below for script):

   Before str_replace = 558,202

This needs to be converted to type int, but doing a settype to integer will return 
only 558. So any resourceful (pronounced "lazy") php programmer would suggest using 
str_replace to remove the comma. This does not work: 

   After str_replace = 558,202

So doing the settype still yeilds this: 

   After settype = 558

Is there a way to have settype deal with commas (depending on the locale of course)? 
Of course the real solution is to use the MYSQL FLOOR, CEILING and ROUND functions, 
which I have done, but it was still perplexing as to why str_replace wouldn't work 
correctly on this string. The database library used here is phpDB. 

Script:
$query = "SELECT FORMAT((1004763843/1800),0) as TimeIndex";

echo $query."\n";

$rs = $db->execute($query);

$TimeIndex = $rs->fields["TimeIndex"];
echo "Before str_replace = $TimeIndex \n";
str_replace(",","",$TimeIndex);
echo "After str_replace = $TimeIndex \n";
settype($TimeIndex,"integer");
echo "After settype = $TimeIndex \n";







Edit this bug report at http://bugs.php.net/?id=13922&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] DOM XML Patch

[Ron Chmara]

>From the notes:
--
[EMAIL PROTECTED]
Hello Uwe Steinmann! 

I have make a little change in Source so that is possible to create textnodes into 
existing node like this example: 

$node->new_child("", "text outside"); 

text outside 
 
 

Here you can download my diff-file: 
http:/www.mf-software.de/files/php_domxml.diff 

Cu, Marco
---
Anybody know if this patch has been rolled in?

-Ronabop


--
Personal:  [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
Work: [EMAIL PROTECTED], 520-546-8993, http://www.pnsinc.com/
The opinions expressed in this email are not neccesarrily those of myself,
my employers, or any of the other little voices in my head.

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

[PHP-DEV] Moving errata notes around.

[Ron Chmara]

I'm in the process of re-writing the Installation section, which
will be greatly enhanced if I can move errata notes from older
pages to newer subsections... aside from a copy-paste method,
is there some facility/method already built for this task?

-Ronabop
--
Personal:  [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
Work: [EMAIL PROTECTED], 520-546-8993, http://www.pnsinc.com/
The opinions expressed in this email are not neccesarrily those of myself,
my employers, or any of the other little voices in my head.

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

[PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] Moving errata notes around.

[Ron Chmara]

Rasmus Lerdorf wrote:
> Not really.  You'd have to massage the database directly.  Why not just
> process the user comments as you go?  Either delete them or fold the
> comments into the docs?
> -Rasmus
> On Sat, 13 Jan 2001, Ron Chmara wrote:
> > I'm in the process of re-writing the Installation section, which
> > will be greatly enhanced if I can move errata notes from older
> > pages to newer subsections... aside from a copy-paste method,
> > is there some facility/method already built for this task?

I should have clarified a little more... for example, there
was one unix page, there are now sub-pages for different
OSs. Some of them are worth rolling into the docs, others
are one-liners-for-those-using-apache-on-ObscureLinux1.0, and
may be better suited for the linux pages than the main unix
page.

Anyways, it's good to know that we don't have this yet.

-Ron

--
Personal:  [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
Work: [EMAIL PROTECTED], 520-546-8993, http://www.pnsinc.com/
The opinions expressed in this email are not neccesarrily those of myself,
my employers, or any of the other little voices in my head.

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

Re: [PHP-DEV] Code Contribution: localeconv()

[Ron Chmara]

"Sean R. Bright" wrote:
> Ok...so that's a "No thanks" then?

That's a "It was posted on saturday night, give it a few days".
(Some PHP people don't work weekends)

Sometimes patches will be submitted once or twice before somebody
picks it up and applies it to the source. Don't take it personally,
it's not.

-Ronabop

--
Personal:  [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
Work: [EMAIL PROTECTED], 520-546-8993, http://www.pnsinc.com/
The opinions expressed in this email are not neccesarrily those of myself,
my employers, or any of the other little voices in my head.

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

Re: [PHP-DEV] PostgreSQL maintainer? Fixing problems?

[Ron Chmara]

Matthew Hagerty wrote:
> 
> Greetings,
> 
> Can someone tell me if there is a PostgreSQL maintainer?

Yes. :-)
(http://cvs.php.net/viewcvs.cgi/php4/EXTENSIONS?rev=1.5&content-type=text/vnd.viewcvs-markup)
It's Jouni. Lot's of people patch it, though, look at the CVS for it for
details.

> Is someone
> working on the serious issues with pg_connect()?

Looking in bugs.php.net, there's outstanding issues with duplicate
pg_connect() calls, and it has a workaround: only use one connection
statement.

Is this what you're running into?

Bug 7298 lists a possible code patch for it.

-Ron

--
Personal:  [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
Work: [EMAIL PROTECTED], 520-546-8993, http://www.pnsinc.com/
The opinions expressed in this email are not neccesarrily those of myself,
my  employers, or any of the other little voices in my head.

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

Re: [PHP-DEV] wrong implementation of isset()?

[Ron Chmara]

"Mark J. Hershenson" wrote:
> >> Great analysis. What about answering the question? Stanislav Malyshev
> >> said some months ago this is 'strange', see the discussion around bug
> >> 6076. Tell us at least, why this actually isn't strange.
> > By default, any unset variable has value NULL - and isset(NULL) returns
> > false to indicate that. Similarly, assigning NULL to a variable unsets
> > it.
> > -Andrei
> > * The great thing about standards is that there are so many to choose from. *
> Well, sure, isset(NULL) should return false, it's not a variable set in the
> scope. A constant(?) yes, but not a variable.
> 
> But if you set a variable at some point in a script, would it not stand to
> reason that that name is in the global/local namespace, and therefore IS
> set?

Perhaps, in order to maintain compatibility, we should re-document is_set,
create the documentation for is_null, and look into creating a new function
that will determine if something has "ever been inside the namespace", regardless
of its current value, or absence of value.

Right now, the *documentation* for isset does imply that:
$a = NULL;
isset($a); //TRUE
when this is not the case. 

Specifically, the documentation says "Returns true if a variable exists"
rather than "Returns true if a variable exists, but has not been sunsequently
assigned a value (or non-value) of NULL, and has not been unset().

-Ronabop

--
Personal:  [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
Work: [EMAIL PROTECTED], 520-546-8993, http://www.pnsinc.com/
The opinions expressed in this email are not neccesarrily those of myself,
my  employers, or any of the other little voices in my head.

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

Re: [PHP-DEV] wrong implementation of isset()?

[Ron Chmara]

André Langhorst wrote:
> > Perhaps, in order to maintain compatibility, we should re-document is_set,
> > create the documentation for is_null, and look into creating a new function
> > that will determine if something has "ever been inside the namespace", regardless
> > of its current value, or absence of value.
> we should just define (and document) this similar to Andrei (note, I do
> not use the word "the same" I use that word equal, what means different
> things):
> NULL  equals  absence_of_value  equals  absence_of_variable_in_namespace
> I can imagine no case where people would need to differentiate between
> NULL and never been in namespace

(Disclaimer: I think much of this is a bit silly, as it all can be
worked around, or people can avoid using NULL... but for the sake of
those who believe "NULL" should be a value)

Here's a possible case for this:
You have three forms. Each uses differently named variables.
All three post to the same page. One way a user might try to code
for this is:
if (isset($HTTP_POST_VARS[var_only_from_form_one]){ include ("foo");}
if (isset($HTTP_POST_VARS[var_only_from_form_two]){ include ("bar");}

Or using "has_ever-been_a_var" to do the same thing. Now, if one of those var's
has been assigned NULL somehow, their logic breaks, even though the var is
actually there, and has been set with something they consider a "value".

In a more interesting fashion, it adds a possible security feature,
where folks could actually error out their scripts if a user tried
to _introduce_ a faked variable, because it wasn't "supposed to be
there" under the current conditions, or at all. By walking the var arrays,
and checking against the expected vars, a user could send a security
warning if sombody was hacking a URL or faking a form the obvious
case I can think of is folks adding "debug=1" somehow.

-Ronabop

--
Personal:  [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
Work: [EMAIL PROTECTED], 520-546-8993, http://www.pnsinc.com/
The opinions expressed in this email are not necessarily those of myself,
my employers, or any of the other little voices in my head.

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

php-dev@lists.php.net

[Ron Chmara]

Toby Butzon wrote:
> 
> Another possibility :) Would require a bit of shifting things around,
> which could be quite a bit of a disturbance.
> 
> I have a get-to-the-root-of-it-all sort of question: Is the problem that
> it's too hard to combat spam or that the people in charge of the lists
> don't have time to really get into it?

Yes.

:-)

I've been fighting SPAM for years, and it's hard to find a balance that
works. Example:
Subject: Make Million$$$
vs.
Subject: My Make Million$$$ PHP site has a mysql problem.

In between the two is a good balance, but I know that many conventional methods
of spam filtering will block out valid users, valid domains, and valid
email. Many PHP users are working in "grey" areas, do we kick them out?

What if some spammer realizes that email from a user named
"rasmus" always gets through? Or that by having a forged IP allows
broadcasting? Or that as long as they change the subject line, or
"subscribe" for the 10 seconds it takes to broadcast email, or, or...

It's the same SPAM fight everybody's been doing, and there is no perfect
answer.

-Bop

--
Personal:  [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
Work: [EMAIL PROTECTED], 520-546-8993, http://www.pnsinc.com/
The opinions expressed in this email are not necessarily those of myself,
my employers, or any of the other little voices in my head.

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

Re: [PHP-DEV] Database connection pooling

[Ron Chmara]

lance your apache-process-creation-speed against your hardware-
resource-requirements. Since apache's spare process spawning happens
in the background (not related to a page load), you shouldn't
see any horrible differences unless you drop it too low (say, 10
connections before dying. :-) )... 

HTH,
-Ronabop
--
Personal:  [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
Work: [EMAIL PROTECTED], 520-546-8993, http://www.pnsinc.com/
The opinions expressed in this email are not necessarily those of myself,
my employers, or any of the other little voices in my head.

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

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

[Ron Chmara]

Stanislav Malyshev wrote:
> JM>> This is not in line with the other is_* functions. To keep in line with
> If you mean ctype functions, I agree - they all should be is*. If you mean
> is_integer type functions - so what? It's not in line also with
> mysql_num_rows function, so? That's just functions from different area,
> and the fact that accidentally they start from the same two letters does
> not change much.

"Accident" generally does not have a good meaning here (AZ,USA)... while we
(PHP) may not have a good naming schema for all functions, I think it is helpful
for the PHP user base to be able to comprehend the use of a function based
on the name.

Hypothetical examples:
xpldl_open() /* Start a new XML based Page Definition Language doc */
xpldl_openf() / * Read a printer language description logic file */

Now, based on what I've seen from Stanislav's code, he's used to this nightmare,
to thousands of include files where *one* typo annhilates an entire compile. But our
users, our base, is not at the level of Stas. Some have never used anything else.
Others came to PHP because it didn't have the [method nightmare|tag bondage|
forced typing] of other languages.

Yes, ctype *could* be prefixed with VGH45i97_*. But it wouldn't be very helpful.

We could prefix ctype with mysql_* names. (Uhm... (So what? *Really?*) Is stas
voting that mysql_is_ctype is a good thing? I really doubt it.)

There's a reason why we don't use a prior name, and it's not because
skilled coders can differentiate between 89DEGU567S_open() and
89D3GU5675_open().. it's because new language adopters *can't*
differentiate.

-Ronabop
--
Personal:  [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
Work: [EMAIL PROTECTED], 520-546-8993, http://www.pnsinc.com/
The opinions expressed in this email are not neccesarrily those of myself,
my  employers, or any of the other little voices in my head.

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

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

[Ron Chmara]

Stanislav Malyshev wrote:
> RC>> I think it is helpful for the PHP user base to be
> RC>> able to comprehend the use of a function based on the name.
> On its name, yes - but not on underscores in it. Do you really think
> anybody will remember/care for those underscores?

Yes.

I find it annoying having to look up reference manuals for every
function, to figure out whether or not I need to use underscores, and
if so, where in the function name should they be used the general
point in *having* the underscores is that they provide a visual separation
of words, so they can be read (and comprehended) more easily, so the
purpose of the function is less ambiguous. Without them, the name
becomes less legible.

Much of the time I already know the function names, I just don't know
all of the choices that were made on whether it's "*_num_rows" or
"*_numrows", on whether it's "is_var" or "isvar". I do lots of code that
uses both mysql and postgres, and it's an ongoing hassle to not only
switch the family name (pg/mysql), but to also switch out other names
because of a lack of consistency, and never be quite sure what the
right thing to do actually is.

> Well, life's female canis familiaris. No naming scheme would resolve the
> problem that if you make typos it probably won't compile.

To a point, yes... Which to me, means we should make *generating* the
proper text as easy as possible for the end user. It will confuse the
users with most of the functions having "family_word_word" formats and
some which switch to "family_wordword" (or even worse, family_wordword_word).

> RC>> skilled coders can differentiate between 89DEGU567S_open() and
> RC>> 89D3GU5675_open().. it's because new language adopters *can't*
> RC>> differentiate.
> I don't see how it proves that is_alpha is better than isapha.

The point is that we don't seem to have any reason to force newbies to work
harder, to look at names super-closely, to guess at the particular
invention-of-the-day for function naming. People who have typed the function
200 times know it already. People still in between 1 and 200 uses or so
are wasting lots of their time guessing and debugging, or re-reading manual
pages.

> For
> unwashed masses, it's manual lookup anyway - they have no idea how it even
> _could_ be called. For people knowing C and descendants, it's a cookie
> (not http one, the pleasant one) - one more function they already know.

Well, put me somewhere in between unwashed and just plain annoyed
when I can remember the function's name, but not the arcane non-ruleset
for the function word delimiting. I certainly don't consider expertise
in obtuse naming to be that much of a cookie. More of a burden, a training
problem, a learning curve problem.

-Bop

--2D426F70|759328624|00101101011001100111
Personal:  [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
Work: [EMAIL PROTECTED], 520-546-8993, http://www.pnsinc.com/
The opinions expressed in this email are not necessarily those of myself,
my employers, or any of the other little voices in my head.

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

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

[Ron Chmara]

d_word
SWF: word_wordword
SNMP: word_word_word/wordwordword
Sockets: word_word_word/wordwordword
Strings: word_word_word/wordwordword
Sybase: word_word_word
URL: word_word_word/wordwordword
Variables: word_word_word/wordwordword
WDDX: word_word_word
XML: word_word_word
XSLT: word_word_word/word_wordword
Yaz: word_word_word/word_wordword
YP: word_word_word
Zlib: wordwordword

Ignoring case, the extension count, and the possible naming styles, is
as follows:
word_word_word: 65
wordwordword: 24
word_wordword: 21

Some extensions use more than one style, but the one most often
used is word_word_word. Many functions fit into word_word, which
is not affected one way or another by observing the most common
thread in naming.

The standard seems to already be in place.

-Ron

-- 
--2D426F70|759328624|00101101011001100111
Personal:  [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
Work: [EMAIL PROTECTED], 520-546-8993, http://www.pnsinc.com/
The opinions expressed in this email are not necessarily those of myself,
my employers, or any of the other little voices in my head.

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

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

[Ron Chmara]

Stanislav Malyshev wrote:
> RC>> It's more legible for the same reason that it's easier (and
> RC>> faster) to read "one two three" than "onetwothree". The human
> RC>> mind can easily tokenize at the appropriate places, when it has
> RC>> a token. Without a token, the string is much harder to parse.
> For me, "isalpha" is single token. That's the name, much like Johnson or
> Chandrabharmata.

That makes sense to me. To a newbie, that's a lot of proper names to learn,
rather than learning a generic grammar, which they can then re-use.


> I repeat it once more, to be clear:
> 
> Functions that have "well known" names should not be touched.
> Snip_>

Well, then defining "well known" may also become an issue. Well known by
whom? C programmers? Perl Hackers? Java users? The users of a particular
PHP module?

I'm of the belief that parallel function names to C, Perl, etc. are good
for convenience, IF AND ONLY IF functionality is the same. See PHP "chop()"
for why doing otherwise is a bad thing... PHP chop() behaves rather oddly
as far as most Perl folks are concerned. Is it a well known name? Yes.
Does it work in a well known fashion? Not if you use Perl. Does it need to
be renamed? (I have no good answer for this one.) How about read()? (same
kind of issue.)

> RC>> I didn't check a manual. Ldap functions aren't named in a mixed fashion
> RC>> of word_wordword and word_word_word. They follow the *most common* PHP
> RC>> syntax of using word_word_word.
> Don't try to make me believe you remember all the "non-underscore" part of
> all functions by hard and your only problem is knowing where's the
> underscore.

The most common function names I remember by their words, but
without looking at a manual. When do i need to use *_num_rows,
*numrows, or *_num_rows?

Do you honestly know, from the words, what it does? Are you familiar
with num rows?

How about the num rows command for MySQL? PostgreSQL? Informix? Sybase?
mSQL? MSSQL? Are all of the num rows commands the same? (no.)

How about num fields? Are all of them the same?

Why on earth should you have to reference a manual for this *simple
task* of figuring out if it's supposed to be numrows, or num_rows?

> RC>> To stop confusing the *language*, as a whole, we should be doing this with
> RC>> some consistency, so we're not confusing people as they try to learn new
> RC>> function names.
> That's not "confusing". That's "remaining in touch with the rest of the
> known world". I do not want function to open file be
> "filesystem_open_file". I want my old trusty fopen. It served me well for
> years.

Well, I don't believe in making it impossible to type. Heck, if it means that
much to any of us, we _can_ just alias the function names ourselves. I
personally (also) consider fopen as one word, and would miss the ability to
have or use convenience aliases (which is something I put into a spec a
long time ago, but it caused *another* round of debate, as it might inspire
folks to create all sorts of bad function names. :-) ).

I'm not focusing on making life harder for coders who have seen languages
come and go, who are used to syntax and keywords being deprecated or reserved.
I'm focusing on making life easier for the newbies, and I thank you,
Stas, for some of the good reminders about maintaining legacy codebase.
(No sarcasm intended.)

-Ron

-- 
--2D426F70|759328624|00101101011001100111
Personal:  [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
Work: [EMAIL PROTECTED], 520-546-8993, http://www.pnsinc.com/
The opinions expressed in this email are not necessarily those of myself,
my employers, or any of the other little voices in my head.

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

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

[Ron Chmara]

Andi Gutmans wrote:
> It doesn't make much sense to go back and break old names and it doesn't
> make lots of sense to create a zillion of aliases. I guess if there are some
> names which in particular need fixing because they are terrible (there
> might be some of these) then we should fix them on a per-function basis.

"zillion" is a bit hard to pin down, isn't it? :-)

I took a swipe at figuring out the scope of the issue, and we have a
small mix of variants in a mostly consistent set of names. I'd say less
than a zillion. A bunch or so, maybe? ;-)

If done as a "think about this when updating and editing old code" problem,
the task of aliasing becomes much smaller, and much more achievable. It
also becomes less wasteful, as functions which aren't being actively
used (and thus, maintained) can atrophy gracefully, without having all
sorts of aliases created for a mostly unused function. (Example: Oracle
functions are slowly falling away, being replaced by OCI, swf functions
are doing a similar thing.)

> I am for uniform names but not if it's at the price of adding a zillion of
> aliases or at a price of making 50% of people's old scripts not work. I am
> also very much against compile-time options because I'd expect a script
> written in PHP and posted on some sites code exchange to work for everybody.

I'd definitely agree with both points, but am wondering if there's a "reasonable"
limit on supporting old scripts. (I'd call reasonable 6 years worth of
code, or three major codebase rewrites).

(Thanks for the humor Zak, it helps... I'm gonna go cry, hold onto
my woogie, and see if I can remember heim_unblock())
:-)

-Bop

--2D426F70|759328624|00101101011001100111
Personal:  [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
Work: [EMAIL PROTECTED], 520-546-8993, http://www.pnsinc.com/
The opinions expressed in this email are not necessarily those of myself,
my employers, or any of the other little voices in my head.

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

[PHP-DEV] PHP 4.0 Bug #9852: Header redirect and db connection cause "CGI misbehaved"

[ron . baldwin]

From: [EMAIL PROTECTED]
Operating system: Windows 2000
PHP version:  4.0.4pl1
PHP Bug Type: IIS related
Bug description:  Header redirect and db connection cause "CGI misbehaved"

Under the category of "You Can Never Have Too Much Information On A Bug", here is my 
experience with the "CGI App Misbehaved" bug (related bug reports: #8571 and #8744).

Bug report summary:
A PHP script that sends a 'Location' header directive and makes a database connection 
causes IIS to intermittently return a 'Gateway Error 502' when the client browser asks 
for the page specified in the redirect.  The address bar will correctly show the page 
that should have loaded when the error is displayed, and pressing F5 (refresh) will 
correctly load the page.  Note that the error is (seemingly) completely random, 
sometimes you get it, other times the script works correctly.  The error message text 
is:

   -- Begin --
   CGI Error
   The specified CGI application misbehaved by not returning a complete set of HTTP 
headers. The headers it did return are:
   --  End  --

This error depends on:
1) Using PHP in CGI mode (i.e. using php.exe, the ISAPI dll does not seem to produce 
this error, although it has it's own problems).
2) A PHP script that connects to a database (tested both mssql_connect and 
odbc_connect) *and* sends a 'Location:' header.  If the script redirects to something 
other than a .php file (i.e. .html or .pdf) or does not connect to the database, the 
error will not occur.
3) A successful db connection.  If the db connect call fails (due to bad password, 
etc.), the redirect always works.

This error does *not* depend on:
1) A fully qualified 'Location' header.  The following also fails:
   header('Location: http://10.0.0.30/test/done.php');
2) The relative order of the header() and xxx_connect() calls in 'doit.php'.  I 
wouldn't expect the order to affect the result, but I checked it anyway.

Interesting note: While upgrading the server to SP1 to see if it had any affect on 
this bug, I continued to test while it was in the process of performing the upgrade.  
It was very difficult (I gave up) trying to get the error.  The CPU was at 100% due to 
the upgrade which (obviously) caused the web server performance to suffer.  Combined 
with the fact that it occurs randomly anyway, this suggests that it may have something 
to do with the timings between the request for doit.php, execution of doit.php, and 
the request for done.php.


Hardware/Software:
   Web server:
  Win2000 Server (with and without SP1)
  IIS 5.0
  PHP 4.0.4pl1 (CGI mode)

   Database server:
  WinNT 4.0 SP6
  MS-SQL 7.0

   Client:
  Win2000 Professional SP1
  IE 5.5 SP1



Test scripts

start.php

Test

Do test


doit.php



done.php

Test

Test complete
Reset test



Here are actual HTTP headers recorded using a packet sniffer:


Scenario #1 - CGI Error Occurs

Client request

GET /test/doit.php HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, 
application/msword, */*
Referer: http://10.0.0.30/test/start.php
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Host: 10.0.0.30
Connection: Keep-Alive

Server response

HTTP/1.1 302 Object Moved
Location: done.php
Server: Microsoft-IIS/5.0
Content-Type: text/html
Connection: close
Content-Length: 131

Client request (automatic IE request)

GET /test/done.php HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, 
application/msword, */*
Referer: http://10.0.0.30/test/start.php
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Host: 10.0.0.30
Connection: Keep-Alive

Server response (Incorrect response)

HTTP/1.1 502 Gateway Error
Server: Microsoft-IIS/5.0
Date: Tue, 20 Mar 2001 00:30:10 GMT
Connection: close
Content-Length: 215
Content-Type: text/html

Client request (F5 - refresh)

GET /test/done.php HTTP/1.1
Accept: */*
Referer: http://10.0.0.30/test/start.php
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Host: 10.0.0.30
C

[PHP-DEV] PHP 4.0 Bug #9854: Empty strings get returned as single spaces

[ron . baldwin]

From: [EMAIL PROTECTED]
Operating system: Windows 2000
PHP version:  4.0.4pl1
PHP Bug Type: MSSQL related
Bug description:  Empty strings get returned as single spaces

mssql_fetch_array (and mssql_fetch_row) return a single space for columns that contain 
an empty string (as opposed to columns that contain NULL).


-- 
Edit Bug report at: http://bugs.php.net/?id=9854&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] PHP 4.0 Bug #9854 Updated: Empty strings get returned as single spaces

[ron . baldwin]

ID: 9854
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: MSSQL related
Description: Empty strings get returned as single spaces

Add'l info:

Web Server:
   Win2000 Server SP1
   IIS 5.0
   PHP 4.0.4pl1

Database Server:
   WinNT SP6
   MSSQL 7.0

Previous Comments:
---

[2001-03-19 23:42:49] [EMAIL PROTECTED]
mssql_fetch_array (and mssql_fetch_row) return a single space for columns that contain 
an empty string (as opposed to columns that contain NULL).

---


Full Bug description available at: http://bugs.php.net/?id=9854


-- 
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] PHP 4.0 Bug #9855: Return column data with correct type

[ron . baldwin]

From: [EMAIL PROTECTED]
Operating system: Windows 2000
PHP version:  4.0.4pl1
PHP Bug Type: MSSQL related
Bug description:  Return column data with correct type

Suggestion:

Add new data retrieval functions (or extend mssql_fetch_array and mssql_fetch_row) to 
return each column in a type that matches the underlying database column type instead 
of the always as type string.  Also, return columns that are NULL as PHP's null type 
(instead of boolean/false).

Two questions - is this the proper place to submit suggestions, and if so should this 
also be submitted to the general 'database functions' category (I know PHP's ODBC 
functions exhibit the same behavior)?



-- 
Edit Bug report at: http://bugs.php.net/?id=9855&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] Re: cvs: php4(PHP_4_0_5)/sapi/fastcgi

[Ron Chmara]

Some thoughts.

1. Adding new/experimental extensions _can_ invisibly bug the rest of a
build, if they require such nastiness as the recent pthread debugging.
It's not only a minor configure issue when a built app breaks due to library
issues, because extensions can be linked in conflicting ways. It does
happen, it has happened in rather annoying, small ways (see mod_ssl
vs. mysql client and -lpthread linking issues.). These bugs suck, but
they do happen, because extensions are not ever totally isolated if they
are running on the same system, and linking to something else.

2. A QA process works well when it has a fixed target. If it's a highly
mobile target, every RC becomes an RC1. That means that RC2 is difficult,
if not impossible, to pin down for the final release.

3. By the same token, changes between RC's often must be made... if RC1
has problems, it's semi-mobile anyways. One of the goals in the issue is to
make it as immobile as possible. This will often require rulesets
that seem odd. Those rulesets are there because they help to pin down
bugs. As a mental example, imagine if bugs.php.net had no version
information (If RC1 and RC 2 have different code, different bugs are
possible, if not probable). Those rules generally forbid any new
features or functions.

4. If people want the newest features, we have daily CVS snapshots
for just that reason. QA'd, tested, release features and functionality,
without surprises, can also be downloaded, in a different place.
(If they _need_ fastcgi, there's nothing that prevents them from
getting it, RC or not is there?) Several open-source workflows have
adopted this, to the point where a QA'd, certified, "official" version
is a sold item, but the wild-and-loose source is free.

5. Nobody wants to add something that may break PHP. However, anticipating
all possible effects of one file on 2862 other files (as of 20010304) is a
bit of a challenge, if not impossible for many mortals. I am not implying
that the dev team is any less than infalliable gods, but QA mortals and
demi-gods like to have more reassurance than "It will work, no problem".
:-)

6. QA is not about making folks happy. It is bean-counting, line-checking,
focused, pragmatic, work. It is making sure that line changes in file 1261
did not affect functionality in 2861 other files. Adding 120 lines makes
it much more difficult.

7. That all being said, I'd be much happier if we could get into a
"tighter" QA release loop. Say, one week per frozen RC. If we add
anything, at all, it should be scheduled for another QA RC run.

Perhaps much of this issue could be settled by making "dead" forks,
where the RC forks have only RC bug fixes and/or releases. Everything
else goes into the main source.

My dos centavos,
-Ronabop

--2D426F70|759328624|001011010110011011110111
Personal:  [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
Work: [EMAIL PROTECTED], 520-546-8993, http://www.pnsinc.com/
The opinions expressed in this email are not necessarily those of myself,
my employers, or any of the other little voices in my head.

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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Ron Chmara]

"Frank M. Kromann" wrote:
> 
> Is there a list of modules that stays ?

One of the things I've noticed on this topic is that a few
folks tend to think that their particular technology should
be used everywhere, and therefore, it should always be
installed on machines. Of course, this is how we got into
this convoluted situation in the first place... sure,
"XYZ functions" may be touted as a future standard for all
machines, someday, but quite frankly, many of such "standards"
aren't even close to widespread use and deployment.

In response to Zeev's point that we don't even know if/how PEAR
will work, yes, I think this discussion isn't about enforcing the
future. I'd say it's more about finding some better direction.

A proposed list where it "cuts close to the bone":
(since nobody seems to want to be the 'bad guy', I'll start...)

M= Main
P= Pear
(To show/expose any personal bias, items marked with a "*" are ones that
I use on most servers.)

apache M *
aspell P *
bcmath P *
bz2 P
calendar P
ccvs P
com P
cpdf P
crack P *
ctype P
curl P
cybercash P
cybermut P
db P
dba P
dbase P
domxml P
dotnet P
exif P
fdf P
filepro P
fribidi P
ftp M *
gd P *
gettext P
gmp P
hyperwave P
icap P
iconv P
iisfunc M
imap M *
informix P
ingres_ii P
interbase P
ircg P
java P
ldap M *
mcal P
mcrypt P *
mhash P *
midgard P
ming P
mnogosearch P
msql P
mssql M
muscat P
mysql M *
notes P 
oci8 P *
odbc P 
openssl P
oracle P
ovrimos P
pcre P
pdf P
pfpro P
pgsql M *
posix P
printer P
pspell M *
qtdom P
readline P
recode P
sablot P
satellite P
session M 
shmop M *
snmp P *
sockets M *
standard M * (duh. :-) )
swf P
sybase P
sybase_ct P
sysvsem M *
sysvshm M *
vpopmail P
wddx P
xml P
yaz P
yp P
zlib P
zziplib P

Which would mean that the main distro would have:
apache
ftp
iisfunc
imap
ldap
mssql
mysql
pgsql
pspell
session
shmop
sockets
standard
sysvsem
sysvshm

This keeps the core system functions, basic database
services for the most widely used DB's, and the basic
data exchange services (IMAP, ftp, ldap, etc.)

Another way of looking at it would to leave almost everything
in some use, and only take out the ones which seem to be for
special purposes and work environments, such as an XML environment
pieces, or midgard, or hyperwave
ccvs P
com P
cpdf P
curl P
cybercash P
cybermut P
domxml P
dotnet P
exif P
fdf P
fribidi P
gettext P
hyperwave P
icap P
iconv P
ircg P
mcal P
midgard P
notes P 
openssl P
pcre P
pdf P
pfpro P
qtdom P
readline P
recode P
sablot P
vpopmail P
wddx P
xml P
yaz P
yp P
zziplib P

And, adding to the pear discussion, working with blocks of
these would undoubtedly be easier. So if you wanted to
get the XML package, it would grab xml, domxml, etc...

-Ronabop

--2D426F70|759328624|00101101011001100111
Personal:  [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
Work: [EMAIL PROTECTED], 520-546-8993, http://www.pnsinc.com/
The opinions expressed in this email are not necessarily those of myself,
my employers, or any of the other little voices in my head.

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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Ron Chmara]

On Wednesday, April 18, 2001, at 03:53  PM, Stig Sæther Bakken wrote:
> [Ron Chmara <[EMAIL PROTECTED]>]
>> "Frank M. Kromann" wrote:
>>> Is there a list of modules that stays ?
>> A proposed list where it "cuts close to the bone":
>> (since nobody seems to want to be the 'bad guy', I'll start...)
>> M= Main
>> P= Pear
>> (To show/expose any personal bias, items marked with a "*" are ones 
>> that
>> I use on most servers.)
>>

Major Snip_>

>> pcre P
> PCRE should be in the main distribution, a lot of PEAR code relies on
> it.

Snip Again _>

>> xml P
> *BLAM*
> That's the sound of someone shooting himself in the foot.  The PEAR
> installer needs the XML extension. :-)

LOL!

Well, so we've established that for PEAR-based-extensions to work, we 
_must_
have some of the /ext's included in the main distribution, as well as 
some form
of dependancy checking and resolution.

Looks like we're morping into a PEAR design discussion, in some ways. :-)

>> Which would mean that the main distro would have:
>> apache
>> ftp
> Why ftp, when for example curl is out?

My mental approach was to ask myself what the basic, internet-related,
extensions were, the things likely to be used by a beginner before they
grasped more advanced concepts, so they wouldn't have to learn PEAR
interactions to get started with  the bare basics.. That's why I picked
fairly well-known names, packages, and databases. While cURL can
do a _lot_ of things, a newbie trying to ftp, get ldap entires, etc. 
might
be more likely to look for functions directly associated with their end
goal.

That was my reasoning. Not neccesarrily the best reasoning, tho. :-)
It assumes a learning curve for PEAR, etc.

Of course, if we have sockets, we don't actually "need" ftp, imap,
ldap... well, just about anything that writes or reads :-)  but that 
makes the
learning curve a bit steeper. Clifflike, even.

>> mssql
>> mysql
>> pgsql
> I'm willing to bet my best cap that oci8 is much more used than mssql.

The reason that I wound up with these three is that I was looking for the
"top two". To compensate for our Win32 users, I added mssql, because
IIRC the pg port was pretty much a cygwin-kind-of-kludgy-thing...

(Of course, the WIn32 users do add a whole new dimension to this)

Hmmm it sure would be nice to have some actual metrics on extension 
use,
regardless of what gets put into PEAR.

Do we have any logs on www.php.net/manual page views? Could we use
that in some form  to determine extension use (by how frequently an 
extensions'
pages get looked up)? It's not survey based, and it's passive enough that
timeframes that we were collecting data on could be hidden from 
poll-slamming.

Even if we didn't want to log web hits (in general) for performance 
reasons,
(I have no idea if we do) we could at least get a set of numbers unbiased
by personal use/coding styles/etc. by turning it on for a minute or two,
once an hour, for a few days.

>> pspell
> Why?

I guess I use it often  enough that I associate it with being as 
valuable as any other
form of standard string-validation.

It's the hidden biases (and I guess the above is one of mine) that creep 
into
this

I'd be much happier if we had some metrics on use. Maybe we could also
gather information on number of errata notes for each, opened/closed bugs
for each, and pageviews for each. Those numbers should at least point us
in a few directions, where it gives us an idea of what people are 
actually
working with (as compared to just installing, or a web-poll.) Something 
that
wasn't too geographically based would be nice, as well, because 
application
usage (which interacts with the extensions used) varies from country to
country, timezone to timezone.

-Ronabop

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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Ron Chmara]

On Wednesday, April 18, 2001, at 05:33  PM, Zeev Suraski wrote:
> Guys,
> Over the years, there's always been a tendency to think about things 
> which are 10 steps ahead.  It never worked, and I don't think it would 
> work here either.

Well, a program spec (or idea) is certainly not the reality of the final 
codebase.

But if we don't think a few steps ahead, (or at least know where it's 
going), it's kind of hard to determine the steps to take here and now, 
or know where it's really going. I posted a list, and we discovered that 
PEAR already has dependancies on some /ext's, and (by implication) that 
if this continues in PEAR, eventually many of the minor ext's may need 
to be built to run PEAR in which case we may want to leave the /ext 
directory out of PEAR entirely.

If something is going to be a possibility, it should probably be 
considered before we build ourselves into a corner, and implementing it 
becomes impossible.

>  Whether or not we separate modules *at all* will greatly depend on how 
> good an implementation we end up having.

Agreed 100%.
But that implementation, as it happens requires some feedback and 
discussion, doesn't it?

>  How many of them we end up separating will also depend on that.  Let's 
> just wait with those discussions until they're somehow connected with 
> reality.

Counterpoint to this, of course, is that if we _would_ be doing this 
with a PEAR scheme, we'd need to design that into PEAR, preferrably 
without having to re-write PEAR from scratch to accomodate this idea. :-)


-Ronabop

-- 
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] 4.0.6

[Ron Chmara]

Andi Gutmans wrote:
> >The problem occurs when a web-developer using a Mac editor edits PHP
> >code: If he writes PHP code and his editor uses \r as linefeeds in the
> >PHP code, then the strange phenomenon may arise.
> 
> The editor only puts \r without \r\n? Wow, I've never seen a system that
> does that :) Were all Mac's like that?

It gets weirder on OS X (yes, I have one OS X box running...). It uses \r\n
*and* \n.  

Macs have been that way since '84 or so.

> Anyway, I don't know why you think that worked in 4.0.4

There have been various bugs with it since 3.0.X. Specifically, things
like multi-line SQL statements, the Error/Warning line numbers reported,
etc.

> OK, seriously. This code has not been changed in between 4.0.4 and 4.0.5.
> Are you sure you weren't using a different editor?
> Isn't there a way for you to save as "\n" or "\r\n"?

Usually, there's a "unix line feed" option... but just something to
think about:
Mac OS X is expected to have 5-10 million new users adopting in the
next year.
*Every single one* of those users is getting a box with Apache+PHP
pre-installed (tho not entirely configured.)

That's a lot of "fix your linefeed" bug responses

-Bop

-- 
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] 4.0.6

[Ron Chmara]

Andi Gutmans wrote:
> I've already commited a fix to the CVS which allows "\r" "\n" and "\r\n".
> >It gets weirder on OS X (yes, I have one OS X box running...). It uses \r\n
> >*and* \n.

Sorry 'bout that, I'm reading email remotely (I'm in D.C., right across from
the chinese embassy), and I'm running a bit behind right now... noticed
the patch a few messages later.
(only 1107 messages to go...)

-Ronabop

-- 
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] Possible feature for current version of PHP or PHP4.1/5.0.

[Ron Chmara]

On Monday, July 9, 2001, at 09:42  PM, Andi Gutmans wrote:
> At 04:04 PM 7/9/2001 -0500, Brian Moon wrote:
>> It is not so much BC.  It is more like unexpected new behavior.
>> As of now, a bad programmer might have this:
>> /www/site.com/include/file.php
>> /www/site.com/include/config.php
>> /www/site.com/index.php
>> /www/site.com/config.php
>> if index.php includes include/file.php which includes 
>> "config.php", the
>> config in the main dir gets included.
>> Now, in the future, if the main config.php is not there, the 
>> one in the
>> include file gets included.  Now, granted, this may not be the 
>> best case,
>> but it would cause some confusion if someone was not well 
>> aware of this
>> change.
>> I am still +1, but think it should be at least a 4.1 thing.
> Does others also think it should wait for 4.1 or later? If so 
> I'll leave it for now (I'll have more free time :).

I have about ~200 files that use the behavior of the current 
version. In some cases, to an (internal) advantage. I'll alter 
the example a bit, to clarify the difference between my includes 
and "page" files:
/www/site.com/include/file.inc
/www/site.com/include/config.inc
/www/site.com/index.php
/www/site.com/config.php

and add a few more:

/www/site.com/file.inc
/www/site.com/config.inc
/www/site.com/semi-seekrit/include/file.inc
/www/site.com/semi-seekrit/include/config.inc
/www/site.com/super-seekrit/include/file.inc
/www/site.com/super-seekrit/include/config.inc

Regardless of how we handle it , it may break code that relies 
on the prior behaviours 4.1 might be good, in those 
circumstances. I _do_ think it's "broken", but, unfortunately, I 
do not share a brain with all of my coding staffers, so this 
code style (error?) has crept in.

-Ronabop

--2D426F70|759328624|00101101011001100111
[EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
The opinions expressed in this email are not necessarily those 
of myself,
my employers, or any of the other little voices in my head.

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

Re: [PHP-DEV] [UPDATE] NGScan

[Ron Chmara]

ntal store.

>>And I certainly don't want to burn all
>> the dynamic of the PHP project by sitting around and hoping
>> that you "may" change your license at some undetermined point
>> in the future.  Thanks, but no.

I hate the license too. (Check the archives if ya want...) It's 
not like it's unchangeable, though.

However, it can't be changed by attacking somebody publicly. 
That's a really bad way of trying to do something.

It _can_ be changed by respecting an author's work, and 
appealing to their sense of community, their sense of 
collaboration, their love of code, of the language(s), and by 
providing them with other channels for income.

-Bop

[1]STFU=Shut The Fuck Up.

--2D426F70|759328624|00101101011001100111
[EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
The opinions expressed in this email are not necessarily those 
of myself,
my employers, or any of the other little voices in my head.

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

[PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] Security?

[Ron Chmara]

First of all, looking over this, this is all alreadly covered by 
the (possibly anemic) security section..which could 
definitely use more examples, explanations, and exploit examples 
(hint hint).

On Wednesday, July 4, 2001, at 10:05  AM, sterling hughes wrote:
> On 03 Jul 2001 19:13:20 -0700, Rasmus Lerdorf wrote:
>> On 4 Jul 2001, sterling hughes wrote:
>>> Ah well, I'm guessing most people have already seen this, still, I
>>> couldn't help passing it along...  There are some good points 
>>> (nothing
>>> we haven't discussed before) and some pretty bad points as well.
>> A lot of these are rather silly and are actually present in other
>> scripting languages when they are used in a web environment.  
>> Most of it
>> boils down to the fact that you cannot trust user data.

Bingo. A perl script which does not check input  is as bad as a 
javascript is as bad as PHP...

I found the article interesting because it addressed the sheer 
amount of insecure code (and coding practices) out there. PHP is 
a powerful language, much more so than javascript or DHTML, and 
yet, that is often what it is compared to. OTOH, it has as much 
power as a CGI, which webmasters/sysadmins know to handle 
delicately, _because_ of root exploits. Server admins need a 
heads up, methinks, and a warning that PHP is a language that 
*can* do nasty things.

>>  The fact that
>> user data is easier to get at in PHP doesn't really change the model.
>> Making it harder to get the user data doesn't help if this 
>> data is still
>> not checked and used incorrectly once you do get it.
>> But, I do think it would be worthwhile to go through these and add a
>> section to the documentation highlighting the pitfalls and 
>> explaining how
>> to avoid them.

 See above. :-)

> I think the main point I agree with is that since many beginning users
> use PHP to implement there websites, PHP should be more secure than
> other languages, and have less places where the user can mess up.

PHP owes it's success to being easier to use. The more we try to 
lock it down, for security reasons, the more it becomes harder 
to use. (I think register globals off is silly, myself... a 
determined cracker can't figure out how to forge a get instead 
of a post, or vice versa?). Sure, we can switch to forced 
typing, fixed buffers, but what's the point? To become C? If 
that was what folks wanted, they'd learn C in the first place. 
And it won't slow down crackers. The exact same article could 
have been written with minor changes (a paragraph or less) to 
show forging get/post/cookies, because PHP coders are often 
*sloppy* about their vars.

It's security through obscurity ("guess which of the whopping 
four (GPCS) places I'm using?") it's an illusion, not a 
solution.

Beginning users grab bad cgi's, horrid javascript, etc. Newbies 
are newbies. The problem is not that PHP does too much, the 
problem is that it's not being recognized for the level of power 
it has, and treated accordingly.

>  I think the security section to the documentation is a superb start,

add away!

> however, I also think that PHP5.0 since we are breaking 
> language compat,
> perhaps we should turn off register_globals by default?

Uhm... I think you'll break pretty much *everything* out there. 
Horrifically.

I don't personally know a single PHP developer who want to type 
an addtional 14+ chars everytime they pick out a variable, and I 
haven't seen much code where people actually do this. Have you 
taken at look at ours? The code driving our php.net website? :-)

Suggestions/Ideas to mock or approve/improve upon.
1. Modify the "secured" var stack names, so calling something 
like $PHPG["a"] Is equivalent to HTTP_GET_VARS["$a"] ( PHPP | 
PHPS | PHPC | PHPF). Less typing of chars is good. Carpal tunnel 
injuries bad.
2. Warn users. Put warnings in everytime something is called 
from globals, without being initialized off of a "clean" stack. 
(Which is dirty anyways, but some folks think it'll help slow 
down hackers by 3/4ths or, on a 10 hits per sec website, by 
less than a second).
3. "beef up" the security section
4. Start talking about PHP as if it was as powerful as it really 
is... sure, it can make dynamic websites, but it can also 
reformat your hard drives.
5. Eat our own dogfood (An americanmism). Make all our code 
clean first, and learn from that.

-Bop

--2D426F70|759328624|00101101011001100111
[EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
The opinions expressed in this email are not necessarily those 
of myself,
my employers, or any of the other little voices in my head.

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

Re: [PHP-DEV] Bug #12223: ldap rebind procedure implementation

[Ron Chmara]

[EMAIL PROTECTED] wrote:
> 
> From: [EMAIL PROTECTED]
> Operating system: any
> PHP version:  4.0.6
> PHP Bug Type: LDAP related
> Bug description:  ldap rebind procedure implementation
> 
> A ldap rebind procedure for automatical referral chase is
> not provided in php4. The solution of #9704 doesn't work
> "ldap result". This is an inherent problem with synchronous
> ldap calls.
> 
> I have written an implementation of ldap_set_rebind_proc
> registering a php rebind callback. A patch is available on
> request (or would it be ok to attach a 240-line patch
> here?). The patch is vs. ext/ldap/ldap.c 1.90 from CVS.

We have seen bigger patches, however, for something of
this size you should:
a) post the patch to thE PHP-DEV list.
b) apply for a CVS account to /ext/ldap
c) also create a patch for the documentation...  referral
chasing does no good if folks don't know what to do (or
how to chase it, or that it works now). The patch to allow
multiple servers never got documented, so many users
are still stuck with one server.

Because it is 240 lines, there might be some macros to speed
it up, which is another reason why peer review (on PHP-dev)
is a good idea.

-Ronastillwonderingaboutthe_mod_functionsbop

-- 
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] Fw: PHP XMF

[Ron Chmara]

On Saturday, July 21, 2001, at 06:43  PM, Michael Glazer wrote:
> Hi
> I was guessing that was the reason when you first said the 
> JavaScript link.
> Why would I test it with Netscape? I wouldn't. Waste of time to 
> be honest.
> The president of Netscape told me that their Netscape browser 
> doesn't work.

Okay, is this a race to get into a bit-bucket?

How about, oh, Opera for OS X, iCab, lynx,  Netscape, Mozilla? 
(there are about 20 Mil
pissed off MacOS users just around the corner...)

You see, PHP is a language that is installed and used on a 
*very* large number
of platforms, many of which that IE can't even hope to support.

If you offered patches to PHP, to be applied if needed, or used 
closed source,
for win32 folks, only, that could help your product.

If your openly contribue your product to the PHP source, with the
understanding that it will *fail* on many browsers, for many 
users,  but were
intending on fixing that problem, that could help.

As it is, your source is broken, on at least 3 browsers. And you don't
seem to be opening it up for repair.

And you don't seem to intend to fix it.

How does it help PHP to add standards-damaging (or standards breaking)
code into the code base?

Can't you just add it as a layer to pear?

-Bop

--2D426F70|759328624|00101101011001100111
[EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
The opinions expressed in this email are not necessarily those 
of myself,
my employers, or any of the other little voices in my head.

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

Re: [PHP-DEV] Security Issues

[Ron Chmara]

On Wednesday, July 25, 2001, at 11:31  PM, Sebastian Bergmann wrote:
> PHP wrote:
>> On Wed, Jul 25, 2001, Sebastian Bergmann wrote:
>>> Andy wrote:
>>>> If register_globals = off is highly recommended, why does the
>>>> default php.ini have register_globals=on
>>>   For backward compatibility reasons. We intend to break this,
>>> and other things, with either PHP 4.1 or PHP 5.
>>   Ah, you must be a PHP core developer!  So good to meet you!
>   No, not really. I'll fwd this to php-dev.

Where it'll be discussed, ad nauseam, by developers working 
in/on/around the core, as well as the core.
:-)

>> %foo // this is a different foo, it is read only and came in
>> via a POST or GET or otherwise.

Here's why this entire *concept* is silly:
I'll make a file...
-Badpage.html



-
Oh, and I should edit my cookies too just in case they're 
using sessions or other cookiesand now I've now rendered all 
of the HTTP_*_VARS features moot for variable "protection".

Every single one can be forged. GET, POST, COOKIES, SESSIONS, FILES.

Developers need to learn that user submitted vars, regardless of 
namespace, are always potentially bad. Period. Turning 
register_globals one way or another does absolutely *nothing* to 
fix it. Prepending get or post submissions with special tokens 
does not fix it. Simply using the variable order controls does 
not fix it. Any illusion of security, in this case, is purely 
aesthetic.

What *might* fix it?
1. Heavy duty random encryption of every variable. Which would 
make PHP amazingly slow.
2. Wise coding. (+1 on E_ALL as the default error level).
3. Coding for vars coming from bad places (POST that should be 
GET) resulting in server lockout (if somebody's hacking your 
vars, deny access, but pointless and damaging for proxy-based 
users like, oh, AOL.com)

I'm really lost on the point of the entire "no-globals" 
approach, other than using method #3., which is non-functional 
for large sites... but I code with #2, and check variables 
heavily.

If you want to protect your own vars, PHP already has those 
tools, in some manner (maybe a perl-like "taint" would help new 
developers? Anybody who lives and breathes perl might want to 
point out how it differs from E_ALL warnings and functionality, 
as I'm not fluent in taint usage and features...).

-Ron

--2D426F70|759328624|00101101011001100111
[EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
The opinions expressed in this email are not necessarily those 
of myself,
my employers, or any of the other little voices in my head.

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

Re: [PHP-DEV] Security Issues

[Ron Chmara]

On Wednesday, July 25, 2001, at 06:32  PM, Zeev Suraski wrote:
> Guys, look back at the advisory.  Apps written by *GOOD* PHP 
> coders who *ARE* aware of security issues were prone to 
> register_globals=on attacks.

telnetd on almost all of *BSD is a big hole right now.
Good coders make mistakes.

> As the guy said in the advisory, it's arguable whether it's the 
> language's responsibility to guide you to write a secure app, 
> or whether it's the coder's responsibility.  He says, and I 
> agree with him, that if the language 'encourages' you to write 
> insecure apps, by providing and streamlining insecure ways of 
> implementing functionality, the language is at fault.

I agree... somewhat. The manual didn't even have a dedicated 
security section until recently, and we are faced with hobbling 
PHP, and making it unusable for low level tasks (to insulate 
users from ever shooting themselves in the foot)
or:
creating many new functions that can not do things like write 
files, read files, open sockets, or other low level tasks (the 
javascript approach)
or:
failing to execute a PHP script which had warnings, errors, or 
otherwise had "problems"
or:
slowly migrating code which does bad things into good things.

If a user thinks of PHP in the same terms as javascript, PHP is 
evil, as it can do all sorts of things that javascript can't. 
That's a good thing. PHP. IMNSHO, is not just a web page 
counter, or popup, or pretty click. It is a full fledged 
language, that can do as much damage as giving the web surfer a 
shell. Coders need to treat it as such.

>   If most of the PHP apps out there are or were vulnerable to 
> register_globals=on attacks, we can't (shouldn't) blame the 
> whole world, but fix the language instead.

I'd suggest fixing the code religion instead, but changing 
faiths is hard. :-) If they aren't checking their vars before 
processing, no language would fix it, would it?

--2D426F70|759328624|00101101011001100111
[EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
The opinions expressed in this email are not necessarily those 
of myself,
my employers, or any of the other little voices in my head.

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

Re: [PHP-DEV] Failure compiling in IMAP.

[Ron Chmara]

Joshua Butcher wrote:
> I am recompiling php and apache for IMAP connectivity.  I had it working,
> then i installed RH 7.1 (to fix another problem on my machine) and I had to
> recompile Apache and PHP all over again.  When I go to compile PHP with IMAP
> connectivity (c-client.a is in the /usr/local/lib) folder, it dies.  During
> the configuration of PHP, its says it find the IMAP library fine... When I
> got to compile Apache with PHP it gives me the following errors:
> 
> /root/Apachetoolbox-1.5.34/src/php-4.0.6/ext/imap/php_imap.c:4147: undefined
> reference to `mail_newstringlist'
> /root/Apachetoolbox-1.5.34/src/php-4.0.6/ext/imap/php_imap.c:4148: undefined
> reference to `cpystr'
> /root/Apachetoolbox-1.5.34/src/php-4.0.6/ext/imap/php_imap.c:4155: undefined
> reference to `mail_newstringlist'
> /root/Apachetoolbox-1.5.34/src/php-4.0.6/ext/imap/php_imap.c:4157: undefined
> reference to `cpystr'
> modules/php4/libphp4.a(php_imap.o): In function `mm_list':
> /root/Apachetoolbox-1.5.34/src/php-4.0.6/ext/imap/php_imap.c:4174: undefined
> reference to `cpystr'
Snip_>
> 
> any thoughts you have would be great!

Well, I can confirm it's not just you. It's driving me batty. (Also on RedHat
7.1)

It happens with multiple versions of the c-client:
imap-2000c
imap-2001.BETA.SNAP-0105251616
imap-2001.BETA.SNAP-0106160125
imap-2001.BETA.SNAP-0107112053

The problem exists in both php-4.0.5 *and* php-4.0.6, with the following PHP
configure string:
./configure  --prefix=/usr --sysconfdir=/etc --with-ldap=/usr --with-mysql=/usr 
--with-pgsql=/usr --enable-gd-imgstrttf --with-gd=/usr
--with-jpeg-dir=/usr --with-png-dir=/usr --with-t1lib=/usr --with-tiff-dir=/usr 
--with-ttf=/usr/include/freetype2/freetype/ --with-zlib-dir=/usr
--with-pdflib=/usr --enable-bcmath --enable-calendar --enable-inline-optimization 
--enable-shared --enable-static --enable-sigchild --enable-sysvsem
--enable-sysvshm --enable-shmop --enable-memory-limit --enable-trans-sid 
--enable-track-vars --with-config-file-path=/etc/httpd/conf/ --with-imap=/usr
--with-mcrypt=/usr --with-mhash=/usr --with-mm=/usr --with-mod_charset 
--with-regex=system --with-curl=/usr --enable-ftp --with-openssl=/usr
--enable-ssl=/usr --enable-sockets --enable-magic-quotes 
--with-apache=/usr/local/src/apache_1.3.20 --with-pspell=/usr/lib
--with-cybercash=/usr/local/src/cybercash-mck/

And apache configure:
CFLAGS="-O2 -I/usr/ " \
LDFLAGS="-L/usr/kerberos/lib -lkrb5 -lgssapi_krb5 -lpam" \
EAPI_MM="SYSTEM" \
SSL_BASE="SYSTEM" \
./configure \
"--with-layout=RedHat" \
"--enable-module=ssl" \
"--activate-module=src/modules/php4/libphp4.a" \
"--activate-module=src/modules/extra/mod_ldap.c" \
"--enable-module=php4" \
"--enable-module=ldap" \
"--enable-module=all" \
"--enable-suexec" \
"--suexec-caller=nobody" \
"--suexec-uidmin=500" \
"--suexec-gidmin=500" \
"--suexec-umask=022"

PHP seems to compile it just fone (no errors):
make[2]: Entering directory `/usr/local/src/php-4.0.6/ext/imap'
make[3]: Entering directory `/usr/local/src/php-4.0.6/ext/imap'
gcc  -I. -I/usr/local/src/php-4.0.6/ext/imap -I/usr/local/src/php-4.0.6/main 
-I/usr/local/src/php-4.0.6 -I/usr/local/src/apache_1.3.20/src/include
-I/usr/local/src/apache_1.3.20/src/os/unix -I/usr/local/src/php-4.0.6/Zend 
-I/usr/local/src/cybercash-mck//c-api -I/usr/include/freetype
-I/usr/include/mysql -I/usr/include/pspell 
-I/usr/local/src/php-4.0.6/ext/xml/expat/xmltok 
-I/usr/local/src/php-4.0.6/ext/xml/expat/xmlparse
-I/usr/local/src/php-4.0.6/TSRM  -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -O2 -I/usr/  -c 
php_imap.c && touch php_imap.lo
/bin/sh /usr/local/src/php-4.0.6/libtool --silent --mode=link gcc  -I. 
-I/usr/local/src/php-4.0.6/ext/imap -I/usr/local/src/php-4.0.6/main
-I/usr/local/src/php-4.0.6 -I/usr/local/src/apache_1.3.20/src/include 
-I/usr/local/src/apache_1.3.20/src/os/unix -I/usr/local/src/php-4.0.6/Zend
-I/usr/local/src/cybercash-mck//c-api -I/usr/include/freetype -I/usr/include/mysql 
-I/usr/include/pspell
-I/usr/local/src/php-4.0.6/ext/xml/expat/xmltok 
-I/usr/local/src/php-4.0.6/ext/xml/expat/xmlparse -I/usr/local/src/php-4.0.6/TSRM  
-DSUPPORT_UTF8
-DXML_BYTE_ORDER=12 -O2 -I/usr/  -L/usr/kerberos/lib -lkrb5 -lgssapi_krb5 -lpam -o 
libimap.la  php_imap.lo  

And:

/bin/sh /usr/local/src/php-4.0.6/libtool --silent --mode=link gcc  -I. 
-I/usr/local/src/php-4.0.6/ -I/usr/local/src/php-4.0.6/main
-I/usr/local/src/php-4.0.6 -I/usr/local/src/apache_1.3.20/src/include 
-I/usr/local/src/apache_1.3.20/src/os/unix -I/usr/local/src/php-4.0.6/Zend
-I/usr/local/src/cybercash-mck//c-api -I/usr/include/freetype -I/usr/include/mysql 
-I/usr/include/pspell
-I/usr/local/src/php-4.0.6/ext/xml/expat/xmltok 
-I/usr/local/src/php-4.0.6/ext/xml/expat/xmlparse -I/usr/local/src/php-4.0.6/TSRM  
-DSUPPORT_UTF8
-DXML_BYTE_ORDER=12 -O2 -I/usr/  -L/usr/kerberos/lib -lkrb5 -lgssapi_krb5 -lpam -o 
libphp4.la -rpath /usr/local/src/php-4.0.6/libs -rdynamic
-L/usr/kerberos/lib -L/usr/local/src/cybercash-mck//c-api/lib -L/usr/lib/pgsql 
-L/u

Re: [PHP-DEV] Security Issues

[Ron Chmara]

On Saturday, July 28, 2001, at 12:52  PM, Zeev Suraski wrote:
> At 06:01 28/07/2001, Phil Driscoll wrote:
>>  I and no doubt thousands of others will turn
>> register_globals on because it gives much more readable code, 
>> much less
>> typing and does not IMHO add one jot to the security of my 
>> applications.
> I have no doubt that thousands would turn it back on.  I can't 
> do anything about it, and as I said numerous times in numerous 
> metaphors, I'm quite alright with that.

I have roughly 2,000 files to fix before I can use it with my 
biggest client :-)

>   I also can't imagine people avoiding PHP because variables 
> are accessed using $_FORM['foo'], instead of $foo.  People are 
> not *THAT* dumb or lazy.  Discussing this issue in the OSCon, 
> Rasmus claimed that right now he can teach PHP to a monkey in 3 
> hours, and he wouldn't want to be limited only to smart 
> Gorillas in the future.  I firmly believe that if a monkey can 
> figure out $foo, $_FORM['foo'] is not going to be the 
> showstopper.

Well, there's two *new* learning curves for the 
never-programmed-before user (monkey?).
1. Understanding arrays. The newest of the newbies are still 
trying to grok strings, and concepts like "get" or "post".
2. They have almost no examples, whatsoever, to use, for 
learning how to work with variables in this manner.

Both of these issues, combined, increase the "monkey" factor. 
Most online and printed tutorials available do not use 
HTTP_*_VARS (or any future TBI vars shorthand). The example 
code, all over php.net and zend.com, does not use it. Even if we 
encourage them to consider it "the right thing" to do, they 
don't really know how to go about doing it. I went to 
google.com, and typed in "PHP tutorials",and started looking 
around...
http://hotwired.lycos.com/webmonkey/99/21/index2a.html <- 
Explains HTTP_POST_VARS, but doesn't use it.
http://www.devshed.com/Server_Side/PHP/ <- Many tutorials, 
looked at a few, none used it.
http://www.linuxguruz.org/z.php <- Many tutorials, looked at a 
few, none used it.
http://www.phpdeveloper.org/ <- Many tutorials, looked at a few, 
none used it.

I think, perhaps, that this is one of the reasons that so much 
of the PHP codebase isn't usable with register_globals = off. 
The learning curve is steep, because it's basically 
undocumented, in terms of tutorials, examples, downloadable 
snippets/functions, etc. So we have a chicken/egg problem, where 
the new monkey has to make a big jump, and use a relatively 
hidden method of acccessing variables, because almost every 
tutorial on PHP is "wrong". Even the smart gorillas, (the ones 
writing the tutorials), aren't using it, probably because they 
never learned how/why to use it.. If we can fix #2, #1 may not 
require as much effort. As it currently stands, if would be akin 
to releasing a version of PHP where we suddenly required them 
(by default, disable if needed) to change every variable they 
used from $foo to %[foo].

So, beyond my normal ramble:
If we were to do this, we might want to start by putting 
examples in place, if only to show users _how_ to do it. Even if 
we don't, we still need to start populating examples, if only to 
show users how they _can_ work with register globals= off.

-Ronabop

--2D426F70|759328624|00101101011001100111
[EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
The opinions expressed in this email are not necessarily those 
of myself,
my employers, or any of the other little voices in my head.

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

Re: [PHP-DEV] Linux Today Article

[Ron Chmara]

Edin Kadribasic wrote:
> http://linuxtoday.com/news_story.php3?ltsn=2001-08-13-009-20-OP
> This guy claims that PHP has been 'left in the dust' by ASP.NET.

Uh... if a viable, tested, deployed product was shipping, that may
eventually be substantiated.

Quick show of hands: Who has deployed an enterprise .NET architecture?

If it's in the the dust, why is it's marketshare peanuts compared to PHP?

> Edin
> From the article:

(Warning: venting below:)

> There will be Apache defenders who will bristle at the suggestion that it is
> a vanilla webserver. Look at PHP, they will say. PHP actually has greater
> market share than ASP. You can build fantastic web applications with PHP at
> a fraction of the cost of any commercial alternatives, including Microsoft.

Not to mention faster, more extensible, more open, with more choices in
backends, and it can be deployed on more stable serving platforms. :-)

>  That's great, but when will PHP grow to become something more than a web
> scripting language?

About two years ago.

> Where is the PHP enterprise component architecture?

Vague marketing speak. Do they want millions of prewritten code blocks
to call, so programmers can "write" code based on somebody else's
catch-all, do all, code, slowing the app down to glacial VB/ASP speeds?

They already exist for PHP, if you want 'em. You barely have to
write an include (use/call/whatever) statement, and there's thousands
posted to www.php.net laready. If you don't want the horrible pain
of downloading 5 lines of code, PEAR is building out generic catch-all
objects and components, so you can use code not optimized for your
individual needs.

> What
> about clustering and failover?

Neither IIS nor apache offer true (coming from a VMS standpoint)
clustering. However, I am doing web server clustering already
with PHP, ldap, and postgresql.

> Where are the WSDL and UDDI implementations?

Ah, buzzword wars. Why not ask why PHP doesn't support CASE or
ROSE? (Because the skill of a technology in performing
a task is unrelated to which buzzword of the day is adopted.)

> Don't show me bits and pieces here and there.

Fine. Don't ask for components, then.

> Show me a framework.

Linux (base) Apache (web server) LDAP (auth) Postgres/MySQL (storage).

> Show me a
> reference implementation.

http://www.php.net
Now show me a high-speed ASP.NET site, with 20+ failover sites, 8+
languages, all running off of a common ASP code base... with less than
30 single CPU machines.

> Show me a friendly interface.

UltraEdit.

> Not there yet? So
> PHP has been left in the dust as well, while ASP is morphing into ASP.NET,
> the browser delivery front-end of the Microsoft web services platform.

FUD. And bad marketing flames. Maybe they wanted to bump up their hit count?

-Bop

-- 
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] Please..

[Ron Chmara]

David Hjortsoe wrote:
> Hi, 
> >  I'm more than welcome to accomidate you,
> >  and Zend, so we can get these issues resolved instead of having
> >  these constant bad feelings.
> As I wrote in my last email, what are those issues -- it would be nice
> to have them outlined in a comprehensible manner instead of, as now,
> they being implicitly refered to in various snide comments.

What I would like to know, (even though I've been trying to play it cool
since my MySQL rant, and getting into it with Zend and sas a bit back...)

1. If the relationship between Zend Tech and PHP becomes irreconcilable,
can PHP and Zend fork and/or recover in some other means? Is there an
'escape plan', or is this a death-spiral, where degrading communications
could actually kill one or both?

2. If all of the current PHP and Zend core developers die in a fire at
a convention, can the codebase continue, or will the ZE possibly become the
property of somebody who could demand $1,500 (USD) per server for licensing,
and lock down the source, thus killing PHP and Zend?

3. Is the Zend license preventing useful submissions from people who
write damn good code, but are FSF believers/zealots, so they refuse to
contribute, because it doesn't have the RMS seal of approval?

4. If an alternate engine was written, would it be possible to use
with PHP? Could an engine be written from Zend code, or would it
have to be clean-room code, and if so, from what version of PHP?

5. If, say, Microsoft beats Zeev and Andi in a Redmond basement for
three weeks, until they sign away all rights with bloody, mangled
hands, can PHP go forward, or does it have to back up? (See the
tim robbins "antitrust" movie... he becomes a software giant through
artful purchasing, and the occasional assasination...)

6. If a core member goes insane, can they damage PHP without
being held in check somehow? If half the core dies, is it distributed
enough that the other half can continue?

Core to the license debate:
7. Can the Q license currently used be adapted to meet the needs/fears
of GPL/BSD and similar folks, without compromising the Zend Tech needs
for having a saleable product? (there's quite a few licenses out there...)
from what I understand, Stallman's complaint are the credits clauses,
others are worried about selling closed source (ironically, isn't a
Zend package designed specifically for this pupose?)

Core to the debate debate:
8. Do some people just need to shoot off some steam, and accomodate
others who do? I get 1000+ emails a day, this is nothing in comparison.
Of course, I also go days without reading certain lists, which helps.
:-)

Rasmus, Zeev and Andi are not eternal, neither is PHP or Zend. Planning
now, however, makes the future easier. Some folks live in volatile parts
of the world about to go to war, :-) , some do not. Some take "breathers"
when they are angered, some do not. So I'm interested in how PHP survives
everything from worst case to best case... it seems bulletproof, in code
terms, because the Q license allows at least one form of forking, if not
several.

Having now re-read the Q license a few times, the PHP license a few
times, this seems unrelated to licensing, and more related to
"mindshare" or the power fluctuations of a given group, or
reactionary impulse to Zend being part commercial, part free. Even
in worst case, PHP could recover in months to a year or so, with the
hardest part being the social damage of bitter debate, or a focus
entirely on an engine rewrite.

I dunno. ANy lawyers on the list?

Anyways, I'm off to go play in the SF bay now. Have fun, folks!

-Bop

-- 
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] The PHP brainstorm

[Ron Chmara]

Kristian Koehntopp wrote:
> 
> I send this again, under a proper subject. You might want to use
> a slow Friday afternoon or the weekend to think about this, and
> write something up. Please do, we need your input.

1. Menu driven *nix self-installer:
-
Would you like me to obtain and build all software needed for
using the following with PHP:
1. MySQL
2. PostgreSQL
3. Oracle (Official installation disks my be needed)
4. Informix
Enter a single database number, or multiple numbers:
--

2. Db connection pooling support.

3. More documentation available for errors:
'Warning: Wrong number of arguments for foo:
Click *here* to see online documentation on "foo"'

4. Online docs for PEAR contributions.

5. PHP "Dashboard", an online php.ini editor, with GUI-based
control panel of all PHP (and apache?) settings.

-Bop

-- 
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] WHAT is PHP's vision????

[Ron Chmara]

Well, quite an interesting thread, with many side points.
My two cents below, with some side threads of their own. ;-/

Rasmus Lerdorf wrote:
> > Of course not. But currently the image for PHP is that it's ONLY
> > meant for web scripting. Even as it can be used in various other
> > places too.
> That has always been our position.  "PHP focuses on the Web problem".
> That has been the design roadmap, if you will, from day one.

A lot of this discussion and debate seems to confuse the problem, "easily
making dynamic web pages", with computer science designs (not having "private"
 is somehow the problem), or architecture decisions (using persistant
 across sessions, or processes, or whatever), or other ancilary
tasks to PHP's core strength. Rather than, oh, make web pages, much of
this discussion (and, it seems, emotion) was expended *not* on PHP making
web pages, but whether or not it did XYZ that a given programmer thinks
is "absolutely essential" for a given (web) language.

If the *problem* is making dynamic web pages, PHP is a great solution,
IMNSHO.

Of course, they're always room for improvements to solving a given
problem, but many of the arguments didn't seem to focus on "this
will make building dynamic web pages easier/faster/simpler", at
least not to my (admittedly jaded) eyes. Instead, the arguments
focused on how different people like to write their code, well,
differently, and suggested changing PHP to match differences, and,
as such, suggested that those matters of preference were problems
to be solved by PHP.

If the problem is "following an OO discipline", one could focus on more
OO-constrained environments, rather than PHP. PHP is not trying to focus
on pleasing an ideal code architecture spec, it's trying to make dynamic
web pages. It does some OO, but "pure OO" isn't related to making dynamic
web pages, so there's no real reason to sidetrack into fighting flamewars
about PHP following "True OO Discipline"... OO is not about making web
pages, it's simply a code style. PHP is about making web pages, not
learning or using OO.

If the problem is "storing something, in a specific fashion, to meet
a given idealized architecture for multiple dynamic pages", one could
investigate the various systems that meet whatever ideals they happen
to have. If the problem is storing something, that another web page
(or the same web page) can use, using a database and PHP can solve
the problem, to some rather absurd scalability limits. PHP is about
making dynamic web pages, not cool architecture diagrams of
"transporting a data object between clusters" (poking fun at Sun,
can you tell?)

If the problem is "using a coding construct that I prefer to write code
in", then one could investigate languages that appeal more to their
specific constructs. If, however, the problem is not with a personal
preference for code constructs, but simply making dynamic web pages,
then PHP is a great tool. It has all the basic primitives needed
to build dynamic pages.

If the problem is "I think a web application should be built and designed
in a specific way", perhaps folks could look at architectures that work
*their* way. If the problem is building complex web applications, with
dynamic web pages, PHP is great for solving that problem. It's not great
for acting like other platforms or languages, because its not... 
different languages are best coded for in different ways, and coding
complex applications for PHP is no exception.

Write code for (not just with, but specifically for) PHP, and it's
great to work with. Try to make PHP into C++, or Perl, or *any other
language or web application platform*, and PHP may seem to have
more "issues", not because it fails to solve the basic problem of
making dynamic web applications, but because it fails to solve the
problem of making dynamic web applications in a given, specific,
way for the individuals who would like PHP to have been designed
differently.

After watching at least 6 programmers "wash out" with PHP, they all
had a similar problem... they wanted PHP to act like their favorite
prior coding environment(s), and any differences were "flaws
in PHP".

They didn't want to deal with PHP's data structures, they wanted
PHP's data structures to behave their preferred way. They didn't
want PHP's variable scope, they wanted variable scope to behave
their preferred way. They didn't want the semi-stateless nature of
web pages, they wanted the server and/or client to be highly stateful
somehow. They didn't want to have, oh, 1 line of code to change
"foo123" to "$array[foo]" and "$array[123]", they wanted a "custom
method operating on the foo's object, with try-catch and a return
of a new object".

The "washed out" programmers didn't want to learn to code *for*
PHP, but simply code *with* PHP, and longed for it to work like
super-foo-platform-x. It didn't, so some complained (as in this
thread??) that it was PHP's failings that stopped them from
making their applic

[PHP-DEV] session related connection handling/cvs/mem

[Ron Lange]

Hi,
I have to build a extension for PHP, which is connecting to a special 
server over tcp/ip. For each session (client-php) a session related set of 
data has to be kept, inclusive the socket descriptors and so on.

1. How can I keep the relationship of the data and the session? The data 
consists of a c struct.

2. How I can determine which session is no longer used and can be freed?

3. At the moment my work rests in the cvs tree of our project, and I want 
them to stay there. How I can build the php extension (using php-internal 
build scripts) without great difficulties??? 

4. Our project uses own memory functions, since the sources will be 
compiled on several different platforms. Do I have to use zend's exxx 
memory functions?

regards
Ron

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

[PHP-DEV] compiling extension

[Ron Lange]

Hi all,
now I have only one really sucking problem: how I can compile extensions? I 
know that I am appearing a little bit stupid, just because of the hints of 
Derick an the others in a former thread...
But I can't get it work...

The core code of my extension (without any php-related stuff yet) laying in 
a external cvs tree. I just set up a proto file, and created a extension 
with it in the ext dir of my php-tree. Then I have copied the files out of 
the extension directory into the cvs dir where my code is laying. I thought 
that was a smart idea. 
According to Derick I phpized, configured an made it. Fine, the (empty) 
php-extension was compiled an everything seems right. 
But now I want to include and use my code. A simple inclusion of my header 
throws make errors. Expectable, I know. 
*where the hell I have to put my include and libary paths in???* 
And does php compile then also as a static apache module with my extensions?

Getting tired
Ron

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

[PHP-DEV] Re: compiling extension

[Ron Lange]

Ron Lange wrote:

...
> And does php compile then also as a static apache module with my
> extensions?

Uhm, sorry, I mean 'compile then also as an apache module with my static 
extension?'...
 
> Getting tired
> Ron


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

Re: [PHP-DEV] compiling extension

[Ron Lange]

Hi Fab,
I have left out some informations, sorry. I had a problem with including 
our lib headers, but now I managed it. Man pages are fine 
things...especially these of autoconf ;-). Another mistake I've done was to 
ignore the output of the ext-skel script, which is telling the further 
steps (./buildconf) to build extensions. Nobody's perfect...
Have a good night
Ron

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

Re: [PHP-DEV] compiling extension

[Ron Lange]

Hello again,
my last question for this week (I hope):
How can I include the sources of my lib in the php build??? Although it's 
compiling fine, the apache build fails about undefined references to my 
functions. I am really tired now, since four hours I am trying to solve 
this problem. May I am only stupid. Who knows.
Ron

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

Re: [PHP-DEV] compiling extension

[Ron Lange]

Hi Markus,

>
> You don't need to include your sources but a static library
> of your extension needs to be created which exports the
> symbols as needed and which gets statically linked into
> libphp4.so . 

How you build and link static libs automatically by modifying 
config.m4? Which macros have to be used? Which additional .m4 files have to 
be set? I am not deep involved in using autoconf, since until now I only 
used highly integrated development tools. 

> But since all you say is "it doesn't work" and
> you don't give any concrete error message, sample
> input/output or even sources, it's pretty hard to be exact,
> either.
...
Sorry, 'it doesn't work' is really flat. 

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

Re: [PHP-DEV] compiling extension

[Ron Lange]

A attempt to explain...

Source-Struktur:
--
 PHP-Tree  INDI-CVS
   ext   ...
@indi -->php
   *buildconf (php)   include
   *configure (php) indiComm.h  (indi communication protos)
  src
indiComm.c  (indi communication functions)

  indi.c(php extension code)
  php_indi.h(php extension protos)
  config.m4 (php)

Regards
Ron


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

[PHP-DEV] linking librarys into php4 extensions

[Ron Lange]

Hi,
I have set additional headers and AC_ADD_LIBRARY_WITH_PATH in the config.m4 
of my extension to link with external libs. The php 'make --with-extension 
--with-apache=[pathtoapache]' builds w/o errors, but at the following 
apache 'configure --activate-module=src/modules/php4/libphp4.a' I get 
follwing message:
 Error Output for sanity check 
cd ..; gcc  -DLINUX=22 -I/usr/src/php-4.2.1 -I/usr/src/php-4.2.1/main 
-I/usr/src/php-4.2.1/main -I/usr/src/php-4.2.1/Zend 
-I/usr/src/php-4.2.1/Zend -I/usr/src/php-4.2.1/TSRM 
-I/usr/src/php-4.2.1/TSRM -I/usr/src/php-4.2.1 -DNO_DL_NEEDED `./apaci` 
-o helpers/dummy helpers/dummy.c   -Wl,-rpath,/usr/src/INDI/lib  
-rdynamic -L/usr/src/INDI/lib -Lmodules/php4 -L../modules/php4
-L../../modules/php4 -lmodphp4   -llibmmem -llibndr -llibIndiComm -lcrypt 
-lresolv -lm -ldl -lnsl
 -lresolv -lcrypt   -lm -lcrypt -lexpat
/usr/i486-suse-linux/bin/ld: cannot find -llibmmem
collect2: ld returned 1 exit status
make: *** [dummy] Error 1
= End of Error Report =

 Aborting!
I wonder since the libs libmmem, libIndiComm and libndr(*.a and *.so) 
laying in the dirs which are set by -L. Any idea?

Regards 
Ron

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

Re: [PHP-DEV] linking librarys into php4 extensions

[Ron Lange]

Hi David, 
thanks a lot!
Regards
Ron

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

[PHP-DEV] functions of ext not available

[Ron Lange]

Hi guys,
I've successfully compiled my extension into php and apache...the test php 
file phpize generated (without dl()) shows:

Functions available in the test extension:
indi_newSession
indi_closeSession
indi_sessionExists
indi_startSearch
indi_viewThumb
indi_viewImage

But if I actually want to use the functions, I get for example:

Fatal error:  Call to undefined function:  indi_sessionexists() in 
/usr/local/apache/htdocs/indi/image.php on line 3

??? A look into the symbol table of libphp4.a shows the existence of my 
whole extension. No compile warnings or errors. No typos. 
Can anybody teach me the miracles of php build-in extensions?
Regards
Ron

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

[PHP-DEV] Re: functions of ext not available

[Ron Lange]

I am really tired. I just changed the function names into the xxx_xxx form, 
and it is going fine. Why doesn't anybody told me that xxxXXX naming isn't 
"very useful"???
Good night
Ron


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

[PHP-DEV] how to debug a php extension...

[Ron Lange]

hi,
in which way I could debug my extension (builtin, apachemodule)?
unfortunately I get segmentation faults of the forked apache proc, and I can 
only guess where it is. It's in a particular place, where I set up a socket 
and two fds. I don't use php_streams. Any hints?
Regards
Ron

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

Re: [PHP-DEV] how to debug a php extension...

[Ron Lange]

Hi David, hi Joseph,
thanks a lot, I have a very helpful backtrace now.
Regards 
Ron

David Eriksson wrote:

> On Tue, 16 Jul 2002, Ron Lange wrote:
> 
>> hi,
>> in which way I could debug my extension (builtin, apachemodule)?
>> unfortunately I get segmentation faults of the forked apache proc, and I
>> can only guess where it is. It's in a particular place, where I set up a
>> socket and two fds. I don't use php_streams. Any hints?
> 
>   http://bugs.php.net/bugs-generating-backtrace.php
> 
> -\- David Eriksson -/-
> 
> "I personally refuse to use inferior tools because of ideology."
> - Linus Torvalds


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

[PHP-DEV] sockets and fds

[Ron Lange]

Hello friends,
I have a couple of questions about sockets and file descriptors.
 
In my extension I make use of a ordinary c socket and two fds build on it. 
I want this connection to be kept over request, therefore I put a struct 
pointer containing this into the persistant_list of the zend engine. 

I made it like the mysql extension, which is looking for an already opened 
connection by zend_hash_find(). If a connection already exists, it will be 
used, if not, a new connection struct is malloced (not emalloc()) and 
inserted into a new list_entry, which is immediately hashed into the 
persistand list. As key I use a emalloced string, consisting of a prefix 
and the session id, since I need to map sessions to connections.
 
I've also implement a zend_list_destructor for a persistent resource, 
actual the allocated conn. struct. There the items of the struct will be 
freed by fclose(), close() and at last the whole struct by free().

The exported extension functions are calling sometimes not exported  
functions, which are not introduced by the function list macro. This 
functions do some not-zend-related-stuff, but make use of the allocated 
connection. 

The initialization of the connection succeed, the functions in the same 
request are working how I want them to, but the explicitly closing of the 
connection causes a segfault. If a new request attempts to reuse the 
connection, the fds are lost, respectively the connection struct pointer 
seems to be invalid -> segfault.

Now my questions: 
1. Is there anything to know about using standart c sockets and fds within 
php extensions?
2. Do pointers stay valid over request end, if they're malloced (not 
emalloc())?
3. Should anything be considered about additional c functions, which not 
exported? (if at all...)

I am not experienced with threads, therefore I might have forget some 
details...about allocations in threads an so on...

Good night and best regards
Ron


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

[PHP-DEV] Re: sockets and fds

[Ron Lange]

Arrrgghh, I left out a detail:
the segmentation faults occured in the io-fns and _free() of libc.
Bye
Ron


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

[PHP-DEV] shared extension linking

[Ron Lange]

Hello,
I need to link some external libs statically into a shared php extension. 
If I compile this extension statically with php, all external libs also 
linked statically in, the extension can be used.

I can't figure out how I have to modify the many configuration files to get 
the additional libs statically linked in if the extension is build 
seperately. I just insert '-L/pathtolibs -llibnames...' into the 
INCLUDES-var of config_vars.mk. Bad way, I know...

But if I want the extension to be compiled as shared object the additional 
libs are not linked statically in.

By the way, if I use phpize to prepare the extension, the proper php prefix 
isn't right set. I manually have to replace it in config_vars.mk.
Unfortunately the self-contained-extension-readme doesn't cover this issue.
Please help...

Regards
Ron

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

Re: [PHP-DEV] shared extension linking

[Ron Lange]

Hi David,
David Eriksson wrote:
> Use PHP_ADD_LIBRARY_WITH_PATH or PHP_ADD_LIBRARY in your config.m4
> 
Already done...
My config.m4:
Note: IndiComm, ndr and mmem have to be statically linked into this module!
--
INDI_PROJECT_PATH="/home/ron/INDI"

PHP_ARG_ENABLE(indi, whether to enable indi support,
[  --enable-indi   Enable indi support])

if test "$PHP_INDI" != "no"; then
   AC_ADD_INCLUDE($INDI_PROJECT_PATH/include)
   AC_ADD_INCLUDE($INDI_PROJECT_PATH/GUI/include)
   AC_ADD_INCLUDE($INDI_PROJECT_PATH/NDR/include)
   AC_ADD_INCLUDE($INDI_PROJECT_PATH/include/dacs)
   PHP_ADD_LIBRARY_WITH_PATH(IndiComm,$INDI_PROJECT_PATH/lib)
   PHP_ADD_LIBRARY_WITH_PATH(ndr,$INDI_PROJECT_PATH/lib)
   PHP_ADD_LIBRARY_WITH_PATH(mmem,$INDI_PROJECT_PATH/lib)
   PHP_EXTENSION(indi, $ext_shared)
fi
--
My Makefile.in:
--
# $Id$
LTLIBRARY_SOURCES   = indi.c
LTLIBRARY_SHARED_NAME   = indi.la

include $(top_srcdir)/build/dynlib.mk
--
Now the steps I walked throug according to README.SELF-CONTAINED-EXTENSIONS:

First I modified config.m4 and Makefile.in. Then I run phpize in this dir. 
After running ./configure the prefix in config_vars.mk isn't set right. I 
modify each wrong path...
Now I make: The additional libs don't occour in the make output...hmmm
After that I just insert '-L/home/ron/INDI/lib -lIndiComm -lmmem -lndr' 
into the INCLUDES var in config_vars.mk. After the following make the libs 
occour in the output. Fine...but if the module is dl()ed in a script, php 
complains about missing shared objects...
Regards
Ron

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

Re: [PHP-DEV] shared extension linking

[Ron Lange]

Hi David,
thank you, at least the linking seems to be done now. But if I test the 
module via dl() following error occours:

Warning: Unable to load dynamic library './indi.so' - libmmem.so: cannot 
open shared object file: No such file or directory in /usr/local/ 
apache/htdocs/indi/indi.php on line 3

I want the libs to be *statically* linked into my php module.
Regards 
Ron  

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