Re: [PHP-DEV] Setting up RFC

[Stig Sæther Bakken]

["Jeroen van Wolffelaar" <[EMAIL PROTECTED]>]
> Hi,
> 
> About a month ago there was a discussion on the Engine 2 mailing list, about
> a possible RFC-proces for the more imporant PHP-issues. In the end, there
> was some consensus that it would be good if such a system exists.
> 
> I'm simply writing to get some comments, to hear what the general opinion
> is. If that is not negative, I think it should be tried to set it up.
> 
> 
> About the details, there needs to be discussion of course, but it would be
> more efficient to discuss those things after a proposal has been made, in
> stead of construct such a proposal by discussion.
> 
> Joey Smith and Zak Great supported the idea on the list, but the discussion
> went dead. Below I quote some of their mails.

Hi,

I think one of the problems with this is that even if php-dev comes up
with a system for determining which feature it wants to see in PHP, we
still depend on Zeev, Andi or someone else @ Zend to implement them.
An RFC system would be a support for Zend's decision-making.  At the
end of the day, due to the licensing issues, php-dev is not the body
governing the language, it has an advisory role only.

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
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 #12744 Updated: Command line option -c failing

[sniper]

ID: 12744
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: PHP options/info functions
Operating System: 
PHP Version: 4.0.6
New Comment:

Works for me with latest CVS so it seems to have been
fixed. Try a snapshot: http://snaps.php.net/

--Jani


Previous Comments:


[2001-08-14 18:49:56] [EMAIL PROTECTED]

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 this 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 #12747 Updated: ***BUG in Autoconf--please report***

[sniper]

ID: 12747
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Old Bug Type: *Compile Issues
Bug Type: Compile Failure
Operating System: Mandrake Linux 8.0
PHP Version: 4.0CVS-2001-08-14
New Comment:

I think your cvs checkout isn't quite 'clean'.
Try to do a clean checkout first.

To be sure which tools PHP finds, run:

# build/buildcheck.sh

As the first error would indicate that there
is something wrong with those..

--Jani


Previous Comments:


[2001-08-14 20:05:37] [EMAIL PROTECTED]

autoconf-2.13-7.mdk
automake-1.4-15mdk
libtool-1.4

Trying to compile the cvs version of PHP. After updating from the CVS server and 
running ./buildconf.

[onaias@frodo php4]$ ./buildconf
aclocal: configure.in: 895: macro `AM_PROG_LIBTOOL' not found in library
rebuilding Makefile templates
rebuilding Makefile templates
rebuilding configure
autoconf: Undefined macros:
***BUG in Autoconf--please report*** AC_ADD_INCLUDE
configure.in:442:PHP_AC_BROKEN_SPRINTF
rebuilding main/php_config.h.in
[onaias@frodo php4]$






Edit this bug report at http://bugs.php.net/?id=12747&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 #12515 Updated: PHP-Compilation sucks: php_mnogo.h:76: Floating point numbers not allowed in #i

[gluke]

ID: 12515
Updated by: gluke
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: mnoGoSearch related
Operating System: Suse Linux 7.2, Kernel 2.4.x
PHP Version: 4.0.6
New Comment:

To be more exact i can tell that i will update mnogosearch php extenstion after 
release of mnogosearch-3.2.x, because of its fast API changes.

Previous Comments:


[2001-08-01 13:49:34] [EMAIL PROTECTED]

A development version of Mnogosearch won't work with PHP 4.0.6..you should use the 
3.1.3.5 version instead.

--Jani




[2001-08-01 11:39:43] [EMAIL PROTECTED]

Hi, 

I can't compile my PHP 4.0.6+Apache 1.3.20 with mnogosearch support. I get the 
followíng error: 

## 
/main -I/usr/local/src/php-4.0.6 -I/usr/local/apache/1.3.20/include 
-I/usr/local/src/php-4.0.6/Zend -I/usr/local/openssl/current/include 
-I/usr/include/freetype -I/usr/local/mnoGoSearch/current/include 
-I/usr/local/mysql/current/include/mysql -I/usr/lib/db2/db2inst1/sqllib/include 
-I/usr/local/lib/libswf/include -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 
-DLINUX=22 -DDEV_RANDOM=/dev/random -DMOD_SSL=208104 -DUSE_HSREGEX -DEAPI -DUSE_EXPAT 
-DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -g -O2 -c internal_functions.c 
In file included from internal_functions.c:37: 
/usr/local/src/php-4.0.6/ext/mnogosearch/php_mnogo.h:76: Floating point numbers not 
allowed in #if expressions 
In file included from /usr/lib/db2/db2inst1/sqllib/include/sqlcli1.h:42, 
from /usr/local/src/php-4.0.6/ext/odbc/php_odbc.h:170, 
from internal_functions.c:39: 
/usr/lib/db2/db2inst1/sqllib/include/sqlcli.h:718: warning: `ODBCVER' redefined 
/usr/local/src/php-4.0.6/ext/odbc/php_odbc.h:27: warning: this is the location of the 
previous definition 
make[2]: *** [internal_functions.lo] Error 1 
make[2]: Leaving directory `/usr/local/src/php-4.0.6/main' 
make[1]: *** [all-recursive] Error 1 
make[1]: Leaving directory `/usr/local/src/php-4.0.6/main' 
make: *** [all-recursive] Error 1 
# 


Without mnogosearch support I can compile Apache with PHP. 
I have mnogosearch 3.2.0.b0. 

Can somebody help me? 

Thanks 

Stefan 





Edit this bug report at http://bugs.php.net/?id=12515&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 #12369 Updated: mnoGoSearch extension

[gluke]

ID: 12369
Updated by: gluke
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: mnoGoSearch related
Operating System: Windows
PHP Version: 4.0.6
New Comment:

mnoGoSearch developers probably will do that. But i cannot tell you when this work 
will be finished.

Previous Comments:


[2001-07-25 12:20:06] [EMAIL PROTECTED]

Hi,

Can you please tell me if you, or any of other developers managed to port mnoGoSearch 
extension to Windows (as dll).

Thanks in advance,
  Roman





Edit this bug report at http://bugs.php.net/?id=12369&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 #12755 Updated: Viewing and inserting the data in the table

[sniper]

ID: 12755
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Old Bug Type: Any
Bug Type: *General Issues
Operating System: unix
PHP Version: 4.0.6
New Comment:

not php problem.

Ask this kind of support questions on some mailing list.

http://www.php.net/support.php


Previous Comments:


[2001-08-15 02:59:04] [EMAIL PROTECTED]

1.If I want to view the content of the table ,Iam getting this message,Please suggest 
me the solution

mala=> select * from APPFORMtable;
Field| Value
(0 rows)



2.If I want to add the data in the table which is in the word format.Please suggest me 
the solution for which I can add the data at one shot .





Edit this bug report at http://bugs.php.net/?id=12755&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 #12755: Viewing and inserting the data in the table

[srimala]

From: [EMAIL PROTECTED]
Operating system: unix
PHP version:  4.0.6
PHP Bug Type: Any
Bug description:  Viewing and inserting the data in the table 

1.If I want to view the content of the table ,Iam getting this
message,Please suggest me the solution

mala=> select * from APPFORMtable;
Field| Value
(0 rows)



2.If I want to add the data in the table which is in the word format.Please
suggest me the solution for which I can add the data at one shot .
-- 
Edit bug report at: http://bugs.php.net/?id=12755&edit=1


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

Re: [PHP-DEV] Setting up RFC

[derick]

On Tue, 14 Aug 2001, John Donagher wrote:

> With what end in mind is an RFC to be created for? In the IETF, RFC's are
> typically long, complex, and authoritative. They are often referenced for years
> after their inception. Do you honestly think we could (or want to) achieve this
> with PHP feature RFC's? Or will they be used only before initial feature
> implementation, then quickly outdated and discarded? That is my biggest problem
> with documents: they take a lot of effort to create, are often difficult to
> grok, and _almost always_ have a very short lifecycle.

Although probable PHP RFC's won't be as complex as IETF RFC's, I still
think the main problem is that almost every developer hates it to write
docs. Doc writing is the most worse thing of software developing, I think
most people will agree with me on this.

However I think the whole RFC will lurk up too much of our precious time.
The idea may be good, but I don't think it will work out as it is intended
to be.

regards,

Derick Rethans

-
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
 SRM: Site Resource Manager - www.vl-srm.net
-


-- 
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 #12751 Updated: Form.php Pear Class errors

[derick]

