#20825 [Fbk->NoF]: browser's get confused with session's id

[php-bugs]

 ID:   20825
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: Session related
 Operating System: win2000
 PHP Version:  4.2.3
 New Comment:

No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".


Previous Comments:


[2002-12-05 09:34:25] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip





[2002-12-05 09:33:30] [EMAIL PROTECTED]

I'm using cookies, yes.



[2002-12-05 09:31:21] [EMAIL PROTECTED]

I go to re-explain the problem, because i didn't this the last time
(sorrie).

Sometimes (i don't know when this occurs, it seems randomly) when there
are somebody in my page, and other try to login, then the last one get
the current value that have the session of other user. I only see the
possible bug, usign IE.

Thx (and sorrie if i'm get confused too and this isn't a bug)



[2002-12-05 08:43:25] [EMAIL PROTECTED]

Do you by any chance mean that you're opening several IE windows? And
you're using cookies?




[2002-12-05 08:19:49] [EMAIL PROTECTED]

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.


Please provide a __short__ and __self-contained__ example script, that
will reproduce the bug.
Additionally, try the latest snapshot:
  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip


There are quite a few session related fixes in those snapshots, so it
may be already fixed.



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/20825

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

#20604 [Fbk->NoF]: PHP CLI exists always with Segmantation Fault

[php-bugs]

 ID:   20604
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: *General Issues
 Operating System: Linux Debian Sarge
 PHP Version:  4CVS-2002-11-24 (dev)
 New Comment:

No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".


Previous Comments:


[2002-12-06 00:44:33] [EMAIL PROTECTED]

argh the error is on php 4.2.3 too but i don't have
session.auto_start=1 =(



[2002-12-05 09:58:19] [EMAIL PROTECTED]

Do you have 'session.auto_start=1' in your php.ini ? (or php-cli.ini)
Does this happen with PHP 4.2.3?



[2002-12-05 00:26:04] [EMAIL PROTECTED]

still have this error with same backtrace =(



[2002-12-04 18:18:42] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip





[2002-11-24 05:11:18] [EMAIL PROTECTED]

i installed now the libc6-dbg package and put /usr/lib/debug in
LD_LIBRARY_PATH and now is the error in another function of libc

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 26000)]
0x403367d0 in main_arena () from /usr/lib/debug/libc.so.6
(gdb) bt
#0  0x403367d0 in main_arena () from /usr/lib/debug/libc.so.6
#1  0x403367c0 in main_arena () from /usr/lib/debug/libc.so.6
#2  0x403367c0 in main_arena () from /usr/lib/debug/libc.so.6
#3  0x403367c8 in main_arena () from /usr/lib/debug/libc.so.6
#4  0x403367b0 in main_arena () from /usr/lib/debug/libc.so.6
#5  0x403367a8 in main_arena () from /usr/lib/debug/libc.so.6
#6  0x403367a0 in main_arena () from /usr/lib/debug/libc.so.6
#7  0x40336798 in main_arena () from /usr/lib/debug/libc.so.6
#8  0x40336790 in main_arena () from /usr/lib/debug/libc.so.6
#9  0x081a4560 in ?? ()



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/20604

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

#20641 [Fbk->NoF]: Numeric type returns invalid result using ibase_fetch_row/ibase_fetch_object

[php-bugs]

 ID:   20641
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: InterBase related
 Operating System: Windows NT / Firebird 1.0
 PHP Version:  4.2.3
 New Comment:

No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".


Previous Comments:


[2002-12-04 22:49:33] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip





[2002-11-26 04:38:19] [EMAIL PROTECTED]

Numeric type returns invalid result using
ibase_fetch_row/ibase_fetch_object (Windows NT).

Numbers stored as an InterBase/Firebird numeric/decimal datatype
beyond
the bounds of the PHP integer type (> 2147483647), do not return a
float
type but cause an overflow 

Example:
2303511415 (decimal 10,0) returns -1991455881

PHP/Firebird example script:
$sql = "create table temp (large_number numeric(10,0))";
$result = ibase_query($sql,connection()); 
if (!$result) {
  exit;
}
ibase_commit();


$sql = "INSERT INTO temp VALUES (2303511415)";
$result = ibase_query($sql,connection()); 
if (!$result) {
  exit;
}

$sql = "SELECT large_number FROM temp WHERE large_number =
2303511415";
$result = ibase_query($sql,connection()); 
if (!$result) {
  exit;
}

while ($row = ibase_fetch_row($result)) {
   print($row[0]); 
}

ibase_free_result($result);

$sql = "drop table temp";
$result = ibase_query($sql,connection()); 
if (!$result) {
  exit;
}
ibase_commit();



[2002-11-26 03:24:19] [EMAIL PROTECTED]

Numeric type returns invalid result using
ibase_fetch_row/ibase_fetch_object (Windows NT).

Numbers stored as an InterBase/Firebird numeric/decimal datatype beyond
the bounds of the PHP integer type (> 2147483647), do not return a
float type but cause an overflow 

Example:
2303511415 (decimal 10,0) returns -1991455881

PHP/Firebird example script:
$sql = "create table temp (large_number numeric(10,0))";
$result = ibase_query($sql,connection()); 
if (!$result) {
  exit;
}

$sql = "INSERT INTO temp VALUES (2303511415)";
$result = ibase_query($sql,connection()); 
if (!$result) {
  exit;
}

$sql = "SELECT large_number FROM temp WHERE large_number =
2303511415";
$result = ibase_query($sql,connection()); 
if (!$result) {
  exit;
}

while ($row = ibase_fetch_row($result)) {
   print($row[0]); 
}




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

#21127 [NEW]: CSRSS.exe 100%

[korngerd]

From: [EMAIL PROTECTED]
Operating system: Windows XP
PHP version:  4.3.0RC3
PHP Bug Type: Performance problem
Bug description:  CSRSS.exe 100%

Whenever someone uploads to my FTP server, I use PHP to execute my scripts.
 Now, although I haven't pinpointed the problem yet, it seems like PHP is
causing CSRSS.exe (Windows' client/server runtime server subsystem), a
system process, to jump up to 100% CPU usage.  I'll try looking into the
problem in more detail, but I just thought I'd post this up for now.
-- 
Edit bug report at http://bugs.php.net/?id=21127&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21127&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=21127&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=21127&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21127&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=21127&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21127&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=21127&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21127&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21127&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=21127&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21127&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=21127&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=21127&r=isapi

#20232 [Fbk->Opn]: php.exe causes errors when using socket_create

[pickleman78]

 ID:   20232
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Sockets related
 Operating System: Windows ME
-PHP Version:  4.3.0-dev
+PHP Version:  4.4.0-dev
 New Comment:

Still nothing, can anyone else actually confirm this error or is my
machine just messed up.


Previous Comments:


[2002-12-19 23:10:11] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip





[2002-11-12 22:33:55] [EMAIL PROTECTED]

ok, well, i have scontinued to test it, and it is not just the script i
wroe, I also changed the title to something that seems more descriptive
to the problem



[2002-11-08 16:49:25] [EMAIL PROTECTED]

How odd.

I have found some other interesiting tidbit. It will not accept any
string, but this does work...

$host=getenv("REMOTE_ADDR");



[2002-11-07 18:49:13] [EMAIL PROTECTED]

forget that last comment, I was just changing the PHP version
information..




[2002-11-07 18:48:38] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip





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/20232

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

#21126 [Opn->Csd]: returncodes in shell $? aren't correct

[cynic]

 ID:   21126
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Output Control
 Operating System: Solaris 9 - Sparc
 PHP Version:  4.2.2
 New Comment:

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.


Previous Comments:


[2002-12-20 20:02:49] [EMAIL PROTECTED]

Hello,

there is something wrong with the exitcodes in PHP. I use it instead of
Perl for some shellscript addons. I need the exitcodes for sendmail.

Example:


Return as exitcode 0 which is ok.


Return as exitcode 255 which isn't ok.


Print out 79 and return exitcode 255, which isn't ok as well.


Here my configure:

'./configure' '--prefix=/www-1/src/php'
'--with-apxs=/usr/local/apache/bin/apxs'
'--with-config-file-path=/usr/local/apache/conf/' '--enable-versioning'
'--with-mysql=/usr/local/mysql' '--enable-ftp' '--enable-bcmath'
'--disable-debug' '--enable-memory-limit=yes' '--enable-track-vars'
'--enable-calendar' '--enable-force-cgi-redirect' '--enable-libgcc'
'--enable-trans-sid' '--with-java=/usr/java' '--enable-yp'
'--enable-sysvsem' '--enable-sysvshm' '--with-zlib=/sw/es-tools/'
'--with-gd=/sw/es-tools/' '--with-system-regex'
'--with-jpeg-dir=/sw/es-tools/pkg/jpeg-6b/'
'--with-tiff-dir=/sw/es-tools/pkg/tiff-3.5.7/'
'--with-ldap=/usr/local/' '--with-db3=/usr/local/BerkeleyDB.3.3/'
'--enable-cli'

I don't  think that a backtrace should help here. If yes, please
contact me.

Thx in forward.

Peter






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

#21126 [NEW]: returncodes in shell $? aren't correct

[Peter . Valicek]

From: [EMAIL PROTECTED]
Operating system: Solaris 9 - Sparc
PHP version:  4.2.2
PHP Bug Type: Output Control
Bug description:  returncodes in shell $? aren't correct

Hello,

there is something wrong with the exitcodes in PHP. I use it instead of
Perl for some shellscript addons. I need the exitcodes for sendmail.

Example:


Return as exitcode 0 which is ok.


Return as exitcode 255 which isn't ok.


Print out 79 and return exitcode 255, which isn't ok as well.


Here my configure:

'./configure' '--prefix=/www-1/src/php'
'--with-apxs=/usr/local/apache/bin/apxs'
'--with-config-file-path=/usr/local/apache/conf/' '--enable-versioning'
'--with-mysql=/usr/local/mysql' '--enable-ftp' '--enable-bcmath'
'--disable-debug' '--enable-memory-limit=yes' '--enable-track-vars'
'--enable-calendar' '--enable-force-cgi-redirect' '--enable-libgcc'
'--enable-trans-sid' '--with-java=/usr/java' '--enable-yp'
'--enable-sysvsem' '--enable-sysvshm' '--with-zlib=/sw/es-tools/'
'--with-gd=/sw/es-tools/' '--with-system-regex'
'--with-jpeg-dir=/sw/es-tools/pkg/jpeg-6b/'
'--with-tiff-dir=/sw/es-tools/pkg/tiff-3.5.7/' '--with-ldap=/usr/local/'
'--with-db3=/usr/local/BerkeleyDB.3.3/' '--enable-cli'

I don't  think that a backtrace should help here. If yes, please contact
me.

Thx in forward.

Peter


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

#21123 [Bgs]: Call Time pass by Reference should not be removed

[cynic]

 ID:   21123
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Feature/Change Request
 Operating System: All
 PHP Version:  4.2.3
 New Comment:

my apology for the offence.

i *did* read the whole thing.
PHP is not Perl, you can't squeeze a web application into $^&, neither
would doing so make your application more readable.
we apparently have different opinion on what constitutes
code-cleanness.

i'm not a member of the PHP development group, i just close a PR every
now and then, and that requires a @php.net account.




Previous Comments:


[2002-12-20 18:09:01] [EMAIL PROTECTED]

Oh and I'm surprised by the fact you appear to be a member of the PHP
development group yet from a very valid request you take the
opportunity to insult me. I've been developing PHP professionly since
version 3.0.9.  I think that's about 4 years now.  I've found a lot of
the 'staff' very friendly and helpful, Cardinal, Philip, even Rasmus at
times. You however, chose to insult me rather than completely
understand my request. Thanks, I'm glad I spent all that money on PHP
shirts to help support the project.



[2002-12-20 18:04:11] [EMAIL PROTECTED]

Apparently you aren't reading my entire comment. First off if you took
the time to understand what depreciated means, Call Time Pass by
Reference will be removed entirely from PHP. Meaning I can't turn it on
in php.ini by setting allow_call_time_pass_reference. That option will
no longer exist in future versions of PHP.

Second, yes that is the way around it. And my point exactly. Removing
Call Time Pass by Reference was intended to make PHP code a bit
cleaner. Well instead of adding one character & to my function, I now
have to create an entirely new function to add to my class. So wheres
the benefit? No instead of consolidating it into one function I have to
split it into two that do 99% the same thing due to the fact Call Time
Pass by Reference was removed. I still don't see the reason for
removing it at all.



[2002-12-20 17:47:30] [EMAIL PROTECTED]

1) you can easily get around this with XForm::addByVal() /
XForm::addByRef()
2) I wonder how you got around writing a "very large application"
without ever looking in php.ini?