ID: 12751
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: *Programming Data Structures
Operating System: linux debian2.3
PHP Version: 4.0.6
New Comment:

Can you please resend your patch to [EMAIL PROTECTED]? (As attachment)

Derick

Previous Comments:


[2001-08-14 22:35:33] [EMAIL PROTECTED]

Here's a copy of the diff between your Form.php and the corrected one I made. 

===
RCS file: Form.php,v
retrieving revision 1.1
diff -r1.1 Form.php
302c302
<   $size = 1, $blank = '', $multiple = false)
---
>   $size = 1, $blank = '', $multiple = false, $attrib = '')
305c305
<  $blank, $multiple);
---
>  $blank, $multiple, $attrib);
501c501
<   $blank = '', $multiple = false)
---
>   $blank = '', $multiple = false, $attrib = '')
506c506
< $str .= $this->returnSelect($name, &$entries, $default, $size, $blank, 
$multiple);
---
> $str .= $this->returnSelect($name, &$entries, $default, $size, $blank, 
>$multiple, $attrib);





Edit this bug report at http://bugs.php.net/?id=12751&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 #12748 Updated: changing allow_url_fopen from "off" to "on" crashes fopen()

[sniper]

ID: 12748
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Reproducible crash
Operating System: redhat-7.1b
PHP Version: 4.0.6
New Comment:

Could you please try latest CVS snapshot from http://snaps.php.net/ to verify if this 
still exists..

Also, what is redhat-7.1b ? (the b there..?)

--Jani


Previous Comments:


[2001-08-14 20:24:01] [EMAIL PROTECTED]

Using 
Apache-1.3.20
PHP-4.0.6
glibc-2.2.3

PHP compiled as DSO, no other options
./configure  --with-apxs=/usr/local/apache/bin/apxs

Note, this is not the same as bug #9672
Updating glibc does solve that problem see
http://bugs.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=2181

/usr/local/lib/php.ini
[PHP]
engine = On
allow_url_fopen = Off

My httpd.conf contains (in a VirtualHost),
  php_admin_flag allow_url_fopen On

A test script
http://www.php.net";, "r" );
if( $fp )
{
fclose($fp);
print "fopen() success\n";
}
?>

Backtrace:
#0  __strtol_internal (nptr=0x403adba0 "", endptr=0x81128bc,
base=4,
group=-1073748792) at eval.c:36
#1  0x402bee14 in zend_hash_find (ht=0x403adba0,
arKey=0x81128bc "http://www.php.net";, nKeyLength=4,
pData=0xbfffe4c8)
at zend_hash.c:850
#2  0x402cd259 in php_fopen_url_wrapper (path=0x81128bc
"http://www.php.net";,
mode=0x810d5c4 "r", options=4, issock=0xbfffe508,
socketd=0xbfffe50c,
opened_path=0x0) at fopen_wrappers.c:445
#3  0x4031f2fb in php_if_fopen (ht=2,
return_value=0x810d5a4, this_ptr=0x0,
return_value_used=1) at file.c:639
#4  0x402acd5c in execute (op_array=0x8109efc) at
./zend_execute.c:1504
#5  0x402bae95 in zend_execute_scripts (type=8,
file_count=3) at zend.c:752
#6  0x402cc30b in php_execute_script
(primary_file=0xb890) at main.c:1206
#7  0x402c8bae in apache_php_module_main (r=0x8107644,
display_source_mode=0)
at sapi_apache.c:89
#8  0x402c9541 in send_php (r=0x8107644,
display_source_mode=0, filename=0x0)
at mod_php4.c:536
#9  0x402c956a in send_parsed_php (r=0x8107644) at
mod_php4.c:547
#10 0x080558d3 in ap_invoke_handler () at eval.c:41
#11 0x08069667 in process_request_internal () at eval.c:41
#12 0x080696c8 in ap_process_request () at eval.c:41
#13 0x08060b69 in child_main () at eval.c:41
#14 0x08060d14 in make_child () at eval.c:41
#15 0x08060e88 in startup_children () at eval.c:41
#16 0x080614d7 in standalone_main () at eval.c:41
#17 0x08061cf3 in main () at eval.c:41
#18 0x400ca6b7 in __libc_start_main (main=0x806195c ,
argc=2,
ubp_av=0xbb64, init=0x804ead0 <_init>,
fini=0x80969bc <_fini>,
rtld_fini=0x4000db64 <_dl_fini>, stack_end=0xbb5c)
at ../sysdeps/generic/libc-start.c:129







Edit this bug report at http://bugs.php.net/?id=12748&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 #8874 Updated: ftp_nlist and rawlist not working

[sniper]

ID: 8874
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: FTP related
Operating System: Windows 2000 Advanced Server
PHP Version: 4.0.4
New Comment:

This bug report was for PHP 4.0.4. There have been a few
changes since that in PHP 4.0.6. Have you tried with it?

And also, these functions do work on most ftp servers. What was the version of the ftp 
server on which this didn't work?

--Jani


Previous Comments:


[2001-08-14 21:07:00] [EMAIL PROTECTED]

$aFiles = Array( "Oct100.log.gz", "Nov100.log.gz");

// $aFiles = ftp_rawlist  (nFTP, "/mnt/web/guide/accumeddata/logs/*.gz");

$aFiles = ftp_nlist ( $nFTP, "*.gz");

echo "count(aFiles)=" . count ($aFiles ) . "";





[2001-08-14 20:10:30] [EMAIL PROTECTED]

can you provide a smaller script that produces the bug please. preferably less than 
ten lines of code which requires nothing other than the bare min.. IE no extenal files 
etc.



[2001-07-22 00:23:57] [EMAIL PROTECTED]

Thanks for responding.  I no longer have access to the FreeBSD FTP server that I was 
connecting to, so it is no longer an issue (for me).  My script is attached below.   
If you do see an issue with the code, I am still interested in your response.

";

for ( $i=0; $i < count ($aDomain) ; )
  {
  
  if ( $bDebug )
echo "Openning \"" . $aDomain[$i] . "\"...";

  $nFTP = ftp_connect ( $aDomain[$i] );

  if ( $nFTP == 0 )
{
echo "Failed to open $aDomain[$i]. Aborting...";
exit();
}

  $nResult = ftp_login ( $nFTP, $aDomain[$i+1], "password" );
  if ( $nResult == 0 )
{
echo "Failed to login to $aDomain[$i]. Aborting...";
exit();
}
  else
echo "Login to $aDomain[$i] succeeded.";

  if ( $bDebug)
echo "ftp_pwd=" . ftp_pwd ( $nFTP ) . "".

  $nResult = ftp_chdir ( $nFTP, "logs");
  if ( $nResult == 0)
{
echo "ftp_chdir failed.  Aborting...";
exit();
}

  if ( $bDebug)
echo "ftp_pwd=" . ftp_pwd ( $nFTP ) . "".

  $aFiles = Array( "Oct100.log.gz",
   "Nov100.log.gz",
   "Dec100.log.gz",
   "mtd.log");

  // $aFiles = ftp_rawlist ( $nFTP, "/mnt/web/guide/accumeddata/logs/*.gz");
  // echo "rawlist = " . count ( $aFileList ) . "";
  // $aFiles = ftp_nlist ( $nFTP, "*.gz");

  if ( $bDebug )
{
echo "count(aFiles)=" . count ($aFiles ) . "";
for ( $j=0; $j <= count($aFiles); $j++ )
  echo "$j=\"$aFiles[$j]\""; 
}

  // Get all the Monthly archives (*.GZ)
  for ( $j=0; $j < count($aFiles); $j++ )
{

$sLocalFile = $aDomain[$i] . "-" . $aFiles[$j];
$sLocalFile = str_replace ( "/", "-", $sLocalFile );
$sRemoteFile = $aFiles[$j];

if ( $bDebug)
  {
  echo "sLocalFile=\"$sLocalFile\"";
  echo "sRemoteFile=\"$sRemoteFile\"";
  }

$nResult = ftp_get ( $nFTP, $sLocalFile, $sRemoteFile, FTP_BINARY );

if ( $nResult == 0)   
  {
  echo "ftp_get failed.  Aborting...";
  exit();
  }
}

  // Get the current month also.
  $nResult = ftp_get ( $nFTP, $sLocalFile, "mtd.log", FTP_BINARY );

  if ( $nResult == 0)   
{
echo "ftp_get of mtd.log failed.  Aborting...";
exit();
}

  $nResult = ftp_quit ( $nFTP );
  if ( $nResult == 0 )   
{
echo "ftp_quit failed.  Aborting...";
exit();
}

  $i = $i + 2;
  }