[2002-12-20 17:27:33] [EMAIL PROTECTED]

In my opinion I do not think depreciating and removing the Call Time
Pass by Reference feature of PHP is a good idea. There are a number of
valid reasons to use this feature, to which this feature is the only
solution. While programming a very large web database application for
my employer, I've found where this feature is extremely useful. Yet
when I've upgraded to new versions of PHP I've come to find that it is
depreciated. 

My example. In this application I've written a series of classes, I
call them XElements. Each XElement is essentially a class that is
dedicated to an XHTML 1.0 element.  So for example, I have an XForm,
XTable, XTd, XTr, etc.  They all inherit the XElement class. The
XElement class has a number of methods that are useful. The most
important two are add() and draw().  

The add() method takes one argument. This argument is then put into an
array variable of the object, maintaining the order by call to add(). 
So each time I call add() it adds this argument to the end of the
array. What are these arguments? They are the nested CDATA.  Consider
this:



Name

Password

 


The way my code above would work is like this.

$myForm =& new XForm();
$myP =& new XP();
$myForm->add(&$myP);

$myP->add("Name");

$myInput1 =& new XInput();
$myP->add(&$myInput1);

$myP->add("Password");

$myInput2 =& new XInput();
$myP->add(&$myInput2);

$myForm->draw();

This is partially pseudo, since my real constructors have many
arguments for attributes of the XHTML code, I've left them out of this
example for clarity. Now with that in mind, onto draw().

The draw() method does one simple thing. It iterates through the array
of CDATA, and writes it out either by 1) if it's a string, echo it, 2)
if it's an object, assume its an XElement and call that XElement's
draw(). You can see how it then works. draw() manages the closing tags,
and knows which tags are allowed CDATA and which are not thus using />
instead of > as well. 

Now, with the above example we can see where Call Time Pass by
Reference comes into play.  If in the first part of my code, I did
$myForm->add($myP); instead of $myForm->add(&$myP); that would create a
copy of $myP and pass it to add().  Then any calls to $myP after that
add() won't reflect the $myP stored in the CDATA Array.  I could modify
t

#21123 [Com]: Call Time pass by Reference should not be removed

[russ]

 ID:   21123
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Feature/Change Request
 Operating System: All
 PHP Version:  4.2.3
 New Comment:

Oh and I'm surprised by the fact you appear to be a member of the PHP
development group yet from a very valid request you take the
opportunity to insult me. I've been developing PHP professionly since
version 3.0.9.  I think that's about 4 years now.  I've found a lot of
the 'staff' very friendly and helpful, Cardinal, Philip, even Rasmus at
times. You however, chose to insult me rather than completely
understand my request. Thanks, I'm glad I spent all that money on PHP
shirts to help support the project.


Previous Comments:


[2002-12-20 18:04:11] [EMAIL PROTECTED]

Apparently you aren't reading my entire comment. First off if you took
the time to understand what depreciated means, Call Time Pass by
Reference will be removed entirely from PHP. Meaning I can't turn it on
in php.ini by setting allow_call_time_pass_reference. That option will
no longer exist in future versions of PHP.

Second, yes that is the way around it. And my point exactly. Removing
Call Time Pass by Reference was intended to make PHP code a bit
cleaner. Well instead of adding one character & to my function, I now
have to create an entirely new function to add to my class. So wheres
the benefit? No instead of consolidating it into one function I have to
split it into two that do 99% the same thing due to the fact Call Time
Pass by Reference was removed. I still don't see the reason for
removing it at all.



[2002-12-20 17:47:30] [EMAIL PROTECTED]

1) you can easily get around this with XForm::addByVal() /
XForm::addByRef()
2) I wonder how you got around writing a "very large application"
without ever looking in php.ini?





[2002-12-20 17:27:33] [EMAIL PROTECTED]

In my opinion I do not think depreciating and removing the Call Time
Pass by Reference feature of PHP is a good idea. There are a number of
valid reasons to use this feature, to which this feature is the only
solution. While programming a very large web database application for
my employer, I've found where this feature is extremely useful. Yet
when I've upgraded to new versions of PHP I've come to find that it is
depreciated. 

My example. In this application I've written a series of classes, I
call them XElements. Each XElement is essentially a class that is
dedicated to an XHTML 1.0 element.  So for example, I have an XForm,
XTable, XTd, XTr, etc.  They all inherit the XElement class. The
XElement class has a number of methods that are useful. The most
important two are add() and draw().  

The add() method takes one argument. This argument is then put into an
array variable of the object, maintaining the order by call to add(). 
So each time I call add() it adds this argument to the end of the
array. What are these arguments? They are the nested CDATA.  Consider
this:



Name

Password

 


The way my code above would work is like this.

$myForm =& new XForm();
$myP =& new XP();
$myForm->add(&$myP);

$myP->add("Name");

$myInput1 =& new XInput();
$myP->add(&$myInput1);

$myP->add("Password");

$myInput2 =& new XInput();
$myP->add(&$myInput2);

$myForm->draw();

This is partially pseudo, since my real constructors have many
arguments for attributes of the XHTML code, I've left them out of this
example for clarity. Now with that in mind, onto draw().

The draw() method does one simple thing. It iterates through the array
of CDATA, and writes it out either by 1) if it's a string, echo it, 2)
if it's an object, assume its an XElement and call that XElement's
draw(). You can see how it then works. draw() manages the closing tags,
and knows which tags are allowed CDATA and which are not thus using />
instead of > as well. 

Now, with the above example we can see where Call Time Pass by
Reference comes into play.  If in the first part of my code, I did
$myForm->add($myP); instead of $myForm->add(&$myP); that would create a
copy of $myP and pass it to add().  Then any calls to $myP after that
add() won't reflect the $myP stored in the CDATA Array.  I could modify
the declaration of add() so that it takes a reference for the argument,
function add(&$arg) { ... }.  However, then I go to do
$myP->add("Name");, this would happen:

Fatal error: Cannot pass parameter 1 by reference

So what once would originally have only taken one function, would
require two if Call Time Pass by Reference was removed. I'd have to
create one function to add non-references, and one to add references. 
One could say I could have a function for adding string CDATA, and one
for addi

#21123 [Com]: Call Time pass by Reference should not be removed

[russ]

 ID:   21123
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Feature/Change Request
 Operating System: All
 PHP Version:  4.2.3
 New Comment:

Apparently you aren't reading my entire comment. First off if you took
the time to understand what depreciated means, Call Time Pass by
Reference will be removed entirely from PHP. Meaning I can't turn it on
in php.ini by setting allow_call_time_pass_reference. That option will
no longer exist in future versions of PHP.

Second, yes that is the way around it. And my point exactly. Removing
Call Time Pass by Reference was intended to make PHP code a bit
cleaner. Well instead of adding one character & to my function, I now
have to create an entirely new function to add to my class. So wheres
the benefit? No instead of consolidating it into one function I have to
split it into two that do 99% the same thing due to the fact Call Time
Pass by Reference was removed. I still don't see the reason for
removing it at all.


Previous Comments:


[2002-12-20 17:47:30] [EMAIL PROTECTED]

1) you can easily get around this with XForm::addByVal() /
XForm::addByRef()
2) I wonder how you got around writing a "very large application"
without ever looking in php.ini?





[2002-12-20 17:27:33] [EMAIL PROTECTED]

In my opinion I do not think depreciating and removing the Call Time
Pass by Reference feature of PHP is a good idea. There are a number of
valid reasons to use this feature, to which this feature is the only
solution. While programming a very large web database application for
my employer, I've found where this feature is extremely useful. Yet
when I've upgraded to new versions of PHP I've come to find that it is
depreciated. 

My example. In this application I've written a series of classes, I
call them XElements. Each XElement is essentially a class that is
dedicated to an XHTML 1.0 element.  So for example, I have an XForm,
XTable, XTd, XTr, etc.  They all inherit the XElement class. The
XElement class has a number of methods that are useful. The most
important two are add() and draw().  

The add() method takes one argument. This argument is then put into an
array variable of the object, maintaining the order by call to add(). 
So each time I call add() it adds this argument to the end of the
array. What are these arguments? They are the nested CDATA.  Consider
this:



Name

Password

 


The way my code above would work is like this.

$myForm =& new XForm();
$myP =& new XP();
$myForm->add(&$myP);

$myP->add("Name");

$myInput1 =& new XInput();
$myP->add(&$myInput1);

$myP->add("Password");

$myInput2 =& new XInput();
$myP->add(&$myInput2);

$myForm->draw();

This is partially pseudo, since my real constructors have many
arguments for attributes of the XHTML code, I've left them out of this
example for clarity. Now with that in mind, onto draw().

The draw() method does one simple thing. It iterates through the array
of CDATA, and writes it out either by 1) if it's a string, echo it, 2)
if it's an object, assume its an XElement and call that XElement's
draw(). You can see how it then works. draw() manages the closing tags,
and knows which tags are allowed CDATA and which are not thus using />
instead of > as well. 

Now, with the above example we can see where Call Time Pass by
Reference comes into play.  If in the first part of my code, I did
$myForm->add($myP); instead of $myForm->add(&$myP); that would create a
copy of $myP and pass it to add().  Then any calls to $myP after that
add() won't reflect the $myP stored in the CDATA Array.  I could modify
the declaration of add() so that it takes a reference for the argument,
function add(&$arg) { ... }.  However, then I go to do
$myP->add("Name");, this would happen:

Fatal error: Cannot pass parameter 1 by reference

So what once would originally have only taken one function, would
require two if Call Time Pass by Reference was removed. I'd have to
create one function to add non-references, and one to add references. 
One could say I could have a function for adding string CDATA, and one
for adding XElements, however there comes a time when I don't want to
add a reference to a XElement, but rather have it store a copy. This
may come into play if say I wanted to construct one XInput then change
a field in the object and re-add it over and over, then I would omit
the Call Time Pass by Reference.

>From what I can gather, removing Call Time Pass by Reference was
suppose to make it easier to read code, however if I have to add an
additional function to manage non-references, I'm don't see the
benefits anymore.
 






-- 
Edit this bug repo

#21125 [NEW]: ncurses extension includes example INI settings

[leon]

From: [EMAIL PROTECTED]
Operating system: 
PHP version:  4CVS-2002-12-20 (dev)
PHP Bug Type: Unknown/Other Function
Bug description:  ncurses extension includes example INI settings

ext/ncurses/ncurses.c contains two php.ini settings that appear to be
unaltered from the skeleton.  These are ncurses.value and ncurses.string.
-- 
Edit bug report at http://bugs.php.net/?id=21125&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21125&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=21125&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=21125&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21125&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=21125&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21125&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=21125&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21125&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21125&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=21125&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21125&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=21125&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=21125&r=isapi

#21123 [Opn->Bgs]: Call Time pass by Reference should not be removed

[cynic]

 ID:   21123
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Feature/Change Request
 Operating System: All
 PHP Version:  4.2.3
 New Comment:

1) you can easily get around this with XForm::addByVal() /
XForm::addByRef()
2) I wonder how you got around writing a "very large application"
without ever looking in php.ini?




Previous Comments:


[2002-12-20 17:27:33] [EMAIL PROTECTED]

In my opinion I do not think depreciating and removing the Call Time
Pass by Reference feature of PHP is a good idea. There are a number of
valid reasons to use this feature, to which this feature is the only
solution. While programming a very large web database application for
my employer, I've found where this feature is extremely useful. Yet
when I've upgraded to new versions of PHP I've come to find that it is
depreciated. 

My example. In this application I've written a series of classes, I
call them XElements. Each XElement is essentially a class that is
dedicated to an XHTML 1.0 element.  So for example, I have an XForm,
XTable, XTd, XTr, etc.  They all inherit the XElement class. The
XElement class has a number of methods that are useful. The most
important two are add() and draw().  

The add() method takes one argument. This argument is then put into an
array variable of the object, maintaining the order by call to add(). 
So each time I call add() it adds this argument to the end of the
array. What are these arguments? They are the nested CDATA.  Consider
this:



Name

Password

 


The way my code above would work is like this.

$myForm =& new XForm();
$myP =& new XP();
$myForm->add(&$myP);

$myP->add("Name");

$myInput1 =& new XInput();
$myP->add(&$myInput1);

$myP->add("Password");

$myInput2 =& new XInput();
$myP->add(&$myInput2);

$myForm->draw();

This is partially pseudo, since my real constructors have many
arguments for attributes of the XHTML code, I've left them out of this
example for clarity. Now with that in mind, onto draw().

The draw() method does one simple thing. It iterates through the array
of CDATA, and writes it out either by 1) if it's a string, echo it, 2)
if it's an object, assume its an XElement and call that XElement's
draw(). You can see how it then works. draw() manages the closing tags,
and knows which tags are allowed CDATA and which are not thus using />
instead of > as well. 

Now, with the above example we can see where Call Time Pass by
Reference comes into play.  If in the first part of my code, I did
$myForm->add($myP); instead of $myForm->add(&$myP); that would create a
copy of $myP and pass it to add().  Then any calls to $myP after that
add() won't reflect the $myP stored in the CDATA Array.  I could modify
the declaration of add() so that it takes a reference for the argument,
function add(&$arg) { ... }.  However, then I go to do
$myP->add("Name");, this would happen:

Fatal error: Cannot pass parameter 1 by reference

So what once would originally have only taken one function, would
require two if Call Time Pass by Reference was removed. I'd have to
create one function to add non-references, and one to add references. 
One could say I could have a function for adding string CDATA, and one
for adding XElements, however there comes a time when I don't want to
add a reference to a XElement, but rather have it store a copy. This
may come into play if say I wanted to construct one XInput then change
a field in the object and re-add it over and over, then I would omit
the Call Time Pass by Reference.

>From what I can gather, removing Call Time Pass by Reference was
suppose to make it easier to read code, however if I have to add an
additional function to manage non-references, I'm don't see the
benefits anymore.
 






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

#21123 [NEW]: Call Time pass by Reference should not be removed

[russ]

From: [EMAIL PROTECTED]
Operating system: All
PHP version:  4.2.3
PHP Bug Type: Feature/Change Request
Bug description:  Call Time pass by Reference should not be removed

In my opinion I do not think depreciating and removing the Call Time Pass
by Reference feature of PHP is a good idea. There are a number of valid
reasons to use this feature, to which this feature is the only solution.
While programming a very large web database application for my employer,
I've found where this feature is extremely useful. Yet when I've upgraded
to new versions of PHP I've come to find that it is depreciated. 

My example. In this application I've written a series of classes, I call
them XElements. Each XElement is essentially a class that is dedicated to
an XHTML 1.0 element.  So for example, I have an XForm, XTable, XTd, XTr,
etc.  They all inherit the XElement class. The XElement class has a number
of methods that are useful. The most important two are add() and draw(). 


The add() method takes one argument. This argument is then put into an
array variable of the object, maintaining the order by call to add().  So
each time I call add() it adds this argument to the end of the array. What
are these arguments? They are the nested CDATA.  Consider this:



Name

Password

 


The way my code above would work is like this.

$myForm =& new XForm();
$myP =& new XP();
$myForm->add(&$myP);

$myP->add("Name");

$myInput1 =& new XInput();
$myP->add(&$myInput1);

$myP->add("Password");

$myInput2 =& new XInput();
$myP->add(&$myInput2);

$myForm->draw();

This is partially pseudo, since my real constructors have many arguments
for attributes of the XHTML code, I've left them out of this example for
clarity. Now with that in mind, onto draw().

The draw() method does one simple thing. It iterates through the array of
CDATA, and writes it out either by 1) if it's a string, echo it, 2) if
it's an object, assume its an XElement and call that XElement's draw().
You can see how it then works. draw() manages the closing tags, and knows
which tags are allowed CDATA and which are not thus using /> instead of >
as well. 

Now, with the above example we can see where Call Time Pass by Reference
comes into play.  If in the first part of my code, I did
$myForm->add($myP); instead of $myForm->add(&$myP); that would create a
copy of $myP and pass it to add().  Then any calls to $myP after that
add() won't reflect the $myP stored in the CDATA Array.  I could modify
the declaration of add() so that it takes a reference for the argument,
function add(&$arg) { ... }.  However, then I go to do $myP->add("Name");,
this would happen:

Fatal error: Cannot pass parameter 1 by reference

So what once would originally have only taken one function, would require
two if Call Time Pass by Reference was removed. I'd have to create one
function to add non-references, and one to add references.  One could say
I could have a function for adding string CDATA, and one for adding
XElements, however there comes a time when I don't want to add a reference
to a XElement, but rather have it store a copy. This may come into play if
say I wanted to construct one XInput then change a field in the object and
re-add it over and over, then I would omit the Call Time Pass by
Reference.

>From what I can gather, removing Call Time Pass by Reference was suppose
to make it easier to read code, however if I have to add an additional
function to manage non-references, I'm don't see the benefits anymore.
 


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

#21121 [NEW]: < br > in notes

[sebastian . haller]

From: [EMAIL PROTECTED]
Operating system: Win98
PHP version:  4.3.0RC3
PHP Bug Type: Output Control
Bug description:  < br > in notes

I can't write < br > (without spaces) in notes. It's always replaces by a
'new line'.

See for example
http://www.php.net/manual/de/function.nl2br.php (trevor at verite dot com
/ php at fendforyourself dot com)
or http://www.php.net/manual/de/function.htmlspecialchars.php
(the last comment 20 dec 2002, note in end)

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

#21120 [NEW]: fflush doesn`t work

[rashid]

From: [EMAIL PROTECTED]
Operating system: win2k pro
PHP version:  4.2.3
PHP Bug Type: Filesystem function related
Bug description:  fflush doesn`t work

this is not the same as
http://bugs.php.net/bug.php?id=19711 :)

the following code on my platform displays:
File size: 0, written: 2890
File size: 2890, written: 2890

as far as i know fflush should flush output to file at the moment of
calling :] moving the line with flcose to the end of script causes that
also the second display shows
File size: 0, written: 2890
it looks for me that fflush doesn`t work and all flushing is done during
file closing.
tested it under linux also - both variants are done ok there:
File size: 2890, written: 2890
File size: 2890, written: 2890 

$str = '';
for($i = 0;$i < 1000;$i++) {
$str .= $i;
}

$fp = fopen('test.txt', 'wb');
$written = fwrite($fp, $str);
fflush($fp);
clearstatcache();
$size = filesize('test.txt');
echo 'File size: '.$size.', written: '.$written.'';
fclose($fp);
clearstatcache();
$size = filesize('test.txt');
echo 'File size: '.$size.', written: '.$written.'';

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

#16524 [Com]: PHP script crashes iPlanet

[mykeolson]

 ID:   16524
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   No Feedback
 Bug Type: iPlanet related
 Operating System: Windows 2000
 PHP Version:  4.1.2
 New Comment:

We've also noticed the same/similar bug using PHP 4.1.2 with iPlanet
4.1 on Solaris 7.  Using the exact same code, one page works and can
connect to the database just fine, but with another page, it kept dying
at the OCILogon function.  Normally, bouncing the iPlanet web server
would fix the problem, but then one day, that solution stopped
working.

OCILogon (or OCIPLogin) would just die and not respect an "or die"
message.

The solution seemed to be to change the Host = line to use the IP
address of the database server instead of the hostname.


Previous Comments:


[2002-10-18 01:00:02] [EMAIL PROTECTED]

No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2002-09-29 20:32:59] [EMAIL PROTECTED]

Does the solution provided in #10821 work for you?




[2002-08-14 23:15:00] [EMAIL PROTECTED]

dup of 10821



[2002-04-11 13:51:21] [EMAIL PROTECTED]

If I run PHP from the command line, it works fine.  But if I try to
execute any PHP script, no matter how simple, the iPlanet portal shuts
down.  Win2K logs the following error...
The description for Event ID ( 25 ) in Source ( WebServer 4.1 ) cannot
be found. The local computer may not have the necessary registry
information or message DLL files to display messages from a remote
computer. The following information is part of the event:
https-enlace_2, 0.

I'm new to PHP, I've tried setting every logging parameter in the
php.ini file and havn't gotten anything

Please, give me a clue, throw me a bone,



[2002-04-10 15:49:46] [EMAIL PROTECTED]

Yes.  But I had trouble figuring out how to get a back trace based on
the link that was sent...
http://bugs.php.net/bugs-generating-backtrace.php



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/16524

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

#21114 [Opn->Csd]: Getting BLOB (image) Field with Sybase db

[sesser]

 ID:   21114
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Sybase (dblib) related
 Operating System: linux 2.4.19
 PHP Version:  4.2.3
 New Comment:

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2002-12-20 13:25:00] [EMAIL PROTECTED]

SQL-Server 2000 submits type SYBIMAGE as datatype.
In file php_sybase_db.c function php_sybase_get_column_content only the
types SYBBINARY and SYBVARBINARY are updated with double buffer size,
not the SYBIMAGE which is submitted from SQL2000.



[2002-12-20 10:11:49] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip





[2002-12-20 08:39:45] [EMAIL PROTECTED]

When selecting an image field from a table sybase_query
causes a segmentation fault in apache server.
The error occures when converting datatype image to char in
file php_sybase_db.c function php_sybase_get_column_content.
The problem is that the buffer is to small for the hex-string.
The buffer had to be the double size because a char is translated in 2
bytes.
If you increase the buffersize to 2*res_length its ok.




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

#21114 [Fbk->Opn]: Getting BLOB (image) Field with Sybase db

[martin . schlaak]

 ID:   21114
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Sybase (dblib) related
 Operating System: linux 2.4.19
 PHP Version:  4.2.3
 New Comment:

SQL-Server 2000 submits type SYBIMAGE as datatype.
In file php_sybase_db.c function php_sybase_get_column_content only the
types SYBBINARY and SYBVARBINARY are updated with double buffer size,
not the SYBIMAGE which is submitted from SQL2000.


Previous Comments:


[2002-12-20 10:11:49] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip





[2002-12-20 08:39:45] [EMAIL PROTECTED]

When selecting an image field from a table sybase_query
causes a segmentation fault in apache server.
The error occures when converting datatype image to char in
file php_sybase_db.c function php_sybase_get_column_content.
The problem is that the buffer is to small for the hex-string.
The buffer had to be the double size because a char is translated in 2
bytes.
If you increase the buffersize to 2*res_length its ok.




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

#21119 [Opn->Csd]: Modified Control Structures

[derick]

 ID:   21119
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Feature/Change Request
 Operating System: NA
 PHP Version:  4.2.3
 New Comment:

if (in_array($x, array ('cats', 'dogs', 'birds))) {

should be as useful as introducing a new construct.

Derick


Previous Comments:


[2002-12-20 13:01:08] [EMAIL PROTECTED]

Here's a suggestion that we(local developers in Carbondale,IL) all feel
would improve usability of the control structures in PHP.

What if in this statement...
  if (($x == 'cats') && ($x == 'dogs') && ($x == 'birds')) {
we instead could say...
  if ($x IN 'cats','dogs','birds') {

This would reduce typing and allow you to compare lists(arrays) in your
conditional statements without using array functions.




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

#21119 [NEW]: Modified Control Structures

[ericf]

From: [EMAIL PROTECTED]
Operating system: NA
PHP version:  4.2.3
PHP Bug Type: Feature/Change Request
Bug description:  Modified Control Structures

Here's a suggestion that we(local developers in Carbondale,IL) all feel
would improve usability of the control structures in PHP.

What if in this statement...
  if (($x == 'cats') && ($x == 'dogs') && ($x == 'birds')) {
we instead could say...
  if ($x IN 'cats','dogs','birds') {

This would reduce typing and allow you to compare lists(arrays) in your
conditional statements without using array functions.
-- 
Edit bug report at http://bugs.php.net/?id=21119&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21119&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=21119&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=21119&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21119&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=21119&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21119&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=21119&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21119&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21119&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=21119&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21119&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=21119&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=21119&r=isapi

#21118 [Opn->Bgs]: Can't load php_gettext.dll

[derick]

 ID:   21118
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Dynamic loading
 Operating System: Windows XP
 PHP Version:  4.2.3
 New Comment:

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php


Previous Comments:


[2002-12-20 12:50:24] [EMAIL PROTECTED]

Hello,

I can't load the php_gettext.dll-extension. Php-info() says: "Unable to
load dynamic libarary 'C:/web/php/extensions/php_gettext.dll' - Can't
find the modul  (german Error Message: Das angegebene Modul wurde nicht
gefunden)

The path is rigth and there are no problems with other extensions...

Any idea?

Greetings
 Dirk Kuch




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

#21118 [NEW]: Can't load php_gettext.dll

[Dirk . Kuch]

From: [EMAIL PROTECTED]
Operating system: Windows XP
PHP version:  4.2.3
PHP Bug Type: Dynamic loading
Bug description:  Can't load php_gettext.dll

Hello,

I can't load the php_gettext.dll-extension. Php-info() says: "Unable to
load dynamic libarary 'C:/web/php/extensions/php_gettext.dll' - Can't find
the modul  (german Error Message: Das angegebene Modul wurde nicht
gefunden)

The path is rigth and there are no problems with other extensions...

Any idea?

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

#21116 [Opn]: where do I find optional dlls?

[chrisz]

 ID:   21116
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: PHP options/info functions
 Operating System: Windows
 PHP Version:  4.3.0RC3
 New Comment:

I understand. I just wanted to point out the fact that it isn't there.
The dll needs to be packaged in the binary rather than having to go
look for it. Thanks for the info.


Previous Comments:


[2002-12-20 12:04:09] [EMAIL PROTECTED]

I'm not sure the policy of php.ini and extensions that aren't included
in the windows distro (dlls) but regardless this is a php-dev question
so am marking it as such.  I don't think the php.ini entry should be
removed though, I'm sure there are others and they are commented out.  
Also, this may have to do with PECL extensions being included or not.

Btw, you can find this (and many other dlls) here:
http://kromann.info/php4.php

Changing summary to: "Where do I find optional dlls?" :)



[2002-12-20 11:38:17] [EMAIL PROTECTED]

In the ini file there is a php_printer.dll option under extensions. No
such dll file exists in the extensions directory. This option just
needs to be deleted out of the ini file.




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

#21116 [Opn]: where do I find optional dlls?

[philip]

 ID:   21116
 Updated by:   [EMAIL PROTECTED]
-Summary:  INI file needs updating
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
-Bug Type: Documentation problem
+Bug Type: PHP options/info functions
 Operating System: Windows
 PHP Version:  4.3.0RC3
 New Comment:

I'm not sure the policy of php.ini and extensions that aren't included
in the windows distro (dlls) but regardless this is a php-dev question
so am marking it as such.  I don't think the php.ini entry should be
removed though, I'm sure there are others and they are commented out.  
Also, this may have to do with PECL extensions being included or not.

Btw, you can find this (and many other dlls) here:
http://kromann.info/php4.php

Changing summary to: "Where do I find optional dlls?" :)


Previous Comments:


[2002-12-20 11:38:17] [EMAIL PROTECTED]

In the ini file there is a php_printer.dll option under extensions. No
such dll file exists in the extensions directory. This option just
needs to be deleted out of the ini file.




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

#20282 [Opn]: COM memory leak

[sven . packmor]

 ID:   20282
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: COM related
 Operating System: Win2000/XP
 PHP Version:  4.2.3
 New Comment:

Hi there,

it's possible that we will hire a developer to fix this bug. If 
somebody is in the mood to do bugfixing, please contact me under
[EMAIL PROTECTED]

Sven


Previous Comments:


[2002-12-09 15:31:19] [EMAIL PROTECTED]

as soon as anybody is in the mood to fix it  ... erm, and 'Hi, how
about bugfixing ?' or 'Is it possible to get a solution soon?' for sure
doesn't bring anyone into that mood.
but you have full access to the sources and can always send in a
patch.

harald



[2002-12-09 03:21:45] [EMAIL PROTECTED]

Hi Derick,

if we don't hire an PHP developer, when do you think the bug will be
fixed? Is there a roadmap for this bug?

Sven



[2002-12-02 04:02:04] [EMAIL PROTECTED]

Well, you can always hire a PHP developer to do it if it is so urgent
for your project. Please don't forget that PHP is an Open Source
project, totally run by volunteers which dedicate their spare time to
develop on PHP.

Derick



[2002-12-02 03:21:25] [EMAIL PROTECTED]

Hi, how about bugfixing? Is it possible to get a solution soon? We are
developing for DaimlerChrysler germany. Our project stagnate. We have a
lot of data to transport across COM-mechanism. It's very urgent to get
a bugfixing. Can you help us?



[2002-11-18 11:54:36] [EMAIL PROTECTED]

Yes, i tryed. Using php-cgi.exe instead of php.exe i got php working.
Here my measuring depending on repetitions for version 4.3.0 :

  0   10002000   1
excel.exe7.500K 9.708K 11.600K 26.516K
php-cgi.exe  5.688K 8.084K 10.612K 29.716K



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/20282

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

#21105 [Fbk->Opn]: Child segfault running mash()

[ncsml]

 ID:   21105
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: Linux (Redhat 7.3)
 PHP Version:  4.3.0RC3
 New Comment:

I just tried with the php4-STABLE-200212201630 snapshot  
and the segfault happended again.  This is using the SAPI  
module with mhash support compiled into libphp4.so  
  
Is it possbile i'm compiling mhash wrong?  Compiling mhash  
with:  
./configure --prefix=/usr --enable-shared=no  
 
Should I try with an older version of mhash and any 
suggestions as to what version so try with?


Previous Comments:


[2002-12-20 08:35:39] [EMAIL PROTECTED]

Does this happen with cli sapi and could you please try this is latest
PHP 4.3.0 snapshot. I cannot replicate the crash.



[2002-12-19 23:49:32] [EMAIL PROTECTED]

PHP 4.3.0RC3 compiled --with-mhash (not dso) using mhash 
0.8.17 segfaults when running this script: 
 ";  
  
?>  
(Does not segfault with MHASH_SHA1)  
  
Apache 1.3.27   
mod_ssl 2.8.11   
PHP 4.3.0RC3   
glibc 2.2.25-40   
gcc-2.96-112   
mhash 0.8.17 (static)   
   
php ./configure:   
 ./configure --prefix=/usr --exec-prefix=/usr  
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc  
--datadir=/usr/share --includedir=/usr/include  
--libdir=/usr/lib --libexecdir=/usr/libexec  
--localstatedir=/var --sharedstatedir=/usr/com  
--mandir=/usr/share/man --infodir=/usr/share/info  
--with-config-file-path=/etc --with-dom=/usr  
--with-exec-dir=/usr/bin --with-gettext  
--with-regex=system --with-layout=GNU  
--enable-magic-quotes --without-oci8 --with-mhash  
--with-imap=shared --with-openssl --with-imap-ssl  
--with-kerberos=/usr/kerberos --with-ldap=shared  
--with-mysql=shared,/usr --with-apxs=/usr/sbin/apxs  
--enable-debug --with-zlib  
   
Backtrace:   
Program received signal SIGSEGV, Segmentation fault.  
0x4207af66 in chunk_free () from /lib/i686/libc.so.6  
(gdb) bt  
#0  0x4207af66 in chunk_free () from /lib/i686/libc.so.6  
#1  0x4207ad14 in free () from /lib/i686/libc.so.6  
#2  0x4033795a in mhash_free (ptr=0x81ca550) at  
mhash.c:548  
#3  0x4070dace in zif_mhash (ht=2, return_value=0x81d20bc,  
this_ptr=0x0,  
return_value_used=1) at  
/usr/src/redhat/php-4.3.0RC3/ext/mhash/mhash.c:185  
#4  0x4080a65b in execute (op_array=0x81cd79c)  
at  
/usr/src/redhat/php-4.3.0RC3/Zend/zend_execute.c:1596  
#5  0x407f879c in zend_execute_scripts (type=8,  
retval=0x0, file_count=3)  
at /usr/src/redhat/php-4.3.0RC3/Zend/zend.c:864  
#6  0x407c106b in php_execute_script  
(primary_file=0xb6f0)  
at /usr/src/redhat/php-4.3.0RC3/main/main.c:1552  
#7  0x4080f63a in apache_php_module_main (r=0x808ced8,  
display_source_mode=0)  
at  
/usr/src/redhat/php-4.3.0RC3/sapi/apache/sapi_apache.c:55  
#8  0x40810504 in send_php (r=0x808ced8,  
display_source_mode=0,  
filename=0x808e9e0  
"/var/www/modesmail/admin/phpcrash.php")  
at  
/usr/src/redhat/php-4.3.0RC3/sapi/apache/mod_php4.c:556  
#9  0x40810571 in send_parsed_php (r=0x808ced8)  
at  
/usr/src/redhat/php-4.3.0RC3/sapi/apache/mod_php4.c:571  
#10 0x080547dd in ap_invoke_handler ()  
#11 0x0806769c in process_request_internal ()  
#12 0x08067713 in ap_process_request ()  
#13 0x0805f867 in child_main ()  
#14 0x0805fa0a in make_child ()  
#15 0x0805fb4d in startup_children ()  
#16 0x080601a0 in standalone_main ()  
#17 0x08060aa3 in main ()  
#18 0x42017589 in __libc_start_main () from  
/lib/i686/libc.so.6  
  




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

#21115 [NEW]: Function to parse Accept-like headers

[freaky]

From: [EMAIL PROTECTED]
Operating system: 
PHP version:  4.2.3
PHP Bug Type: Feature/Change Request
Bug description:  Function to parse Accept-like headers

Using content negotiation I often find myself wanting a low-cost but
correct way of parsing Accept headers, e.g, Accept: for
application/xhtml+xml or application/rdf+xml, or Accept-Language: for
en/fr/de/klingon, or Accept-Encoding: for UTF, or whatever.

Although parsing these in PHP isn't particularly difficult, it's fairly
expensive if you want to do it properly, handling weights and levels --
most don't bother.

A function to pass this work off to C would be nice, and would discourage
broken Accept header checks that ignore weighting (e.g. just searching
HTTP_ACCEPT for application/xhtml+xml breaks when it's q=0.0, and results
in undesirable behavior when text/html has a higher q=).

Given that serving XHTML as application/xhtml+xml is gaining in
popularity, I think this would be a valuable addition to PHP's API.
-- 
Edit bug report at http://bugs.php.net/?id=21115&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21115&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=21115&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=21115&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21115&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=21115&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21115&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=21115&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21115&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21115&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=21115&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21115&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=21115&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=21115&r=isapi

#21114 [Opn->Fbk]: Getting BLOB (image) Field with Sybase db

[sesser]

 ID:   21114
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Sybase (dblib) related
 Operating System: linux 2.4.19
 PHP Version:  4.2.3
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip




Previous Comments:


[2002-12-20 08:39:45] [EMAIL PROTECTED]

When selecting an image field from a table sybase_query
causes a segmentation fault in apache server.
The error occures when converting datatype image to char in
file php_sybase_db.c function php_sybase_get_column_content.
The problem is that the buffer is to small for the hex-string.
The buffer had to be the double size because a char is translated in 2
bytes.
If you increase the buffersize to 2*res_length its ok.




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

#20529 [Opn->Bgs]: Bad subject line when using JIS encoding

[moriyoshi]

 ID:   20529
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: mbstring related
 Operating System: red hat Linux 6.2
 PHP Version:  4.3.0RC1
 New Comment:

mb_send_mail() is smart enough to choose the appropriate encoding for
the language in which a mail is written. So it's not likely that you
are bothered by unnecessary encoding performed by this function. See
the test cases for mb_send_mail() that reside in
ext/mbstring/tests/mb_send_mail*.phpt for detail.

Anyway you should use mb_send_mail() in case you want to send mails
composed in the character sets other than US-ASCII or ISO-8859-* since
some MUA don't accept bare multibyte-encoded strings.

Regards,
Moriyoshi


Previous Comments:


[2002-12-20 02:42:58] [EMAIL PROTECTED]

Hi Again,
  I think actually this does, the problem is to do with the way the php
mail function handles the subject line, I don't think it is actually a
problem with the mb_string hence I originally posted to Mail. 

This bug was not apparent in any other version of php, of which we have
around 6 test servers and 5 main servers running. 

It has only started with the 4.3.0 versions. 

If you look closely you can will see that this also does not occur in
the message body of the email, just the header. It seams that the mail
function can no longer handle '' character for some reason and
replaces it with a blank space. 

In fact I do have a way around this which I am actively using. 
mb_language ( "ja");
mb_send_mail(  ) which does not seem to be affected by this bug.

I do not mind using mb_send_mail() from now on if this issue is not
going to be fixed but this is kinda annoying when you don't necessary
always want to write Japanese emails or use the base64 encoded subject
lines. 

Just to note, I know for a fact several big companies using php in
Japan are going to start experiencing this problem very soon if the
decide to upgrade to 4.3. As from what I have seen they all tend to use
the mail function which has worked very well up to now rather that the
mb_send_mail function.

Anyway thank for you help and time,
sorry that it could not be fixed,
thanks,
Malek

p.s. if after reading this you still think it not a bug please change
back to bogus, just put on open now to make sure you get this mail.



[2002-12-20 02:14:06] [EMAIL PROTECTED]

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

You should prepare mime headers(subject line, etc.) to be encoded in
base64. Please ask this kind of question at [EMAIL PROTECTED] or
[EMAIL PROTECTED](if you can understand Japanese) which you can
subscribe at the appropriate pages of http://www.php.net/ or
http://www.php.gr.jp/ respectively, before posting this kind of
question to the bug database.





[2002-12-20 01:58:47] [EMAIL PROTECTED]

Hi,
 Have just tried using the latest snapshot and the bug is still there,
no change,
thanks,
Malek



[2002-12-19 22:57:50] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip





[2002-11-20 19:19:33] [EMAIL PROTECTED]

Hi Ya,
  Basically I am using
PHP 4.3.0RC1 (but I have also noticed the same thing with PHP 4.3.0PR2
)
on Red Hat Linux 6.2
with Sendmail 8.9.3

I am basically trying to send a mail in Japanese,
I first encode the text into JIS then simply send as normal,
i.e.
".$subjectja,"Content-Type:
text/plain;charset=\"iso-2022-jp\"\nContent-Transfer-Encoding: 7bit");
// mail
?>
however the subject line does not appear correctly. On viewing the
email source I noticed that it is seemingly removing some characters
from the Subject line JIS,
Subject:  $B%G%$%j!<%l%]!<%H (B <--- this is the resulting subject
line which is broken

test->$B%G%$%j!<%l%]!<%H(B<--- this is the email body which works
fine

 $B%G%$%j!<%l%]!<%H (B
$B%G%$%j!<%l%]!<%H(B

slightly different. Also if you take out the "test->" on the body part
the body of the email will not to work.

p.s. there is no problems with 4.0,4.1 or 4.2

thanks,
Malek




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

#21114 [NEW]: Getting BLOB (image) Field with Sybase db

[martin . schlaak]

From: [EMAIL PROTECTED]
Operating system: linux 2.4.19
PHP version:  4.2.3
PHP Bug Type: Sybase (dblib) related
Bug description:  Getting BLOB (image) Field with Sybase db 

When selecting an image field from a table sybase_query
causes a segmentation fault in apache server.
The error occures when converting datatype image to char in
file php_sybase_db.c function php_sybase_get_column_content.
The problem is that the buffer is to small for the hex-string.
The buffer had to be the double size because a char is translated in 2
bytes.
If you increase the buffersize to 2*res_length its ok.
-- 
Edit bug report at http://bugs.php.net/?id=21114&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21114&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=21114&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=21114&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21114&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=21114&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21114&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=21114&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21114&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21114&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=21114&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21114&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=21114&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=21114&r=isapi

#21105 [Opn->Fbk]: Child segfault running mash()

[iliaa]

 ID:   21105
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Linux (Redhat 7.3)
 PHP Version:  4.3.0RC3
 New Comment:

Does this happen with cli sapi and could you please try this is latest
PHP 4.3.0 snapshot. I cannot replicate the crash.


Previous Comments:


[2002-12-19 23:49:32] [EMAIL PROTECTED]

PHP 4.3.0RC3 compiled --with-mhash (not dso) using mhash 
0.8.17 segfaults when running this script: 
 ";  
  
?>  
(Does not segfault with MHASH_SHA1)  
  
Apache 1.3.27   
mod_ssl 2.8.11   
PHP 4.3.0RC3   
glibc 2.2.25-40   
gcc-2.96-112   
mhash 0.8.17 (static)   
   
php ./configure:   
 ./configure --prefix=/usr --exec-prefix=/usr  
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc  
--datadir=/usr/share --includedir=/usr/include  
--libdir=/usr/lib --libexecdir=/usr/libexec  
--localstatedir=/var --sharedstatedir=/usr/com  
--mandir=/usr/share/man --infodir=/usr/share/info  
--with-config-file-path=/etc --with-dom=/usr  
--with-exec-dir=/usr/bin --with-gettext  
--with-regex=system --with-layout=GNU  
--enable-magic-quotes --without-oci8 --with-mhash  
--with-imap=shared --with-openssl --with-imap-ssl  
--with-kerberos=/usr/kerberos --with-ldap=shared  
--with-mysql=shared,/usr --with-apxs=/usr/sbin/apxs  
--enable-debug --with-zlib  
   
Backtrace:   
Program received signal SIGSEGV, Segmentation fault.  
0x4207af66 in chunk_free () from /lib/i686/libc.so.6  
(gdb) bt  
#0  0x4207af66 in chunk_free () from /lib/i686/libc.so.6  
#1  0x4207ad14 in free () from /lib/i686/libc.so.6  
#2  0x4033795a in mhash_free (ptr=0x81ca550) at  
mhash.c:548  
#3  0x4070dace in zif_mhash (ht=2, return_value=0x81d20bc,  
this_ptr=0x0,  
return_value_used=1) at  
/usr/src/redhat/php-4.3.0RC3/ext/mhash/mhash.c:185  
#4  0x4080a65b in execute (op_array=0x81cd79c)  
at  
/usr/src/redhat/php-4.3.0RC3/Zend/zend_execute.c:1596  
#5  0x407f879c in zend_execute_scripts (type=8,  
retval=0x0, file_count=3)  
at /usr/src/redhat/php-4.3.0RC3/Zend/zend.c:864  
#6  0x407c106b in php_execute_script  
(primary_file=0xb6f0)  
at /usr/src/redhat/php-4.3.0RC3/main/main.c:1552  
#7  0x4080f63a in apache_php_module_main (r=0x808ced8,  
display_source_mode=0)  
at  
/usr/src/redhat/php-4.3.0RC3/sapi/apache/sapi_apache.c:55  
#8  0x40810504 in send_php (r=0x808ced8,  
display_source_mode=0,  
filename=0x808e9e0  
"/var/www/modesmail/admin/phpcrash.php")  
at  
/usr/src/redhat/php-4.3.0RC3/sapi/apache/mod_php4.c:556  
#9  0x40810571 in send_parsed_php (r=0x808ced8)  
at  
/usr/src/redhat/php-4.3.0RC3/sapi/apache/mod_php4.c:571  
#10 0x080547dd in ap_invoke_handler ()  
#11 0x0806769c in process_request_internal ()  
#12 0x08067713 in ap_process_request ()  
#13 0x0805f867 in child_main ()  
#14 0x0805fa0a in make_child ()  
#15 0x0805fb4d in startup_children ()  
#16 0x080601a0 in standalone_main ()  
#17 0x08060aa3 in main ()  
#18 0x42017589 in __libc_start_main () from  
/lib/i686/libc.so.6  
  




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