?>



[2001-07-21 21:27:45] [EMAIL PROTECTED]

Please submit a short script for me the analyze.  This will
also clarify your bug a little bit.



[2001-01-23 22:23:49] [EMAIL PROTECTED]

The ftp_nlist and ftp_rawlist functions failed to work for me.  I am using PHP.EXE 
v4.0.4 from a Windows 2000 machine connecting to a Free BSD box running the following 
FTP server:

Our.ftp.server FTP server (Version wu-2.6.1(1) Mon Jul 3 03:07:01 EDT 2000)

Both ftp_nlist and ftp_rawlist return a single blank string ("") into the result 
array.






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


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

Re: [PHP-DEV] Setting up RFC

[Zak Greant]

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

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

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

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

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

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

--zak


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

Re: [PHP-DEV] Setting up RFC

[jimw]

Zak Greant <[EMAIL PROTECTED]> wrote:
> :) I should have chosen the symbols more carefully. 
> They seem to have generated more comments than the original proposal...
> 
> Does anyone have any comments pertaining to the *concept*? :)

i was trying to drive at the point that you've just restated a
slightly weaker form of the apache project guidelines.

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

the real problem is determining who gets to vote.

jim

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

[PHP-DEV] Bug #12753: stristr Bug

[Darwin]

From: [EMAIL PROTECTED]
Operating system: Linux 7.1
PHP version:  4.0.6
PHP Bug Type: Unknown/Other Function
Bug description:  stristr Bug

There appears to be a bug in the stristr function.  If $haystack contains a
string that includes "" and $needle is "", then this function fails. 
However, if we keep $haystack the same and change $needle to "", the
function works.  This is very odd, since I have only observed this behavior
in this particular instance, no where else...

Take care,
Darwin

-- 
Edit bug report at: http://bugs.php.net/?id=12753&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] fileperms(), fileinode(), filesize(), is_readable(), etc.

[Sterling Hughes]

As an issue for PHP 5 (or PHP 4.1 for that matter), perhaps we
should remove these functions and just stick with stat() and lstat()
calls?  This would remove a bunch of functions which aren't
really that necessary (I'm probably just being a minimalist, but I
figured I'd bring it up :)

-Sterling


-- 
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] shell_exec()

[Sterling Hughes]

Hi,

What's the purpose of this function? It's prototype is:

/* {{{ proto string shell_exec(string cmd)
   Use pclose() for FILE* that has been opened via popen() */


What advantage does this have over something like exec() or
system()?

-Sterling


-- 
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 #12752: preg_replace eats '$' characters

[ruben]

From: [EMAIL PROTECTED]
Operating system: Linux Redhat 7.1
PHP version:  4.0.6
PHP Bug Type: PCRE related
Bug description:  preg_replace eats '$' characters

The preg_replace function seems to dissapear '$' characters, and up to two
more numeric characters after it. If the character after the dollar sign is
not a number, it works as expected.

$string = 'sum: {token} pesos.';
$number= '$123,456.78';
$number2='$ 123,456.78';
echo  "Wrong: ".preg_replace("/\{token\}/i",$number,$string);
echo  "Right: ".preg_replace("/\{token\}/i",$number2,$string);

My configure line:
'./configure' '--with-apxs' '--with-pgsql' '--without-mysql'
'--with-openssl' '--enable-ftp' '--with-gd' '--enable-gd-native-ttf'
-- 
Edit bug report at: http://bugs.php.net/?id=12752&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: Bug #12581 Updated: ....

[Lawrence E. Widman]

Jani,

> ID: 12581
> Updated by: sniper
> Reported By: [EMAIL PROTECTED]
> Old Status: Feedback
> Status: Closed
> Bug Type: dBase related
> Operating System: Linux 2.2.16-3
> PHP Version: 4.0.6
> New Comment:
> 
> Patch committed. Thanks!

And thank you! - Larry Widman




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

Re: [PHP-DEV] Setting up RFC

[Zak Greant]

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

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

--zak

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


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


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

Re: [PHP-DEV] Setting up RFC

[jimw]

Sterling Hughes <[EMAIL PROTECTED]> wrote:
>Actually, (+-) 0 are really terms and votes, in other projects I've
>been involved in, there interpreted as "I don't like it, but I won't
>stop you" and "I like it, but its not something I think is
>absolutely necessary"

right.

http://dev.apache.org/guidelines.html is probably worth reading for
folks not familiar with the apache project's process.

this presentation is worth checking out, too:

  http://www.ics.uci.edu/~fielding/talks/apache98/index.htm

jim

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

[PHP-DEV] Bug #12751: Form.php Pear Class errors

[lani]

From: [EMAIL PROTECTED]
Operating system: linux debian2.3
PHP version:  4.0.6
PHP Bug Type: *Programming Data Structures
Bug description:  Form.php Pear Class errors

Here's a copy of the diff between your Form.php and the corrected one I
made. 

===
RCS file: Form.php,v
retrieving revision 1.1
diff -r1.1 Form.php
302c302
<   $size = 1, $blank = '', $multiple = false)
---
>   $size = 1, $blank = '', $multiple = false, $attrib =
'')
305c305
<  $blank, $multiple);
---
>  $blank, $multiple, $attrib);
501c501
<   $blank = '', $multiple = false)
---
>   $blank = '', $multiple = false, $attrib =
'')
506c506
< $str .= $this->returnSelect($name, &$entries, $default, $size,
$blank, $multiple);
---
> $str .= $this->returnSelect($name, &$entries, $default, $size,
$blank, $multiple, $attrib);
-- 
Edit bug report at: http://bugs.php.net/?id=12751&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 #12750: No echo call in example code

[bwise]

From: [EMAIL PROTECTED]
Operating system: N/A
PHP version:  4.0.6
PHP Bug Type: Documentation problem
Bug description:  No echo call in example code

On the manual page:
http://www.php.net/manual/en/language.oop.constructor.php

The following code lacks an "echo" in function C (shown in square
brackets).
---
class A {
  function A() {
echo "I am the constructor of A.\n";
  }
}
class B extends A {
  function C() {
[should have echo here?] "I am a regular function.\n";
  }
}
// no constructor is being called in PHP 3.
$b = new B;

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


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

Re: [PHP-DEV] Setting up RFC

[Sterling Hughes]

On Tue, 14 Aug 2001, Zak Greant wrote:

> Joey wrote:
> > > Are you doing a new O'Reilly book, PHP-DEV in a nutshell?
>
> Subtitled: A Rogues Gallery ;)
>
> > > -Sterling
> >
> > I especially enjoy the idea of "positive zero" and "negative
> > zero". :)
>
> I think that +/-0 would accurately portray the sometimes
> odd nature of support for proposals. ;)
>
> --zak


Actually, (+-) 0 are really terms and votes, in other projects I've
been involved in, there interpreted as "I don't like it, but I won't
stop you" and "I like it, but its not something I think is
absolutely necessary"

Sort of the concept of either abstaining -- or abstaining with an
objection.

-Sterling


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

Re: [PHP-DEV] Setting up RFC

[Zak Greant]

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

Subtitled: A Rogues Gallery ;)

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

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

--zak


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

Re: [PHP-DEV] Setting up RFC

[Joey Smith]

> > +1: Strongly Support
> > +0: Support
> >  0: Neutral
> > -0: Oppose
> > -1: Strongly Oppose
> 
> Are you doing a new O'Reilly book, PHP-DEV in a nutshell?
> 
> -Sterling

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


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

Re: [PHP-DEV] Setting up RFC

[Sterling Hughes]

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

:)

> * "The characters and opinions portrayed and the names used herein are
> fictitious and any
> resemblance to the names, character, or history of any person is
> coincidental and unintentional!" ;)
>
> +1: Strongly Support
> +0: Support
>  0: Neutral
> -0: Oppose
> -1: Strongly Oppose

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

-Sterling



-- 
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 #8874 Updated: ftp_nlist and rawlist not working

[steve]

ID: 8874
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: FTP related
Operating System: Windows 2000 Advanced Server
PHP Version: 4.0.4
New Comment:

$aFiles = Array( "Oct100.log.gz", "Nov100.log.gz");

// $aFiles = ftp_rawlist  (nFTP, "/mnt/web/guide/accumeddata/logs/*.gz");

$aFiles = ftp_nlist ( $nFTP, "*.gz");

echo "count(aFiles)=" . count ($aFiles ) . "";



Previous Comments:


[2001-08-14 20:10:30] [EMAIL PROTECTED]

can you provide a smaller script that produces the bug please. preferably less than 
ten lines of code which requires nothing other than the bare min.. IE no extenal files 
etc.



[2001-07-22 00:23:57] [EMAIL PROTECTED]

Thanks for responding.  I no longer have access to the FreeBSD FTP server that I was 
connecting to, so it is no longer an issue (for me).  My script is attached below.   
If you do see an issue with the code, I am still interested in your response.

";

for ( $i=0; $i < count ($aDomain) ; )
  {
  
  if ( $bDebug )
echo "Openning \"" . $aDomain[$i] . "\"...";

  $nFTP = ftp_connect ( $aDomain[$i] );

  if ( $nFTP == 0 )
{
echo "Failed to open $aDomain[$i]. Aborting...";
exit();
}

  $nResult = ftp_login ( $nFTP, $aDomain[$i+1], "password" );
  if ( $nResult == 0 )
{
echo "Failed to login to $aDomain[$i]. Aborting...";
exit();
}
  else
echo "Login to $aDomain[$i] succeeded.";

  if ( $bDebug)
echo "ftp_pwd=" . ftp_pwd ( $nFTP ) . "".

  $nResult = ftp_chdir ( $nFTP, "logs");
  if ( $nResult == 0)
{
echo "ftp_chdir failed.  Aborting...";
exit();
}

  if ( $bDebug)
echo "ftp_pwd=" . ftp_pwd ( $nFTP ) . "".

  $aFiles = Array( "Oct100.log.gz",
   "Nov100.log.gz",
   "Dec100.log.gz",
   "mtd.log");

  // $aFiles = ftp_rawlist ( $nFTP, "/mnt/web/guide/accumeddata/logs/*.gz");
  // echo "rawlist = " . count ( $aFileList ) . "";
  // $aFiles = ftp_nlist ( $nFTP, "*.gz");

  if ( $bDebug )
{
echo "count(aFiles)=" . count ($aFiles ) . "";
for ( $j=0; $j <= count($aFiles); $j++ )
  echo "$j=\"$aFiles[$j]\""; 
}

  // Get all the Monthly archives (*.GZ)
  for ( $j=0; $j < count($aFiles); $j++ )
{

$sLocalFile = $aDomain[$i] . "-" . $aFiles[$j];
$sLocalFile = str_replace ( "/", "-", $sLocalFile );
$sRemoteFile = $aFiles[$j];

if ( $bDebug)
  {
  echo "sLocalFile=\"$sLocalFile\"";
  echo "sRemoteFile=\"$sRemoteFile\"";
  }

$nResult = ftp_get ( $nFTP, $sLocalFile, $sRemoteFile, FTP_BINARY );

if ( $nResult == 0)   
  {
  echo "ftp_get failed.  Aborting...";
  exit();
  }
}

  // Get the current month also.
  $nResult = ftp_get ( $nFTP, $sLocalFile, "mtd.log", FTP_BINARY );

  if ( $nResult == 0)   
{
echo "ftp_get of mtd.log failed.  Aborting...";
exit();
}

  $nResult = ftp_quit ( $nFTP );
  if ( $nResult == 0 )   
{
echo "ftp_quit failed.  Aborting...";
exit();
}

  $i = $i + 2;
  }


?>



[2001-07-21 21:27:45] [EMAIL PROTECTED]

Please submit a short script for me the analyze.  This will
also clarify your bug a little bit.



[2001-01-23 22:23:49] [EMAIL PROTECTED]

The ftp_nlist and ftp_rawlist functions failed to work for me.  I am using PHP.EXE 
v4.0.4 from a Windows 2000 machine connecting to a Free BSD box running the following 
FTP server:

Our.ftp.server FTP server (Version wu-2.6.1(1) Mon Jul 3 03:07:01 EDT 2000)

Both ftp_nlist and ftp_rawlist return a single blank string ("") into the result 
array.






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


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

Re: [PHP-DEV] Setting up RFC

[Zak Greant]

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

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

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

We perform additional work due to the above problem.

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

The system would work something like this:

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

i.e.

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

Abstract

The foo feature would do bar and baz.

Details
---
...

Other developers would respond to the proposal.

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

i.e.

Zak Greant

Proposal Foo

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

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


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


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

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

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

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

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

 -: Have not commented


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

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

--zak





-- 
PHP Development Mailing List 
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 or Intended Behaviour?

[Markus Fischer]

Quoting Andrei:
Static variables are references, so you should not use &new 
when assigning to them, same as with global variables.

sorry for the fuzz :)

- Markus

On Wed, Aug 15, 2001 at 02:09:26AM +0200, Sebastian Bergmann wrote : 
>   Consider the following code
> 
>class foo {
> function foo() {}
>   }
> 
>   function contains_static() {
> static $bar;
> echo '1'.$bar.'';
> 
> $bar =& new foo();
> echo '2'.$bar.'';
>   }
> 
>   contains_static();
>   contains_static();
> ?>
> 
>   When $bar is assigned as above (with a &), this outputs
> 
> 1
> 2Object
> 1
> 2Object
> 
>   Clearly, the static variable loses its contend between the two
>   calls.
> 
>   After removing the & the output looks as follows
> 
> 1
> 2Object
> 1Object
> 2Object
> 
>   Now the question: Is this a bug and assignment to a static
>   variable by reference should work, or is this intended
>   behaviour since after the scope of contains_static() the
>   reference count is decreased, and bla bla ?
> 
>   You can easily find argument for both variants, hence the
>   question.
> 
> -- 
>   Sebastian Bergmann Measure Traffic & Usability
>   http://sebastian-bergmann.de/http://phpOpenTracker.de/
> 
> -- 
> 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]

-- 
Markus Fischer,  http://guru.josefine.at/~mfischer/
EMail: [EMAIL PROTECTED]
PGP Public  Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
PGP Fingerprint: D3B0 DD4F E12B F911 3CE1  C2B5 D674 B445 C227 2BD0
  -All your scripts are belong to Zend-

-- 
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 #12748: changing allow_url_fopen from "off" to "on" crashes fopen()

[phpman]

From: [EMAIL PROTECTED]
Operating system: redhat-7.1b
PHP version:  4.0.6
PHP Bug Type: Reproducible crash
Bug description:  changing allow_url_fopen from "off" to "on" crashes fopen()

Using 
Apache-1.3.20
PHP-4.0.6
glibc-2.2.3

PHP compiled as DSO, no other options
./configure  --with-apxs=/usr/local/apache/bin/apxs

Note, this is not the same as bug #9672
Updating glibc does solve that problem see
http://bugs.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=2181

/usr/local/lib/php.ini
[PHP]
engine = On
allow_url_fopen = Off

My httpd.conf contains (in a VirtualHost),
  php_admin_flag allow_url_fopen On

A test script
http://www.php.net";, "r" );
if( $fp )
{
fclose($fp);
print "fopen() success\n";
}
?>

Backtrace:
#0  __strtol_internal (nptr=0x403adba0 "", endptr=0x81128bc,
base=4,
group=-1073748792) at eval.c:36
#1  0x402bee14 in zend_hash_find (ht=0x403adba0,
arKey=0x81128bc "http://www.php.net";, nKeyLength=4,
pData=0xbfffe4c8)
at zend_hash.c:850
#2  0x402cd259 in php_fopen_url_wrapper (path=0x81128bc
"http://www.php.net";,
mode=0x810d5c4 "r", options=4, issock=0xbfffe508,
socketd=0xbfffe50c,
opened_path=0x0) at fopen_wrappers.c:445
#3  0x4031f2fb in php_if_fopen (ht=2,
return_value=0x810d5a4, this_ptr=0x0,
return_value_used=1) at file.c:639
#4  0x402acd5c in execute (op_array=0x8109efc) at
./zend_execute.c:1504
#5  0x402bae95 in zend_execute_scripts (type=8,
file_count=3) at zend.c:752
#6  0x402cc30b in php_execute_script
(primary_file=0xb890) at main.c:1206
#7  0x402c8bae in apache_php_module_main (r=0x8107644,
display_source_mode=0)
at sapi_apache.c:89
#8  0x402c9541 in send_php (r=0x8107644,
display_source_mode=0, filename=0x0)
at mod_php4.c:536
#9  0x402c956a in send_parsed_php (r=0x8107644) at
mod_php4.c:547
#10 0x080558d3 in ap_invoke_handler () at eval.c:41
#11 0x08069667 in process_request_internal () at eval.c:41
#12 0x080696c8 in ap_process_request () at eval.c:41
#13 0x08060b69 in child_main () at eval.c:41
#14 0x08060d14 in make_child () at eval.c:41
#15 0x08060e88 in startup_children () at eval.c:41
#16 0x080614d7 in standalone_main () at eval.c:41
#17 0x08061cf3 in main () at eval.c:41
#18 0x400ca6b7 in __libc_start_main (main=0x806195c ,
argc=2,
ubp_av=0xbb64, init=0x804ead0 <_init>,
fini=0x80969bc <_fini>,
rtld_fini=0x4000db64 <_dl_fini>, stack_end=0xbb5c)
at ../sysdeps/generic/libc-start.c:129


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


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

Re: [PHP-DEV] Setting up RFC

[Joey Smith]

On Tue, 14 Aug 2001, John Donagher wrote the following to [EMAIL PROTECTED]:
> With what end in mind is an RFC to be created for? In the IETF, RFC's are
> typically long, complex, and authoritative. They are often referenced for years
> after their inception. Do you honestly think we could (or want to) achieve this
> with PHP feature RFC's? Or will they be used only before initial feature
> implementation, then quickly outdated and discarded? That is my biggest problem
> with documents: they take a lot of effort to create, are often difficult to
> grok, and _almost always_ have a very short lifecycle.

PHP feature RFC != IETF RFC's.

Go back and read my original proposal on the issue. What I had in mind
was something more like what Perl has done with the Perl 6 RFC's, or
(perhaps) the PEP's of Python...

The point being that there is a LOT of discussion on certain topics, and
people often change sides on an issue over the life of the discussion. I
was simply trying to say "Let's make this a *bit* more orderly.", mainly
becuase I had already lost track of several of the then-current threads
on the zend-engine list.


-- 
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: RE Email address in user notes - SPAM (fwd)

[Sascha Schumann]

> Me too, I'm getting a lot of spam on my @php.net adress :(...

Btw, your @php.net address is bouncing..  did you receive soo
much spam lately? :)

So, hopefully you are reading this mailing list using
nntp..

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg



-- 
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 #8999 Updated: difference ftp_fget() cgi and module

[jmoore]

ID: 8999
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: FTP related
Operating System: Windows
PHP Version: 4.0.4pl1
New Comment:

can you provide some indepth information about your setup please and a script less 
than ten lines that also produces the bug.

- James

Previous Comments:


[2001-07-21 21:29:38] [EMAIL PROTECTED]

If it works as a CGI, I say just go back to the CGI version.

But, if you don't then answer these questions.

-Does it still happen in the latest version of PHP?
-Are there any error messages (either on the page or logs)



[2001-01-30 07:16:07] [EMAIL PROTECTED]

Until now I was using PHP4 in CGI-Mode. Now I want to change to Apache Module. So I 
made the nessecary changes in httpd.conf and rebotted the Windows 2000 server.

Since PHP is running as an Apache Module, the function ftp_fget() doesn't work 
correctly anymore.

I read a jpg from a FTP Server and display it with the  tag. In Module Mode the 
file is transferred and the width and height is correct, but the content is wrong 
(wrong colors in the completely wrong places). When PHP is running in cgi mode, 
everything is correct.

Thanks for any help, Rolf.

Code Sample:

class Foto_class
{

  var $fotoname;

  function Foto_class( $verwender )
  {
global $const_ftp_host, $const_ftp_user, $const_ftp_passwd, $const_ftp_dir;
$select_file = "foto.jpg";
$ftp = ftp_connect( $const_ftp_host );
if ( $ftp )
{
  ftp_login( $ftp, $const_ftp_user, urldecode( $const_ftp_passwd ) );
}
if ( $const_ftp_dir == "" )
{
  $const_ftp_dir = FTP_DIRROOT;
}
$const_ftp_dir = $const_ftp_dir . FTP_DIRROOT . $verwender;
if ( ( ! $ftp ) || ( ! @ftp_chdir( $ftp, $const_ftp_dir ) ) )
{
  @ftp_quit( $ftp );
}
else
{
  srand( ( double ) microtime() * 100 );
  $randval = rand();
  $tmpfile = $select_file . "." . $randval;
  $showfile = $this->filename( $tmpfile );
  $fp = fopen( $showfile, "w" );
  if ( ! @ftp_fget( $ftp, $fp, $select_file, FTP_BINARY ) )
  {
ftp_quit( $ftp );
  }
  else
  {
ftp_quit( $ftp );
$this->fotoname = $showfile;
  }
  @fclose( $fp );
}
  }

  function filename($f_name)
  {
$dir = "./temp/sess_".session_id();
if (!file_exists($dir)) mkdir($dir,0700);
return $dir."/".$f_name;
  }

  function out()
  {
return $this->fotoname;
  }

}






Edit this bug report at http://bugs.php.net/?id=8999&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 #8874 Updated: ftp_nlist and rawlist not working

[jmoore]

ID: 8874
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: FTP related
Operating System: Windows 2000 Advanced Server
PHP Version: 4.0.4
New Comment:

can you provide a smaller script that produces the bug please. preferably less than 
ten lines of code which requires nothing other than the bare min.. IE no extenal files 
etc.

Previous Comments:


[2001-07-22 00:23:57] [EMAIL PROTECTED]

Thanks for responding.  I no longer have access to the FreeBSD FTP server that I was 
connecting to, so it is no longer an issue (for me).  My script is attached below.   
If you do see an issue with the code, I am still interested in your response.

";

for ( $i=0; $i < count ($aDomain) ; )
  {
  
  if ( $bDebug )
echo "Openning \"" . $aDomain[$i] . "\"...";

  $nFTP = ftp_connect ( $aDomain[$i] );

  if ( $nFTP == 0 )
{
echo "Failed to open $aDomain[$i]. Aborting...";
exit();
}

  $nResult = ftp_login ( $nFTP, $aDomain[$i+1], "password" );
  if ( $nResult == 0 )
{
echo "Failed to login to $aDomain[$i]. Aborting...";
exit();
}
  else
echo "Login to $aDomain[$i] succeeded.";

  if ( $bDebug)
echo "ftp_pwd=" . ftp_pwd ( $nFTP ) . "".

  $nResult = ftp_chdir ( $nFTP, "logs");
  if ( $nResult == 0)
{
echo "ftp_chdir failed.  Aborting...";
exit();
}

  if ( $bDebug)
echo "ftp_pwd=" . ftp_pwd ( $nFTP ) . "".

  $aFiles = Array( "Oct100.log.gz",
   "Nov100.log.gz",
   "Dec100.log.gz",
   "mtd.log");

  // $aFiles = ftp_rawlist ( $nFTP, "/mnt/web/guide/accumeddata/logs/*.gz");
  // echo "rawlist = " . count ( $aFileList ) . "";
  // $aFiles = ftp_nlist ( $nFTP, "*.gz");

  if ( $bDebug )
{
echo "count(aFiles)=" . count ($aFiles ) . "";
for ( $j=0; $j <= count($aFiles); $j++ )
  echo "$j=\"$aFiles[$j]\""; 
}

  // Get all the Monthly archives (*.GZ)
  for ( $j=0; $j < count($aFiles); $j++ )
{

$sLocalFile = $aDomain[$i] . "-" . $aFiles[$j];
$sLocalFile = str_replace ( "/", "-", $sLocalFile );
$sRemoteFile = $aFiles[$j];

if ( $bDebug)
  {
  echo "sLocalFile=\"$sLocalFile\"";
  echo "sRemoteFile=\"$sRemoteFile\"";
  }

$nResult = ftp_get ( $nFTP, $sLocalFile, $sRemoteFile, FTP_BINARY );

if ( $nResult == 0)   
  {
  echo "ftp_get failed.  Aborting...";
  exit();
  }
}

  // Get the current month also.
  $nResult = ftp_get ( $nFTP, $sLocalFile, "mtd.log", FTP_BINARY );

  if ( $nResult == 0)   
{
echo "ftp_get of mtd.log failed.  Aborting...";
exit();
}

  $nResult = ftp_quit ( $nFTP );
  if ( $nResult == 0 )   
{
echo "ftp_quit failed.  Aborting...";
exit();
}

  $i = $i + 2;
  }


?>



[2001-07-21 21:27:45] [EMAIL PROTECTED]

Please submit a short script for me the analyze.  This will
also clarify your bug a little bit.



[2001-01-23 22:23:49] [EMAIL PROTECTED]