#21112 [Fbk->Bgs]: unexpected token AC_ADD_INCLUDE during configure with sqlanywhere

[derick]

 ID:   21112
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Bogus
 Bug Type: Compile Failure
 Operating System: linux
 PHP Version:  4.3.0RC3
 New Comment:

We do not support 3rd party extensions. They need to fix their module
as it just no longer compiles. Not a PHP problem -> bogus.

Derick


Previous Comments:


[2002-12-20 07:09:22] [EMAIL PROTECTED]

sqlanywhere from https://login.sybase.com/detail/1,6904,1019698,00.html



[2002-12-20 07:07:17] [EMAIL PROTECTED]

changed summary.



[2002-12-20 07:06:46] [EMAIL PROTECTED]

Where did you get that sqlanyware from?

Derick



[2002-12-20 07:05:04] [EMAIL PROTECTED]

I try to configure php-4.3.0RC3 with sqlanywhere support. I make it
like in previous versions of php 4.x:
cd ext
tar xzf ../../../dwn/sqlanywhere-1.0.1.tgz
cd sqlanywhere
touch *
cd ../..
./buildconf
using default Zend directory
buildconf: checking installation...
buildconf: autoconf version 2.13 (ok)
buildconf: automake version 1.4-p5 (ok)
buildconf: libtool version 1.4 (ok)
rebuilding configure
autoconf: Undefined macros:
***BUG in Autoconf--please report*** AC_ADD_INCLUDE
***BUG in Autoconf--please report*** AC_ADD_INCLUDE
***BUG in Autoconf--please report*** AC_ADD_LIBRARY_WITH_PATH
rebuilding main/php_config.h.in

and during configuration:
./configure --with-apxs=/usr/local/apache/bin/apxs --enable-EAPI \
--enable-track-vars --with-mysql=/usr/local/mysql --with-jpeg-dir
--with-t1lib \
--enable-calendar --enable-sysvsem --enable-sysvshm --enable-trans-sid
\
--with-zlib --enable-ftp --enable-yp --enable-memory-limit --with-gd \
--with-exec-dir --enable-sockets --enable-safe-mode \
--with-exec-dir=/usr/local/php/bin --with-pdflib=/usr/pdflib \
--with-imap --with-png-dir --with-gettext --enable-mbstring \
--with-openssl=/usr/openssl/ --with-config-file-path=/root/conf/ \
--with-ldap \
--with-sqlanywhere

checking for SQLAnywhere support... yes
./configure: line 66818: syntax error near unexpected token
`AC_ADD_INCLUDE($SQLANY_DIR/include)'
./configure: line 66818: `AC_ADD_INCLUDE($SQLANY_DIR/include)'






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

#21112 [Com]: unexpected token AC_ADD_INCLUDE during configure with sqlanywhere

[tnowak]

 ID:   21112
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Compile Failure
 Operating System: linux
 PHP Version:  4.3.0RC3
 New Comment:

sqlanywhere from https://login.sybase.com/detail/1,6904,1019698,00.html


Previous Comments:


[2002-12-20 07:07:17] [EMAIL PROTECTED]

changed summary.



[2002-12-20 07:06:46] [EMAIL PROTECTED]

Where did you get that sqlanyware from?

Derick



[2002-12-20 07:05:04] [EMAIL PROTECTED]

I try to configure php-4.3.0RC3 with sqlanywhere support. I make it
like in previous versions of php 4.x:
cd ext
tar xzf ../../../dwn/sqlanywhere-1.0.1.tgz
cd sqlanywhere
touch *
cd ../..
./buildconf
using default Zend directory
buildconf: checking installation...
buildconf: autoconf version 2.13 (ok)
buildconf: automake version 1.4-p5 (ok)
buildconf: libtool version 1.4 (ok)
rebuilding configure
autoconf: Undefined macros:
***BUG in Autoconf--please report*** AC_ADD_INCLUDE
***BUG in Autoconf--please report*** AC_ADD_INCLUDE
***BUG in Autoconf--please report*** AC_ADD_LIBRARY_WITH_PATH
rebuilding main/php_config.h.in

and during configuration:
./configure --with-apxs=/usr/local/apache/bin/apxs --enable-EAPI \
--enable-track-vars --with-mysql=/usr/local/mysql --with-jpeg-dir
--with-t1lib \
--enable-calendar --enable-sysvsem --enable-sysvshm --enable-trans-sid
\
--with-zlib --enable-ftp --enable-yp --enable-memory-limit --with-gd \
--with-exec-dir --enable-sockets --enable-safe-mode \
--with-exec-dir=/usr/local/php/bin --with-pdflib=/usr/pdflib \
--with-imap --with-png-dir --with-gettext --enable-mbstring \
--with-openssl=/usr/openssl/ --with-config-file-path=/root/conf/ \
--with-ldap \
--with-sqlanywhere

checking for SQLAnywhere support... yes
./configure: line 66818: syntax error near unexpected token
`AC_ADD_INCLUDE($SQLANY_DIR/include)'
./configure: line 66818: `AC_ADD_INCLUDE($SQLANY_DIR/include)'






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

#21112 [Opn->Fbk]: unexpected token AC_ADD_INCLUDE during configure with sqlanywhere

[derick]

 ID:   21112
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Compile Failure
 Operating System: linux
 PHP Version:  4.3.0RC3


Previous Comments:


[2002-12-20 07:07:17] [EMAIL PROTECTED]

changed summary.



[2002-12-20 07:06:46] [EMAIL PROTECTED]

Where did you get that sqlanyware from?

Derick



[2002-12-20 07:05:04] [EMAIL PROTECTED]

I try to configure php-4.3.0RC3 with sqlanywhere support. I make it
like in previous versions of php 4.x:
cd ext
tar xzf ../../../dwn/sqlanywhere-1.0.1.tgz
cd sqlanywhere
touch *
cd ../..
./buildconf
using default Zend directory
buildconf: checking installation...
buildconf: autoconf version 2.13 (ok)
buildconf: automake version 1.4-p5 (ok)
buildconf: libtool version 1.4 (ok)
rebuilding configure
autoconf: Undefined macros:
***BUG in Autoconf--please report*** AC_ADD_INCLUDE
***BUG in Autoconf--please report*** AC_ADD_INCLUDE
***BUG in Autoconf--please report*** AC_ADD_LIBRARY_WITH_PATH
rebuilding main/php_config.h.in

and during configuration:
./configure --with-apxs=/usr/local/apache/bin/apxs --enable-EAPI \
--enable-track-vars --with-mysql=/usr/local/mysql --with-jpeg-dir
--with-t1lib \
--enable-calendar --enable-sysvsem --enable-sysvshm --enable-trans-sid
\
--with-zlib --enable-ftp --enable-yp --enable-memory-limit --with-gd \
--with-exec-dir --enable-sockets --enable-safe-mode \
--with-exec-dir=/usr/local/php/bin --with-pdflib=/usr/pdflib \
--with-imap --with-png-dir --with-gettext --enable-mbstring \
--with-openssl=/usr/openssl/ --with-config-file-path=/root/conf/ \
--with-ldap \
--with-sqlanywhere

checking for SQLAnywhere support... yes
./configure: line 66818: syntax error near unexpected token
`AC_ADD_INCLUDE($SQLANY_DIR/include)'
./configure: line 66818: `AC_ADD_INCLUDE($SQLANY_DIR/include)'






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

#21112 [Fbk->Opn]: unexpected token AC_ADD_INCLUDE during configure with sqlanywhere

[tnowak]

 ID:   21112
 User updated by:  [EMAIL PROTECTED]
-Summary:  random error: open_basedir restriction in effect. File
   is in wrong directory
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: linux
 PHP Version:  4.3.0RC3
 New Comment:

changed summary.


Previous Comments:


[2002-12-20 07:06:46] [EMAIL PROTECTED]

Where did you get that sqlanyware from?

Derick



[2002-12-20 07:05:04] [EMAIL PROTECTED]

I try to configure php-4.3.0RC3 with sqlanywhere support. I make it
like in previous versions of php 4.x:
cd ext
tar xzf ../../../dwn/sqlanywhere-1.0.1.tgz
cd sqlanywhere
touch *
cd ../..
./buildconf
using default Zend directory
buildconf: checking installation...
buildconf: autoconf version 2.13 (ok)
buildconf: automake version 1.4-p5 (ok)
buildconf: libtool version 1.4 (ok)
rebuilding configure
autoconf: Undefined macros:
***BUG in Autoconf--please report*** AC_ADD_INCLUDE
***BUG in Autoconf--please report*** AC_ADD_INCLUDE
***BUG in Autoconf--please report*** AC_ADD_LIBRARY_WITH_PATH
rebuilding main/php_config.h.in

and during configuration:
./configure --with-apxs=/usr/local/apache/bin/apxs --enable-EAPI \
--enable-track-vars --with-mysql=/usr/local/mysql --with-jpeg-dir
--with-t1lib \
--enable-calendar --enable-sysvsem --enable-sysvshm --enable-trans-sid
\
--with-zlib --enable-ftp --enable-yp --enable-memory-limit --with-gd \
--with-exec-dir --enable-sockets --enable-safe-mode \
--with-exec-dir=/usr/local/php/bin --with-pdflib=/usr/pdflib \
--with-imap --with-png-dir --with-gettext --enable-mbstring \
--with-openssl=/usr/openssl/ --with-config-file-path=/root/conf/ \
--with-ldap \
--with-sqlanywhere

checking for SQLAnywhere support... yes
./configure: line 66818: syntax error near unexpected token
`AC_ADD_INCLUDE($SQLANY_DIR/include)'
./configure: line 66818: `AC_ADD_INCLUDE($SQLANY_DIR/include)'






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

#21112 [Opn->Fbk]: random error: open_basedir restriction in effect. File is in wrong directory

[derick]

 ID:   21112
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Compile Failure
 Operating System: linux
 PHP Version:  4.3.0RC3
 New Comment:

Where did you get that sqlanyware from?

Derick


Previous Comments:


[2002-12-20 07:05:04] [EMAIL PROTECTED]

I try to configure php-4.3.0RC3 with sqlanywhere support. I make it
like in previous versions of php 4.x:
cd ext
tar xzf ../../../dwn/sqlanywhere-1.0.1.tgz
cd sqlanywhere
touch *
cd ../..
./buildconf
using default Zend directory
buildconf: checking installation...
buildconf: autoconf version 2.13 (ok)
buildconf: automake version 1.4-p5 (ok)
buildconf: libtool version 1.4 (ok)
rebuilding configure
autoconf: Undefined macros:
***BUG in Autoconf--please report*** AC_ADD_INCLUDE
***BUG in Autoconf--please report*** AC_ADD_INCLUDE
***BUG in Autoconf--please report*** AC_ADD_LIBRARY_WITH_PATH
rebuilding main/php_config.h.in

and during configuration:
./configure --with-apxs=/usr/local/apache/bin/apxs --enable-EAPI \
--enable-track-vars --with-mysql=/usr/local/mysql --with-jpeg-dir
--with-t1lib \
--enable-calendar --enable-sysvsem --enable-sysvshm --enable-trans-sid
\
--with-zlib --enable-ftp --enable-yp --enable-memory-limit --with-gd \
--with-exec-dir --enable-sockets --enable-safe-mode \
--with-exec-dir=/usr/local/php/bin --with-pdflib=/usr/pdflib \
--with-imap --with-png-dir --with-gettext --enable-mbstring \
--with-openssl=/usr/openssl/ --with-config-file-path=/root/conf/ \
--with-ldap \
--with-sqlanywhere

checking for SQLAnywhere support... yes
./configure: line 66818: syntax error near unexpected token
`AC_ADD_INCLUDE($SQLANY_DIR/include)'
./configure: line 66818: `AC_ADD_INCLUDE($SQLANY_DIR/include)'






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

#21112 [NEW]: random error: open_basedir restriction in effect. File is in wrong directory

[tnowak]

From: [EMAIL PROTECTED]
Operating system: linux
PHP version:  4.3.0RC3
PHP Bug Type: Compile Failure
Bug description:  random error: open_basedir restriction in effect. File is in wrong 
directory

I try to configure php-4.3.0RC3 with sqlanywhere support. I make it like in
previous versions of php 4.x:
cd ext
tar xzf ../../../dwn/sqlanywhere-1.0.1.tgz
cd sqlanywhere
touch *
cd ../..
./buildconf
using default Zend directory
buildconf: checking installation...
buildconf: autoconf version 2.13 (ok)
buildconf: automake version 1.4-p5 (ok)
buildconf: libtool version 1.4 (ok)
rebuilding configure
autoconf: Undefined macros:
***BUG in Autoconf--please report*** AC_ADD_INCLUDE
***BUG in Autoconf--please report*** AC_ADD_INCLUDE
***BUG in Autoconf--please report*** AC_ADD_LIBRARY_WITH_PATH
rebuilding main/php_config.h.in

and during configuration:
./configure --with-apxs=/usr/local/apache/bin/apxs --enable-EAPI \
--enable-track-vars --with-mysql=/usr/local/mysql --with-jpeg-dir
--with-t1lib \
--enable-calendar --enable-sysvsem --enable-sysvshm --enable-trans-sid \
--with-zlib --enable-ftp --enable-yp --enable-memory-limit --with-gd \
--with-exec-dir --enable-sockets --enable-safe-mode \
--with-exec-dir=/usr/local/php/bin --with-pdflib=/usr/pdflib \
--with-imap --with-png-dir --with-gettext --enable-mbstring \
--with-openssl=/usr/openssl/ --with-config-file-path=/root/conf/ \
--with-ldap \
--with-sqlanywhere

checking for SQLAnywhere support... yes
./configure: line 66818: syntax error near unexpected token
`AC_ADD_INCLUDE($SQLANY_DIR/include)'
./configure: line 66818: `AC_ADD_INCLUDE($SQLANY_DIR/include)'


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

#21110 [Opn->Fbk]: session_start

[derick]

 ID:   21110
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Compile Warning
 Operating System: win2000 pro+Apache1.3.27
 PHP Version:  4.3.0RC3
 New Comment:

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.



Previous Comments:


[2002-12-20 06:12:52] [EMAIL PROTECTED]

An error at function of session_start for PHP 4.3.0RC3.




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

#21110 [NEW]: session_start

[nologic]

From: [EMAIL PROTECTED]
Operating system: win2000 pro+Apache1.3.27
PHP version:  4.3.0RC3
PHP Bug Type: Compile Warning
Bug description:  session_start

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

#21095 [Fbk->Opn]: symlink and chroot

[busia]

 ID:   21095
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Filesystem function related
 Operating System: Redhat 7.2
 PHP Version:  4.3.0RC3
 New Comment:

Yes I use php with thread safe enabled, I'm using Apache 2.0.43 with
worker MPM.


Previous Comments:


[2002-12-19 18:43:09] [EMAIL PROTECTED]

Are you using PHP with thread safety enabled?



[2002-12-19 06:11:44] [EMAIL PROTECTED]

if I use



the symlink that is created in /home/foo_alfa is 
bar -> /home/foo

ant not
bar -> ../foo

how expected

this is a problem because I use chroot jails for ftp and the file
became not accessible.

Andrea Busia





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

#21109 [Opn->Sus]: ftp_connect throws script error and halts execution

[derick]

 ID:   21109
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Suspended
 Bug Type: FTP related
 Operating System: linux debian
 PHP Version:  4.2.3
 New Comment:

Setting it to suspended then until you provide feedback.

Derick


Previous Comments:


[2002-12-20 05:51:13] [EMAIL PROTECTED]

this is a production machine so im not about to install rc's on it - as
for other computers i cant be bothered simply because i have one
deadline today and then dinner..

its all about christmas - and a merry one to you all :)

if you release 4.3 soon i'll test it on that, as far RC's go - maybe
when i get a testing box where i'm allowed to break stuff.



[2002-12-20 05:43:33] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip



[2002-12-20 05:33:55] [EMAIL PROTECTED]