The ftp_nlist and ftp_rawlist functions failed to work for me.  I am using PHP.EXE 
v4.0.4 from a Windows 2000 machine connecting to a Free BSD box running the following 
FTP server:

Our.ftp.server FTP server (Version wu-2.6.1(1) Mon Jul 3 03:07:01 EDT 2000)

Both ftp_nlist and ftp_rawlist return a single blank string ("") into the result 
array.






Edit this bug report at http://bugs.php.net/?id=8874&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 #5653 Updated: PIKE specific: with setcookie(), only the last cookie is written

[jmoore]

ID: 5653
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: Other web server
Operating System: Linux
PHP Version: 4.0.5
New Comment:

feedback -> open

Previous Comments:


[2001-07-24 12:23:37] [EMAIL PROTECTED]

OK here is the result...

Variable Value 
PHP_SELF  =  /test.php 
HTTP_COOKIE_VARS["cookie3"] = phprocks  

if you don't believe you can try at www.delta7.de/test.php.
The real problem is in source-file src/sapi/roxen/roxen.c about line 298 (in ver 4.0.6 
of PHP)...
this function (pike):
mapping_string_insert(REQUEST_DATA, ind, &mappie);
does not append headers of the same type (here cookies).
this means: old cookies are deleted and replaced with the last one you set.

The Problen is _not_ on the side of the webserver. I found out (and may proove) that 
the roxen-php-module will recieve more than only one cookie if you like, i would 
make some php-scripts that will show you...


 




[2001-07-24 09:02:41] [EMAIL PROTECTED]

this could be because your server is only sending one cookie to 
browser

Try creating a script like the one below...


go down to the section about the "HTTP Headers Information"
then go to the "HTTP Response Headers."  Either post this
information here, or give us the address to that page.



[2001-07-24 02:01:28] [EMAIL PROTECTED]

This is not a browser-specific bug. It's only pike-specifc (roxen) .

I spent some time to undaerstand the roxen-sapi-code, but at last I'm not able to fix 
it.
This 'bug' is already mentioned in the README
..sorry. 

So this 'bug' should be listed in 'missing features' or 'todo's' but not maybe not in 
'bugs'





[2001-07-23 19:26:00] [EMAIL PROTECTED]

i meant to say "only lets you set ONE"



[2001-07-23 19:25:30] [EMAIL PROTECTED]

this is probably a browser related problem (the browser only
lets you set noe cookie per site.)  Does anyone else agree
or has somebody actually reproduced this one?



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/?id=5653


Edit this bug report at http://bugs.php.net/?id=5653&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 #7663 Updated: Initialization problem at fontFetch()

[jmoore]

ID: 7663
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: GD related
Operating System: Red Hat Linux 6.2J
PHP Version: 4.0.3pl1


Previous Comments:


[2001-07-22 19:30:34] [EMAIL PROTECTED]

is this a GD problem or a PHP problem.



[2000-11-06 09:46:44] [EMAIL PROTECTED]

Some initialization codes are not worked at fontFetch() in gdttf.c.

if (TT_Set_Instance_Resolutions(a->instance, RESOLUTION, RESOLUTION)) {
*error = "Could not set device resolutions";
return NULL;
map_found = 0;// <--
a->have_char_map_Unicode = 0; // <--
a->have_char_map_Big5 = 0;// <--
a->have_char_map_Roman = 0;   // <--
}






Edit this bug report at http://bugs.php.net/?id=7663&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 #7663 Updated: Initialization problem at fontFetch()

[jmoore]

ID: 7663
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: GD related
Operating System: Red Hat Linux 6.2J
PHP Version: 4.0.3pl1
New Comment:

no feedback

Previous Comments:


[2001-07-22 19:30:34] [EMAIL PROTECTED]

is this a GD problem or a PHP problem.



[2000-11-06 09:46:44] [EMAIL PROTECTED]

Some initialization codes are not worked at fontFetch() in gdttf.c.

if (TT_Set_Instance_Resolutions(a->instance, RESOLUTION, RESOLUTION)) {
*error = "Could not set device resolutions";
return NULL;
map_found = 0;// <--
a->have_char_map_Unicode = 0; // <--
a->have_char_map_Big5 = 0;// <--
a->have_char_map_Roman = 0;   // <--
}






Edit this bug report at http://bugs.php.net/?id=7663&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 #12747: ***BUG in Autoconf--please report***

[onaias]

From: [EMAIL PROTECTED]
Operating system: Mandrake Linux 8.0
PHP version:  4.0CVS-2001-08-14
PHP Bug Type: *Compile Issues
Bug description:  ***BUG in Autoconf--please report***

autoconf-2.13-7.mdk
automake-1.4-15mdk
libtool-1.4

Trying to compile the cvs version of PHP. After updating from the CVS
server and running ./buildconf.