$this->_connection = ftp_connect($host);
if (!$this->_connection) {
trigger_error('FTP Connection to '.$host.'
failed.',E_USER_ERROR);
}
$this->_login = ftp_login($this->_connection,$user,$pass);
if (!$this->_login) {
trigger_error('FTP Login to '.$user.'@'.$host.'
failed.',E_USER_ERROR);
}
$this->_passive = ftp_pasv($this->_connection,$passive);
$this->_systype = ftp_systype($this->_connection);

- this is the code for my connect function inside a ftp class, and it
should be valid according to documentation provided, and i really cant
complain

i have everything routed trough error handlers, but every once in a
while i get a scripting error (ughm, i dont know if that is the correct
term) which basially halts the script and doesnt go trough error
handlers

the error message displayed is:

"connect: Connection timed out"

this could/should be changed to E_WARNING or E_NOTICE from this
critical error kinda thing.




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

#21109 [Fbk->Opn]: ftp_connect throws script error and halts execution

[tit . petric]

 ID:   21109
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: FTP related
 Operating System: linux debian
 PHP Version:  4.2.3
 New Comment:

this is a production machine so im not about to install rc's on it - as
for other computers i cant be bothered simply because i have one
deadline today and then dinner..

its all about christmas - and a merry one to you all :)

if you release 4.3 soon i'll test it on that, as far RC's go - maybe
when i get a testing box where i'm allowed to break stuff.


Previous Comments:


[2002-12-20 05:43:33] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip



[2002-12-20 05:33:55] [EMAIL PROTECTED]

$this->_connection = ftp_connect($host);
if (!$this->_connection) {
trigger_error('FTP Connection to '.$host.'
failed.',E_USER_ERROR);
}
$this->_login = ftp_login($this->_connection,$user,$pass);
if (!$this->_login) {
trigger_error('FTP Login to '.$user.'@'.$host.'
failed.',E_USER_ERROR);
}
$this->_passive = ftp_pasv($this->_connection,$passive);
$this->_systype = ftp_systype($this->_connection);

- this is the code for my connect function inside a ftp class, and it
should be valid according to documentation provided, and i really cant
complain

i have everything routed trough error handlers, but every once in a
while i get a scripting error (ughm, i dont know if that is the correct
term) which basially halts the script and doesnt go trough error
handlers

the error message displayed is:

"connect: Connection timed out"

this could/should be changed to E_WARNING or E_NOTICE from this
critical error kinda thing.




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

#21109 [Opn->Fbk]: ftp_connect throws script error and halts execution

[derick]

 ID:   21109
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: FTP related
 Operating System: linux debian
 PHP Version:  4.2.3
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip


Previous Comments:


[2002-12-20 05:33:55] [EMAIL PROTECTED]

$this->_connection = ftp_connect($host);
if (!$this->_connection) {
trigger_error('FTP Connection to '.$host.'
failed.',E_USER_ERROR);
}
$this->_login = ftp_login($this->_connection,$user,$pass);
if (!$this->_login) {
trigger_error('FTP Login to '.$user.'@'.$host.'
failed.',E_USER_ERROR);
}
$this->_passive = ftp_pasv($this->_connection,$passive);
$this->_systype = ftp_systype($this->_connection);

- this is the code for my connect function inside a ftp class, and it
should be valid according to documentation provided, and i really cant
complain

i have everything routed trough error handlers, but every once in a
while i get a scripting error (ughm, i dont know if that is the correct
term) which basially halts the script and doesnt go trough error
handlers

the error message displayed is:

"connect: Connection timed out"

this could/should be changed to E_WARNING or E_NOTICE from this
critical error kinda thing.




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

#21109 [NEW]: ftp_connect throws script error and halts execution

[tit . petric]

From: [EMAIL PROTECTED]
Operating system: linux debian
PHP version:  4.2.3
PHP Bug Type: FTP related
Bug description:  ftp_connect throws script error and halts execution

$this->_connection = ftp_connect($host);
if (!$this->_connection) {
trigger_error('FTP Connection to '.$host.'
failed.',E_USER_ERROR);
}
$this->_login = ftp_login($this->_connection,$user,$pass);
if (!$this->_login) {
trigger_error('FTP Login to '.$user.'@'.$host.'
failed.',E_USER_ERROR);
}
$this->_passive = ftp_pasv($this->_connection,$passive);
$this->_systype = ftp_systype($this->_connection);

- this is the code for my connect function inside a ftp class, and it
should be valid according to documentation provided, and i really cant
complain

i have everything routed trough error handlers, but every once in a while
i get a scripting error (ughm, i dont know if that is the correct term)
which basially halts the script and doesnt go trough error handlers

the error message displayed is:

"connect: Connection timed out"

this could/should be changed to E_WARNING or E_NOTICE from this critical
error kinda thing.
-- 
Edit bug report at http://bugs.php.net/?id=21109&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21109&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=21109&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=21109&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21109&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=21109&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21109&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=21109&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21109&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21109&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=21109&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21109&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=21109&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=21109&r=isapi

#21108 [Opn->Bgs]: ?: evaluates to copy of object

[derick]

 ID:   21108
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: Windows 98
 PHP Version:  4.2.3
 New Comment:

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the existing bug instead.

Thank you for your interest in PHP.




Previous Comments:


[2002-12-20 04:53:05] [EMAIL PROTECTED]

Since I do not know the internals of PHP, it's probably best to just
give an example:

$a = 11;

function &f()  {
return TRUE ? $GLOBALS['a'] : $GLOBALS['a'];
}

function &g()  {
return $GLOBALS['a'];
}

$b =& f();
$b = 12;
echo $a."";
$c =& g();
$c = 13;
echo $a;

-
output: 1113
expected output: 1213

Thanks for fixing this,
Cheers,
Rai





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

#21108 [NEW]: ?: evaluates to copy of object

[RNova]

From: [EMAIL PROTECTED]
Operating system: Windows 98
PHP version:  4.2.3
PHP Bug Type: Scripting Engine problem
Bug description:  ?: evaluates to copy of object

Since I do not know the internals of PHP, it's probably best to just give
an example:

$a = 11;

function &f()  {
return TRUE ? $GLOBALS['a'] : $GLOBALS['a'];
}

function &g()  {
return $GLOBALS['a'];
}

$b =& f();
$b = 12;
echo $a."";
$c =& g();
$c = 13;
echo $a;

-
output: 1113
expected output: 1213

Thanks for fixing this,
Cheers,
Rai

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

#20968 [Bgs->]: Session rewriter misses a case

[yohgaki]

 ID:   20968
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Won\'t fix
 Bug Type: Session related
 Operating System: Windows 2000
 PHP Version:  4.2.3
 New Comment:

"Won't fix" would be better for searching these things.


Previous Comments:


[2002-12-13 08:05:01] [EMAIL PROTECTED]

It is intentional



[2002-12-13 08:03:15] [EMAIL PROTECTED]

The javascript is generated code from a product by a dll.  I have no
access to modifying the html.

The only workaround I have is to not use trans sid.  But then clients
without cookies cannot access it.  

I do not believe this behavior is intentional.

Charles



[2002-12-13 03:02:01] [EMAIL PROTECTED]

Use single quotes in your script. Not a bug.




[2002-12-12 12:29:44] [EMAIL PROTECTED]

The cvs behaves differently but still the same error

str += "";

It doesnt put quotes around the reptoc but it still puts bad quotes
around the type="hidden" and others.

Charles



[2002-12-12 11:49:02] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip



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/20968

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

#21106 [Opn->Fbk]: browser crash from redirect command in function

[derick]

 ID:   21106
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: win98/pws/ie5
 PHP Version:  4.2.3
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip




Previous Comments:


[2002-12-20 03:38:20] [EMAIL PROTECTED]

reopened



[2002-12-20 03:21:34] [EMAIL PROTECTED]

closed



[2002-12-20 03:09:21] [EMAIL PROTECTED]

when using this  code from within a function 
===
$location='http://'.$_SERVER["HTTP_HOST"].$_SERVER['PHP_SELF'].'?cmd=frm
'.$temp.'&msg='.urlencode($return_msg);
header("Location:".$location);
=

results in the following repeatable crash message from IE5

PHP caused a stack fault in module PHP4TS.DLL at 015f:100b1f96.
Registers:
EAX=00762d90 CS=015f EIP=100b1f96 EFLGS=00010212
EBX=06fcceb0 SS=0167 ESP=00541f54 EBP=06fcd32c
ECX=00792c20 DS=0167 ESI=00761fa0 FS=5a37
EDX=0007 ES=0167 EDI=0001 GS=
Bytes at CS:EIP:
53 55 56 57 8b bc 24 90 04 00 00 33 db 89 5c 24 
Stack dump:
      

      


screen display is

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

--end of screen display--



[2002-12-20 03:06:06] [EMAIL PROTECTED]


when using this  code from within a function 
===
$location='http://'.$_SERVER["HTTP_HOST"].$_SERVER['PHP_SELF'].'?cmd=frm'.$temp.'&msg='.urlencode($return_msg);

header("Location:".$location);
=

results in the following repeatable crash message from IE5


PHP caused a stack fault in module PHP4TS.DLL at 015f:100b1f96.
Registers:
EAX=00762d90 CS=015f EIP=100b1f96 EFLGS=00010212
EBX=06fcceb0 SS=0167 ESP=00541f54 EBP=06fcd32c
ECX=00792c20 DS=0167 ESI=00761fa0 FS=5a37
EDX=0007 ES=0167 EDI=0001 GS=
Bytes at CS:EIP:
53 55 56 57 8b bc 24 90 04 00 00 33 db 89 5c 24 
Stack dump:
       
       



screen display is

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

--end of screen display--




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

#21106 [Csd->Opn]: browser crash from redirect command in function

[webber123456]

 ID:   21106
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Closed
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: win98/pws/ie5
 PHP Version:  4.2.3
 New Comment:

reopened


Previous Comments:


[2002-12-20 03:21:34] [EMAIL PROTECTED]

closed



[2002-12-20 03:09:21] [EMAIL PROTECTED]

when using this  code from within a function 
===
$location='http://'.$_SERVER["HTTP_HOST"].$_SERVER['PHP_SELF'].'?cmd=frm
'.$temp.'&msg='.urlencode($return_msg);
header("Location:".$location);
=

results in the following repeatable crash message from IE5

PHP caused a stack fault in module PHP4TS.DLL at 015f:100b1f96.
Registers:
EAX=00762d90 CS=015f EIP=100b1f96 EFLGS=00010212
EBX=06fcceb0 SS=0167 ESP=00541f54 EBP=06fcd32c
ECX=00792c20 DS=0167 ESI=00761fa0 FS=5a37
EDX=0007 ES=0167 EDI=0001 GS=
Bytes at CS:EIP:
53 55 56 57 8b bc 24 90 04 00 00 33 db 89 5c 24 
Stack dump:
      

      


screen display is

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

--end of screen display--



[2002-12-20 03:06:06] [EMAIL PROTECTED]


when using this  code from within a function 
===
$location='http://'.$_SERVER["HTTP_HOST"].$_SERVER['PHP_SELF'].'?cmd=frm'.$temp.'&msg='.urlencode($return_msg);

header("Location:".$location);
=

results in the following repeatable crash message from IE5


PHP caused a stack fault in module PHP4TS.DLL at 015f:100b1f96.
Registers:
EAX=00762d90 CS=015f EIP=100b1f96 EFLGS=00010212
EBX=06fcceb0 SS=0167 ESP=00541f54 EBP=06fcd32c
ECX=00792c20 DS=0167 ESI=00761fa0 FS=5a37
EDX=0007 ES=0167 EDI=0001 GS=
Bytes at CS:EIP:
53 55 56 57 8b bc 24 90 04 00 00 33 db 89 5c 24 
Stack dump:
       
       



screen display is

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

--end of screen display--




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

#21106 [Opn->Csd]: browser crash from redirect command in function

[webber123456]

 ID:   21106
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Reproducible crash
 Operating System: win98/pws/ie5
 PHP Version:  4.2.3
 New Comment:

closed


Previous Comments:


[2002-12-20 03:09:21] [EMAIL PROTECTED]

when using this  code from within a function 
===
$location='http://'.$_SERVER["HTTP_HOST"].$_SERVER['PHP_SELF'].'?cmd=frm
'.$temp.'&msg='.urlencode($return_msg);
header("Location:".$location);
=

results in the following repeatable crash message from IE5

PHP caused a stack fault in module PHP4TS.DLL at 015f:100b1f96.
Registers:
EAX=00762d90 CS=015f EIP=100b1f96 EFLGS=00010212
EBX=06fcceb0 SS=0167 ESP=00541f54 EBP=06fcd32c
ECX=00792c20 DS=0167 ESI=00761fa0 FS=5a37
EDX=0007 ES=0167 EDI=0001 GS=
Bytes at CS:EIP:
53 55 56 57 8b bc 24 90 04 00 00 33 db 89 5c 24 
Stack dump:
      

      


screen display is

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

--end of screen display--



[2002-12-20 03:06:06] [EMAIL PROTECTED]


when using this  code from within a function 
===
$location='http://'.$_SERVER["HTTP_HOST"].$_SERVER['PHP_SELF'].'?cmd=frm'.$temp.'&msg='.urlencode($return_msg);

header("Location:".$location);
=

results in the following repeatable crash message from IE5


PHP caused a stack fault in module PHP4TS.DLL at 015f:100b1f96.
Registers:
EAX=00762d90 CS=015f EIP=100b1f96 EFLGS=00010212
EBX=06fcceb0 SS=0167 ESP=00541f54 EBP=06fcd32c
ECX=00792c20 DS=0167 ESI=00761fa0 FS=5a37
EDX=0007 ES=0167 EDI=0001 GS=
Bytes at CS:EIP:
53 55 56 57 8b bc 24 90 04 00 00 33 db 89 5c 24 
Stack dump:
       
       



screen display is

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

--end of screen display--




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

#21106 [Opn]: browser crash from redirect command in function

[webber123456]

 ID:   21106
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: win98/pws/ie5
 PHP Version:  4.2.3
 New Comment:

when using this  code from within a function 
===
$location='http://'.$_SERVER["HTTP_HOST"].$_SERVER['PHP_SELF'].'?cmd=frm
'.$temp.'&msg='.urlencode($return_msg);
header("Location:".$location);
=

results in the following repeatable crash message from IE5

PHP caused a stack fault in module PHP4TS.DLL at 015f:100b1f96.
Registers:
EAX=00762d90 CS=015f EIP=100b1f96 EFLGS=00010212
EBX=06fcceb0 SS=0167 ESP=00541f54 EBP=06fcd32c
ECX=00792c20 DS=0167 ESI=00761fa0 FS=5a37
EDX=0007 ES=0167 EDI=0001 GS=
Bytes at CS:EIP:
53 55 56 57 8b bc 24 90 04 00 00 33 db 89 5c 24 
Stack dump:
      

      


screen display is

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

--end of screen display--


Previous Comments:


[2002-12-20 03:06:06] [EMAIL PROTECTED]


when using this  code from within a function 
===
$location='http://'.$_SERVER["HTTP_HOST"].$_SERVER['PHP_SELF'].'?cmd=frm'.$temp.'&msg='.urlencode($return_msg);

header("Location:".$location);
=

results in the following repeatable crash message from IE5


PHP caused a stack fault in module PHP4TS.DLL at 015f:100b1f96.
Registers:
EAX=00762d90 CS=015f EIP=100b1f96 EFLGS=00010212
EBX=06fcceb0 SS=0167 ESP=00541f54 EBP=06fcd32c
ECX=00792c20 DS=0167 ESI=00761fa0 FS=5a37
EDX=0007 ES=0167 EDI=0001 GS=
Bytes at CS:EIP:
53 55 56 57 8b bc 24 90 04 00 00 33 db 89 5c 24 
Stack dump:
       
       



screen display is

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

--end of screen display--




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

#21106 [NEW]: browser crash from redirect command in function

[webber123456]

From: [EMAIL PROTECTED]
Operating system: win98/pws/ie5
PHP version:  4.2.3
PHP Bug Type: Reproducible crash
Bug description:  browser crash from redirect command in function


when using this  code from within a function 
===
$location='http://'.$_SERVER["HTTP_HOST"].$_SERVER['PHP_SELF'].'?cmd=frm'.$temp.'&msg='.urlencode($return_msg);

header("Location:".$location);
=

results in the following repeatable crash message from IE5


PHP caused a stack fault in module PHP4TS.DLL at 015f:100b1f96.
Registers:
EAX=00762d90 CS=015f EIP=100b1f96 EFLGS=00010212
EBX=06fcceb0 SS=0167 ESP=00541f54 EBP=06fcd32c
ECX=00792c20 DS=0167 ESI=00761fa0 FS=5a37
EDX=0007 ES=0167 EDI=0001 GS=
Bytes at CS:EIP:
53 55 56 57 8b bc 24 90 04 00 00 33 db 89 5c 24 
Stack dump:
       
        


screen display is

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

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

#21065 [Com]: shell_exec seems not to work properly if result was false.

[dj-bj]

 ID:   21065
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Windows 2000 Server
 PHP Version:  4.2.3
 New Comment:

I installed this version using the old ini file - no errors execpt the
one reported.
Still, the result of shell_exec is not passed to the variable but
displayed on the page with added "

Content-type: text/html
X-Powered-By: PHP/4.4.0-dev

" after the error message.

In my script i control some nt services and therefor i tell shell_exec
to execute net start / net stop. If a service has already been started
and i attempt to start it again it returns the error "More help is
available by typing NET HELPMSG 2182." like in DOS Shell on Windows but
this error not passed to the variable.


Previous Comments:


[2002-12-19 19:15:53] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip





[2002-12-17 06:41:55] [EMAIL PROTECTED]

Running PHP 4.2.3 on Windows 2000 Server shell_exec works fine and
passes its output to the variable when the result of the executed
command is true. 
However, if the command fails and the DOS-shell returns an error the
result is no longer availiable in the variable but is passed directly
to the page.




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

#20529 [Bgs->Opn]: Bad subject line when using JIS encoding

[malek]

 ID:   20529
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Open
 Bug Type: mbstring related
 Operating System: red hat Linux 6.2
 PHP Version:  4.3.0RC1
 New Comment:

Hi Again,
  I think actually this does, the problem is to do with the way the php
mail function handles the subject line, I don't think it is actually a
problem with the mb_string hence I originally posted to Mail. 

This bug was not apparent in any other version of php, of which we have
around 6 test servers and 5 main servers running. 

It has only started with the 4.3.0 versions. 

If you look closely you can will see that this also does not occur in
the message body of the email, just the header. It seams that the mail
function can no longer handle '' character for some reason and
replaces it with a blank space. 

In fact I do have a way around this which I am actively using. 
mb_language ( "ja");
mb_send_mail(  ) which does not seem to be affected by this bug.

I do not mind using mb_send_mail() from now on if this issue is not
going to be fixed but this is kinda annoying when you don't necessary
always want to write Japanese emails or use the base64 encoded subject
lines. 

Just to note, I know for a fact several big companies using php in
Japan are going to start experiencing this problem very soon if the
decide to upgrade to 4.3. As from what I have seen they all tend to use
the mail function which has worked very well up to now rather that the
mb_send_mail function.

Anyway thank for you help and time,
sorry that it could not be fixed,
thanks,
Malek

p.s. if after reading this you still think it not a bug please change
back to bogus, just put on open now to make sure you get this mail.


Previous Comments:


[2002-12-20 02:14:06] [EMAIL PROTECTED]

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

You should prepare mime headers(subject line, etc.) to be encoded in
base64. Please ask this kind of question at [EMAIL PROTECTED] or
[EMAIL PROTECTED](if you can understand Japanese) which you can
subscribe at the appropriate pages of http://www.php.net/ or
http://www.php.gr.jp/ respectively, before posting this kind of
question to the bug database.





[2002-12-20 01:58:47] [EMAIL PROTECTED]

Hi,
 Have just tried using the latest snapshot and the bug is still there,
no change,
thanks,
Malek



[2002-12-19 22:57:50] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip





[2002-11-20 19:19:33] [EMAIL PROTECTED]

Hi Ya,
  Basically I am using
PHP 4.3.0RC1 (but I have also noticed the same thing with PHP 4.3.0PR2
)
on Red Hat Linux 6.2
with Sendmail 8.9.3

I am basically trying to send a mail in Japanese,
I first encode the text into JIS then simply send as normal,
i.e.
".$subjectja,"Content-Type:
text/plain;charset=\"iso-2022-jp\"\nContent-Transfer-Encoding: 7bit");
// mail
?>
however the subject line does not appear correctly. On viewing the
email source I noticed that it is seemingly removing some characters
from the Subject line JIS,
Subject:  $B%G%$%j!<%l%]!<%H (B <--- this is the resulting subject
line which is broken

test->$B%G%$%j!<%l%]!<%H(B<--- this is the email body which works
fine

 $B%G%$%j!<%l%]!<%H (B
$B%G%$%j!<%l%]!<%H(B

slightly different. Also if you take out the "test->" on the body part
the body of the email will not to work.

p.s. there is no problems with 4.0,4.1 or 4.2

thanks,
Malek




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

#20937 [Com]: PHP binary randomly consumes from 300kb to 5Mb

[hchinhwa]

 ID:   20937
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: *General Issues
 Operating System: Win2000, MacOS
 PHP Version:  4.2.3
 New Comment:

Hi,

I am facing similar problem. There are multiple PHP binaries running in
Windows (viewed from Windows Task Manager). The PHP server went dead
when more requests came in when I was just running a simple index.php
file. This file consisted of 7 include statments. Each included file
did not even exceed more than 30 LOC in plain HTML.

Wrong PHP installation?


Previous Comments:


[2002-12-11 12:04:35] [EMAIL PROTECTED]

No single line of code is executed, the script only does an include so
the problem is indeed the size of the PHP binary which varies from 2 to
5mb without a reason.



[2002-12-11 11:57:03] [EMAIL PROTECTED]

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

The memory usage will depend on the amount of data retrieved from the
SQL server.



[2002-12-11 09:05:16] [EMAIL PROTECTED]

You need advanced tools to test this: Windows Task Manager!

The PHP binary randomly cunsumes up to 5Mb of memory for no clear
reason. When the whole application is loaded this leads
to binaries from 2Mb to 12Mb.
The script includes PEAR::DB (DB.php), connects to the database (MySQL)
and dies.
Zillions of users are complainin about exhausted memory problems and we
have to make them change the maximum memory size for PHP scripts in
their php.ini settings.




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

#20529 [Opn->Bgs]: Bad subject line when using JIS encoding

[moriyoshi]

 ID:   20529
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: mbstring related
 Operating System: red hat Linux 6.2
 PHP Version:  4.3.0RC1
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

You should prepare mime headers(subject line, etc.) to be encoded in
base64. Please ask this kind of question at [EMAIL PROTECTED] or
[EMAIL PROTECTED](if you can understand Japanese) which you can
subscribe at the appropriate pages of http://www.php.net/ or
http://www.php.gr.jp/ respectively, before posting this kind of
question to the bug database.




Previous Comments:


[2002-12-20 01:58:47] [EMAIL PROTECTED]

Hi,
 Have just tried using the latest snapshot and the bug is still there,
no change,
thanks,
Malek



[2002-12-19 22:57:50] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip





[2002-11-20 19:19:33] [EMAIL PROTECTED]

Hi Ya,
  Basically I am using
PHP 4.3.0RC1 (but I have also noticed the same thing with PHP 4.3.0PR2
)
on Red Hat Linux 6.2
with Sendmail 8.9.3

I am basically trying to send a mail in Japanese,
I first encode the text into JIS then simply send as normal,
i.e.
".$subjectja,"Content-Type:
text/plain;charset=\"iso-2022-jp\"\nContent-Transfer-Encoding: 7bit");
// mail
?>
however the subject line does not appear correctly. On viewing the
email source I noticed that it is seemingly removing some characters
from the Subject line JIS,
Subject:  $B%G%$%j!<%l%]!<%H (B <--- this is the resulting subject
line which is broken

test->$B%G%$%j!<%l%]!<%H(B<--- this is the email body which works
fine

 $B%G%$%j!<%l%]!<%H (B
$B%G%$%j!<%l%]!<%H(B

slightly different. Also if you take out the "test->" on the body part
the body of the email will not to work.

p.s. there is no problems with 4.0,4.1 or 4.2

thanks,
Malek




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

#20987 [Com]: Problem with curl_setopt and client certificates

[daniel]

 ID:   20987
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: cURL related
 Operating System: Redhat Linux 7.2
 PHP Version:  4.3.0RC3
 New Comment:

Basicly, dnorrell wants this little patch applied and I think (s)he is
right:


diff -u -r1.2 interface.c
--- interface.c 14 Nov 2002 11:41:24 -  1.2
+++ interface.c 20 Dec 2002 08:07:16 -
@@ -794,6 +794,7 @@
case CURLOPT_USERAGENT:
case CURLOPT_FTPPORT:
case CURLOPT_COOKIE:
+   case CURLOPT_SSLCERT:
case CURLOPT_COOKIEFILE:
case CURLOPT_REFERER:
case CURLOPT_INTERFACE:


Previous Comments:


[2002-12-13 04:48:17] [EMAIL PROTECTED]

It appears that if you try to specify a client certficate for an HTTPS
connection using the CURLOPT_SSLCERT option, nothing gets set. An
example would be:

curl_setopt($ch, CURLOPT_SSLCERT, "client.pem");

A quick look at the PHP source seems to indicate that this option is
omitted from the curl_setopt function. If I add it it works fine.




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