[onaias@frodo php4]$ ./buildconf
aclocal: configure.in: 895: macro `AM_PROG_LIBTOOL' not found in library
rebuilding Makefile templates
rebuilding Makefile templates
rebuilding configure
autoconf: Undefined macros:
***BUG in Autoconf--please report*** AC_ADD_INCLUDE
configure.in:442:PHP_AC_BROKEN_SPRINTF
rebuilding main/php_config.h.in
[onaias@frodo php4]$

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


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

Re: [PHP-DEV] Setting up RFC

[Jeroen van Wolffelaar]

> With what end in mind is an RFC to be created for? In the IETF, RFC's are
> typically long, complex, and authoritative. They are often referenced for
years
> after their inception.
> Do you honestly think we could (or want to) achieve this
> with PHP feature RFC's? Or will they be used only before initial feature
> implementation, then quickly outdated and discarded? That is my biggest
problem
> with documents: they take a lot of effort to create, are often difficult
to
> grok, and _almost always_ have a very short lifecycle.

They should _not_ be too technical, _not_ too long, but yet as simple as
possible, but exactly as precise enough to be relatively unambigious if you
know about the PHP conventions. For example like that zend engine 2 white
paper.

But they need to be updated, and not discarded.

They shouldn't be too hard to create, and definitely not too hard to grok. A
simple template could help achieving this.

All of the above IMHO,

Jeroen



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

[PHP-DEV] Bug or Intended Behaviour?

[Sebastian Bergmann]

  Consider the following code

';

$bar =& new foo();
echo '2'.$bar.'';
  }

  contains_static();
  contains_static();
?>

  When $bar is assigned as above (with a &), this outputs

1
2Object
1
2Object

  Clearly, the static variable loses its contend between the two
  calls.

  After removing the & the output looks as follows

1
2Object
1Object
2Object

  Now the question: Is this a bug and assignment to a static
  variable by reference should work, or is this intended
  behaviour since after the scope of contains_static() the
  reference count is decreased, and bla bla ?

  You can easily find argument for both variants, hence the
  question.

-- 
  Sebastian Bergmann Measure Traffic & Usability
  http://sebastian-bergmann.de/http://phpOpenTracker.de/

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

Re: [PHP-DEV] Setting up RFC

[John Donagher]

On Wed, 15 Aug 2001, James Moore wrote:

> 
> RFC.. Request For Comments, its as simple as that someone posts a document
> outlining what they want changed/want to do, calls it an RFC and is
> litterally making a request for comments on their idea. I think this is a
> good idea for large things but if we encourage too much we will suddenly be
> flooded with RFC's all over the place then they begin to conflict.. I think
> that if someone feels somthing is really important then an RFC is a good
> idea but I certainly dont want a couple a week to plough through.
> 

With what end in mind is an RFC to be created for? In the IETF, RFC's are
typically long, complex, and authoritative. They are often referenced for years
after their inception. Do you honestly think we could (or want to) achieve this
with PHP feature RFC's? Or will they be used only before initial feature
implementation, then quickly outdated and discarded? That is my biggest problem
with documents: they take a lot of effort to create, are often difficult to
grok, and _almost always_ have a very short lifecycle.

-- 

John Donagher
Application Engineer, Intacct Corp.

Public key available off http://www.keyserver.net
Key fingerprint = 4024 DF50 56EE 19A3 258A  D628 22DE AD56 EEBE 8DDD


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

Re: [PHP-DEV] Setting up RFC

[Jeroen van Wolffelaar]

> > The work on Zend Engine 2 has now started, _without_ a proper definition
> of
> > it. IMHO, that's not the ideal situation, since this could lead to
strange
> > inconsequences, because the precise behaviour is decided during
> > implementation.
>
> Umm what about the white paper that was prepaired before work on Zend
Engine
> 2 started?? http://www.zend.com/engine2/ZendEngine-2.0.pdf

It was some kind of RFC indeed, but not updated as discussion progressed. A
lot of other issues were discussed, but without RFC 'backbone'. There was
also no good infrastructure to have a constructive discussion, a lot of
issues have been discussed quite reasonably, but with quite some open ends.

> > For example bug 10437, which wouldn't have existed if the
> > zend engine was properly defined _before_ it was implemented. But it
> simply
> > was the easiest way to implement it...
>
> Probably the the best way too.. not that Ive read 10437 cause Im currently
> working..

Useless to comment on this if you haven't read the report...

> > As you say, for 'light' changes, no official RFC should be created, it
> isn't
> > necessary, mainly because:
> > > at the moment there is no democratic process in PHP, people
> > > just do what they want
>
> Yes this is part of opensource, people will do what they want to do, If I
> want some feature in PHP Ill program it, the general direction of PHP
should
> be decided by a group of people yes but it gets to a point where everyone
is
> saying we should do it this way, that way or another way and in the end
> nothing gets done, at the moment people see what others are doing and
> question it if necessary, if its their extension then they are free to do
> what they want with it.

I am obviously not used enough to open-source, to feel that... I have some
some resistance to myself to change/add something if it isn't agreed... You
shouldn't try that on a paid closed-source project ;-)...

I think you're definitely right on the 'nothing gets done' part.

> - James



-- 
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] libmysql and MS Visual Studio .NET

[Sebastian Bergmann]

  Hi,

  while cleaning up my room today I found my copy of the MS Visual
  Studio .NET Beta 1 again. Since I was a little bored I installed
  it and tried again to build PHP 4 with it.

  It still chokes on the strtoll.c file. I wonder if someone else
  has tried to build PHP (or MySQL) with this next version of the
  standard Win32 compiler.

  Have a look at 

http://www.sebastian-bergmann.de/libmysql.htm

  for the exact error messages. Sorry, I only own the german 
  version of Visual Studio.

  Note: This is currently not important, but better support it
  sooner than later, I think.

-- 
  Sebastian Bergmann Measure Traffic & Usability
  http://sebastian-bergmann.de/http://phpOpenTracker.de/

-- 
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 #12746 Updated: CGI Bad Header Error - Random

[David . Carter]

ID: 12746
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: IIS related
Operating System: Win2000
PHP Version: 4.0.6
New Comment:

Sorry, the message looks like the "bad header" returns the "system: " line ... there 
is nothing after the bad header ... zilch ... I was just reporting what my system was 
and that has nothting to do with the header ... sorry that was unclear.

Previous Comments:


[2001-08-14 19:43:28] [EMAIL PROTECTED]

Random Error:

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

System: Dell Poweredge 350 w/1GB Ram, Win2K, MS SQL 2000

Basically the page is blank, like there was some error that is not being reported 
properly.  There is no output from the page at all, just that error message.  When the 
page is refreshed, page is fine, but sooner or later the error comes back requiring a 
refresh.

Our pages are pretty complex, so a snippet is not going to be feasible.  We run a page 
with 9 frames on it for our intranet. Sometimes all 9 frames will be displayed 
correctly, sometime as many as 3 frames with get that error.

Frames are thing like Customer Info, Customer Order, Customer Aging, Inventory levels, 
Item Sold History, etc, etc, etc.

I have seen this reported numerous times on this system, but the last one is 4.0.3p11 
or something like that ... this is 4.0.6 ... if there is anything you wish me to test 
or to look at, let me know.

I have looked at the IIS logs and nothing seems to stand out persay. I have been 
counting on using PHP on NT and never dreamed this sort of thing would happen.  Been 
using PHP since it was PHP/FI :-)





Edit this bug report at http://bugs.php.net/?id=12746&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 #12746: CGI Bad Header Error - Random

[David . Carter]

From: [EMAIL PROTECTED]
Operating system: Win2000
PHP version:  4.0.6
PHP Bug Type: IIS related
Bug description:  CGI Bad Header Error - Random

Random Error:

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

System: Dell Poweredge 350 w/1GB Ram, Win2K, MS SQL 2000

Basically the page is blank, like there was some error that is not being
reported properly.  There is no output from the page at all, just that
error message.  When the page is refreshed, page is fine, but sooner or
later the error comes back requiring a refresh.

Our pages are pretty complex, so a snippet is not going to be feasible.  We
run a page with 9 frames on it for our intranet. Sometimes all 9 frames
will be displayed correctly, sometime as many as 3 frames with get that
error.

Frames are thing like Customer Info, Customer Order, Customer Aging,
Inventory levels, Item Sold History, etc, etc, etc.

I have seen this reported numerous times on this system, but the last one
is 4.0.3p11 or something like that ... this is 4.0.6 ... if there is
anything you wish me to test or to look at, let me know.

I have looked at the IIS logs and nothing seems to stand out persay. I have
been counting on using PHP on NT and never dreamed this sort of thing would
happen.  Been using PHP since it was PHP/FI :-)
-- 
Edit bug report at: http://bugs.php.net/?id=12746&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 #12745: problem with the randomic generation of salt when a use crypt("pass")

[marcus]

From: [EMAIL PROTECTED]
Operating system: Linux Slackware 7.1
PHP version:  4.0.6
PHP Bug Type: *Encryption and hash functions
Bug description:  problem with the randomic generation of salt when a use crypt("pass")

problem with the randomic generation of salt when a use $string =
crypt("11lei11lao11") it allways generates a salt ( the first 2 chars from
encrypted string ) that if use crypt("11lei11lao11blablabla") would work,
and also crypt("11lei11lao11anythingwouldworkhere").

the code is

$cryptedpass = crypt("11lei11lao11");
if (crypt ( "11lei11lao11anythingwouldworkhere", substr ( $cryptedpass, 0,
2)) == $cryptedpass) {
  echo "this is extremely strange for me";
}

and this works with this pass but not whit others!
-- 
Edit bug report at: http://bugs.php.net/?id=12745&edit=1


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

Re: [PHP-DEV] Setting up RFC

[James Moore]

> The work on Zend Engine 2 has now started, _without_ a proper definition
of
> it. IMHO, that's not the ideal situation, since this could lead to strange
> inconsequences, because the precise behaviour is decided during
> implementation.

Umm what about the white paper that was prepaired before work on Zend Engine
2 started?? http://www.zend.com/engine2/ZendEngine-2.0.pdf

> For example bug 10437, which wouldn't have existed if the
> zend engine was properly defined _before_ it was implemented. But it
simply
> was the easiest way to implement it...

Probably the the best way too.. not that Ive read 10437 cause Im currently
working..

> As you say, for 'light' changes, no official RFC should be created, it
isn't
> necessary, mainly because:
> > at the moment there is no democratic process in PHP, people
> > just do what they want

Yes this is part of opensource, people will do what they want to do, If I
want some feature in PHP Ill program it, the general direction of PHP should
be decided by a group of people yes but it gets to a point where everyone is
saying we should do it this way, that way or another way and in the end
nothing gets done, at the moment people see what others are doing and
question it if necessary, if its their extension then they are free to do
what they want with it.

- James


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

Re: [PHP-DEV] Setting up RFC

[Joey Smith]

This is why I sort of dropped the subject. I've been waiting until I have
time to look
into Python's PEP system in depth, and see what it requires. Thanks to Jon
for pointing
it out. :)
- Original Message -
From: "Jon Parise" <[EMAIL PROTECTED]>
To: "Jeroen van Wolffelaar" <[EMAIL PROTECTED]>
Cc: "PHP Developers Mailing List" <[EMAIL PROTECTED]>; "Joey Smith"
<[EMAIL PROTECTED]>; "Zak Greant" <[EMAIL PROTECTED]>
Sent: Tuesday, August 14, 2001 4:58 PM
Subject: Re: [PHP-DEV] Setting up RFC


> On Wed, Aug 15, 2001 at 12:18:06AM +0200, Jeroen van Wolffelaar wrote:
>
> > About a month ago there was a discussion on the Engine 2 mailing list,
about
> > a possible RFC-proces for the more imporant PHP-issues. In the end,
there
> > was some consensus that it would be good if such a system exists.
>
> I thought the idea was sound, too, and suggested we mimic
> Python's PEP (Python Enhancement Proposal) system:
>
> http://python.sourceforge.net/peps/
>
> --
> Jon Parise ([EMAIL PROTECTED])  .  Rochester Inst. of Technology
> http://www.csh.rit.edu/~jon/  :  Computer Science House Member
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>


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

Re: [PHP-DEV] Setting up RFC

[Jeroen van Wolffelaar]

> > On the other hand, the latter one could be named 'RFC process', since it
> > hasn't yet been defined what the heck it is precisely...
>
> RFC.. Request For Comments, its as simple as that someone posts a document
> outlining what they want changed/want to do, calls it an RFC and is
> litterally making a request for comments on their idea. I think this is a
> good idea for large things but if we encourage too much we will suddenly
be
> flooded with RFC's all over the place then they begin to conflict.. I
think
> that if someone feels somthing is really important then an RFC is a good
> idea but I certainly dont want a couple a week to plough through.

That PEP's seem to work quite well, there needs to be some selection on
it... For example: several supporters before you may even start an
(official) RFC for example.

The work on Zend Engine 2 has now started, _without_ a proper definition of
it. IMHO, that's not the ideal situation, since this could lead to strange
inconsequences, because the precise behaviour is decided during
implementation. For example bug 10437, which wouldn't have existed if the
zend engine was properly defined _before_ it was implemented. But it simply
was the easiest way to implement it...

As you say, for 'light' changes, no official RFC should be created, it isn't
necessary, mainly because:
> at the moment there is no democratic process in PHP, people
> just do what they want


Jeroen



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

Re: [PHP-DEV] Setting up RFC

[James Moore]

> On the other hand, the latter one could be named 'RFC process', since it
> hasn't yet been defined what the heck it is precisely...

RFC.. Request For Comments, its as simple as that someone posts a document
outlining what they want changed/want to do, calls it an RFC and is
litterally making a request for comments on their idea. I think this is a
good idea for large things but if we encourage too much we will suddenly be
flooded with RFC's all over the place then they begin to conflict.. I think
that if someone feels somthing is really important then an RFC is a good
idea but I certainly dont want a couple a week to plough through.

- James


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

Re: [PHP-DEV] Setting up RFC

[Jeroen van Wolffelaar]

> Just poit them to php-dev and keep bringing it up until there is some
decent
> comment on it, at the moment there is no democratic process in PHP, people
> just do what they want and someone normally knows some part of PHP better
> than anyother, IE if you have a sessions thing speak to sascha (via
> PHP-DEV), a COM thing speak to Frank, Daniel and Zeev via PHP-DEV, an
object
> thing speak to Andrei, Zeev and Andi etc... RFC's are a good idea but as
> soon as they are posted to php-dev they are in the archives and it will be
a
> big pain in the arse putting them in CVS due to the karma thing and people
> who dont have cvs access. php-dev is there so use it, yes we should
> formalise some of the more important discussions but it should all take
> place on php-dev.

Discussion about RFC's would have taken place at php-dev, of course.

For the rest of your arguments, you're right, as long as it goes about minor
issues. But I believe it is not true when it comes to really heavy issues,
such as syntax of private object-vars (just an example).

The question is now, is it worth the effort of a complete RFC process for
that, or would a mere formalization of the important discussions, as you
suggest, do?
On the other hand, the latter one could be named 'RFC process', since it
hasn't yet been defined what the heck it is precisely...

> - James

Jeroen


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

Re: [PHP-DEV] Setting up RFC

[Jon Parise]

On Wed, Aug 15, 2001 at 12:18:06AM +0200, Jeroen van Wolffelaar wrote:

> About a month ago there was a discussion on the Engine 2 mailing list, about
> a possible RFC-proces for the more imporant PHP-issues. In the end, there
> was some consensus that it would be good if such a system exists.
 
I thought the idea was sound, too, and suggested we mimic
Python's PEP (Python Enhancement Proposal) system:

http://python.sourceforge.net/peps/

-- 
Jon Parise ([EMAIL PROTECTED])  .  Rochester Inst. of Technology
http://www.csh.rit.edu/~jon/  :  Computer Science House Member

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

Re: [PHP-DEV] Setting up RFC

[James Moore]

> > Ive written one or two before, mainly for the release process (I think
its
> > in CVS under README.realease_process or somthing like that). Id suggest
> > people just get on and write them and post them to php-dev where people
> > generally read them and make comments. I dont see what there is to
discuss
> > Jeroen.
>
> There should IMO be a more generalized way for this, indeed, it was my
idea
> to put RFC's in cvs. But no in the php4 module, but in a separate.
>
> Main point is that discussions on phpdev die out quite quickly, and you
> can't say then it's decided. And you can't put each proposal in php4 cvs
> either, release proces is not about PHP itself, but about the proces
around
> it, and it is always 'current', since realeases keep coming out...
>
> Anyway, Zak wrote that, not me. So CC'ing to him.

Just poit them to php-dev and keep bringing it up until there is some decent
comment on it, at the moment there is no democratic process in PHP, people
just do what they want and someone normally knows some part of PHP better
than anyother, IE if you have a sessions thing speak to sascha (via
PHP-DEV), a COM thing speak to Frank, Daniel and Zeev via PHP-DEV, an object
thing speak to Andrei, Zeev and Andi etc... RFC's are a good idea but as
soon as they are posted to php-dev they are in the archives and it will be a
big pain in the arse putting them in CVS due to the karma thing and people
who dont have cvs access. php-dev is there so use it, yes we should
formalise some of the more important discussions but it should all take
place on php-dev.

- James


-- 
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] Setting up RFC

[Jeroen van Wolffelaar]

Hi,

About a month ago there was a discussion on the Engine 2 mailing list, about
a possible RFC-proces for the more imporant PHP-issues. In the end, there
was some consensus that it would be good if such a system exists.

I'm simply writing to get some comments, to hear what the general opinion
is. If that is not negative, I think it should be tried to set it up.


About the details, there needs to be discussion of course, but it would be
more efficient to discuss those things after a proposal has been made, in
stead of construct such a proposal by discussion.

Joey Smith and Zak Great supported the idea on the list, but the discussion
went dead. Below I quote some of their mails.


Regards,
Jeroen



Joey Smith wrote:
> Actually, I felt that the Perl 6 design process had a fairly good idea
> that was poorly implemented...that of RFC's. Anyone who wants to sponsor
> a feature compiles an RFC on it, and is resposible for keeping track of
> the discussion on it, and occasionally rolling the comments back into a
> new revision of the RFC.
>
> What do you guys think of something like this? We could even mark
> certain RFC's as "Dead for now", or something like, so that we can kill
> threads such as {}, and anyone who doubts the "deadness" of the thread
> can check the status of the RFC before commenting.
>
> One potential risk I see with this approach: Someone sponsors a certain
> RFC, goes through much time and trouble to track and merge discussion,
> only to have it "killed" somewhere down the road by the others. This
> could possibly lead to the kinds of flare-ups that occur from
> time-to-time on php-dev...

Zak wrote:
> That sounds like a very good idea. We spend a good deal of time going
> around.
> The RFC process should have a series of significant benefits:
>
> a.) Less digging through old mail to figure out what was said
>
> b.) The sponsor must be serious
>
> c.) The process of writing an RFC will encourage the sponsor to consider
the
> feature more carefully
>
> d.) The RFCs will provide a form that can easily be archived.
>
> --zak

Zak wrote again:
> Has anyone else had a chance to think about this proposal?
>
> I think that it is a solid idea.
>
> As Joey points out, it might help prevent the pointless go-rounds
> that have been occurring with this discussion *and* would give us a
> clear set of documents to refer to in the future.
>
> --zak






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

[PHP-DEV] transparent output compression

[John Donagher]

Hi all-

Is there really a difference between ob_gzhandler and zlib.output_compression,
now that ob_gzhandler supports chunks?

Since, in zlib.c, zlib.output_compression still causes output buffering to be
turned on, I can't see that there's a convincing reason to use one over the
other, unless you need fine control over the flush/clean functions. Can anyone
shed some light on this?

Slightly OT: with such an amazing option so easy to implement on top of an
existing application (via either PHP or mod_gzip), and widespread browser
support, why don't more sites use this? Bandwidth is expensive. CPU cycles are
not. We've seen 900K HTML reports compressed to 40K. Truly awesome.

Thanks
John

-- 

John Donagher
Application Engineer, Intacct Corp.

Public key available off http://www.keyserver.net
Key fingerprint = 4024 DF50 56EE 19A3 258A  D628 22DE AD56 EEBE 8DDD


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

[Jon Parise]

PHP (or, rather, the Zend scanner) currently recognizes the
following tags as enclosing PHP code:



<% %>


The attached patch extends the