#39653 [Fbk->Opn]: BDB-4.5 include, older BDB linked

2006-11-28 Thread vesely at tana dot it 
 ID:   39653
 User updated by:  vesely at tana dot it
 Reported By:  vesely at tana dot it
-Status:   Feedback
+Status:   Open
 Bug Type: DBM/DBA related
 Operating System: unix
 PHP Version:  4.4.4
 New Comment:

I bet that patch works, but it's difficult for me to test it.
I've done the following, which works:
--- configure%2006-11-28 10:53:19.851446000 +0100
+++ configure2006-11-28 10:53:19.981427000 +0100
@@ -26166,7 +26166,7 @@
  fi
done
-  for LIB in db-4.3 db-4.2 db-4.1 db-4.0 db-4 db4 db; do
+  for LIB in db-4.5 db-4.3 db-4.2 db-4.1 db-4.0 db-4 db4 db; do
if test -f $THIS_PREFIX/lib/lib$LIB.a -o -f
$THIS_PREFIX/lib/lib$LIB.$SHLIB_SUFFIX_NAME; then

I guess that's about the same as the patch you produced,
from an end-user perspective - thanx


Previous Comments:


[2006-11-28 10:01:26] [EMAIL PROTECTED]

Please apply this patch:
http://tony2001.phpclub.net/dev/tmp/bug39653.diff (patch -p0 <
bug39653.diff).
After applying it, please run the following commands:
make clean
rm configure
./buildconf
./config.nice
make
Please check if it works after that.



[2006-11-28 01:06:45] vesely at tana dot it

To reproduce the bug you must install BDB-4.5 (probably 4.4 also fails)
over an existing BDB-4.1 (probably 4.3, 4.2, or 4.0 would also reproduce
the crash). Then configure

  --with-db4
or, say,
  --with-db4=/usr/local/lib/libdb-4.5

I still had libdb-4.1, for programs compiled before I upgraded.
However, only the most recent db.h remained installed. After
libdb-4.1's db_create, the virtual function bdb->set_errcall appears to
be NULL to programs referring to bdb-4.5's included structure
definition.

The configure script won't complain, the compilations looks fine, but
libphp4.la mentions libdb-4.1. That's because the configure scripts
only tests for versions 4.3 and below.


The patch (broken on pasting) only fixes a compiler warning. It's not
much relevant until the errcall will not be actually called (presumably
after a runtime error). Even then, only the error reporting will be
broken, not the functionality.



[2006-11-28 00:40:11] [EMAIL PROTECTED]

Elaborate please on how to reproduce it, what is this patch supposed to
fix and why.

>Please add tests for db-4.5 and newer: the compilation >does not fail
if by chance an older db-4.1 (in my case) existed.
This likely means you're messing different headers and libraries, which
is in no way PHP problem.

----------------

[2006-11-28 00:30:08] vesely at tana dot it

Description:

Please add tests for db-4.5 and newer: the compilation does not fail if
by chance an older db-4.1 (in my case) existed.
However, when calling dbd->set_errcall the process crashes with pc=0.
That happens because the DB structure changed and newer elements have
been inserted in the middle of it, rather than at the bottom.

Hopefully, one day BDB will come with an official m4 macro. I already
asked them...

One more thing, the errcall has different arguments in 4.5:
--- ./ext/dba/dba_db4.c%2006-11-27 23:54:31.021697000 +0100
+++ ./ext/dba/dba_db4.c2006-11-27 23:54:31.031696000 +0100
@@ -35,7 +35,7 @@
#include 
#endif

-static void php_dba_db4_errcall_fcn(const char *errpfx, char *msg)
+static void php_dba_db4_errcall_fcn(const DB_ENV*env, const char
*errpfx, const char *msg)
{
TSRMLS_FETCH();
 


Reproduce code:
---
This was trapped in the test suite. (Since the program aborted its
output was different.)


Expected result:

database handler: db4
3NYNYY
Content String 2
Content 2 replaced
Read during write: not allowed
Content 2 replaced 2nd time
The 6th value
array(3) {
 ["key number 6"]=>
 string(13) "The 6th value"
 ["key2"]=>
 string(27) "Content 2 replaced 2nd time"
 ["key5"]=>
 string(23) "The last content string"
}


Actual result:
--
database handler: db4





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

#39653 [Fbk->Opn]: BDB-4.5 include, older BDB linked

2006-11-27 Thread vesely at tana dot it 
 ID:   39653
 User updated by:  vesely at tana dot it
 Reported By:  vesely at tana dot it
-Status:   Feedback
+Status:   Open
-Bug Type: Unknown/Other Function
+Bug Type: DBM/DBA related
 Operating System: unix
 PHP Version:  4.4.4
 New Comment:

To reproduce the bug you must install BDB-4.5 (probably 4.4 also fails)
over an existing BDB-4.1 (probably 4.3, 4.2, or 4.0 would also reproduce
the crash). Then configure

  --with-db4
or, say,
  --with-db4=/usr/local/lib/libdb-4.5

I still had libdb-4.1, for programs compiled before I upgraded.
However, only the most recent db.h remained installed. After
libdb-4.1's db_create, the virtual function bdb->set_errcall appears to
be NULL to programs referring to bdb-4.5's included structure
definition.

The configure script won't complain, the compilations looks fine, but
libphp4.la mentions libdb-4.1. That's because the configure scripts
only tests for versions 4.3 and below.


The patch (broken on pasting) only fixes a compiler warning. It's not
much relevant until the errcall will not be actually called (presumably
after a runtime error). Even then, only the error reporting will be
broken, not the functionality.


Previous Comments:


[2006-11-28 00:40:11] [EMAIL PROTECTED]

Elaborate please on how to reproduce it, what is this patch supposed to
fix and why.

>Please add tests for db-4.5 and newer: the compilation >does not fail
if by chance an older db-4.1 (in my case) existed.
This likely means you're messing different headers and libraries, which
is in no way PHP problem.

--------

[2006-11-28 00:30:08] vesely at tana dot it

Description:

Please add tests for db-4.5 and newer: the compilation does not fail if
by chance an older db-4.1 (in my case) existed.
However, when calling dbd->set_errcall the process crashes with pc=0.
That happens because the DB structure changed and newer elements have
been inserted in the middle of it, rather than at the bottom.

Hopefully, one day BDB will come with an official m4 macro. I already
asked them...

One more thing, the errcall has different arguments in 4.5:
--- ./ext/dba/dba_db4.c%2006-11-27 23:54:31.021697000 +0100
+++ ./ext/dba/dba_db4.c2006-11-27 23:54:31.031696000 +0100
@@ -35,7 +35,7 @@
#include 
#endif

-static void php_dba_db4_errcall_fcn(const char *errpfx, char *msg)
+static void php_dba_db4_errcall_fcn(const DB_ENV*env, const char
*errpfx, const char *msg)
{
TSRMLS_FETCH();
 


Reproduce code:
---
This was trapped in the test suite. (Since the program aborted its
output was different.)


Expected result:

database handler: db4
3NYNYY
Content String 2
Content 2 replaced
Read during write: not allowed
Content 2 replaced 2nd time
The 6th value
array(3) {
 ["key number 6"]=>
 string(13) "The 6th value"
 ["key2"]=>
 string(27) "Content 2 replaced 2nd time"
 ["key5"]=>
 string(23) "The last content string"
}


Actual result:
--
database handler: db4





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

#39653 [NEW]: BDB-4.5 include, older BDB linked

2006-11-27 Thread vesely at tana dot it 
From: vesely at tana dot it
Operating system: unix
PHP version:  4.4.4
PHP Bug Type: Reproducible crash
Bug description:  BDB-4.5 include, older BDB linked

Description:

Please add tests for db-4.5 and newer: the compilation does not fail if by
chance an older db-4.1 (in my case) existed.
However, when calling dbd->set_errcall the process crashes with pc=0. That
happens because the DB structure changed and newer elements have been
inserted in the middle of it, rather than at the bottom.

Hopefully, one day BDB will come with an official m4 macro. I already
asked them...

One more thing, the errcall has different arguments in 4.5:
--- ./ext/dba/dba_db4.c%2006-11-27 23:54:31.021697000 +0100
+++ ./ext/dba/dba_db4.c2006-11-27 23:54:31.031696000 +0100
@@ -35,7 +35,7 @@
#include 
#endif

-static void php_dba_db4_errcall_fcn(const char *errpfx, char *msg)
+static void php_dba_db4_errcall_fcn(const DB_ENV*env, const char *errpfx,
const char *msg)
{
TSRMLS_FETCH();
 


Reproduce code:
---
This was trapped in the test suite. (Since the program aborted its output
was different.)


Expected result:

database handler: db4
3NYNYY
Content String 2
Content 2 replaced
Read during write: not allowed
Content 2 replaced 2nd time
The 6th value
array(3) {
 ["key number 6"]=>
 string(13) "The 6th value"
 ["key2"]=>
 string(27) "Content 2 replaced 2nd time"
 ["key5"]=>
 string(23) "The last content string"
}


Actual result:
--
database handler: db4

-- 
Edit bug report at http://bugs.php.net/?id=39653&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=39653&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=39653&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=39653&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39653&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=39653&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=39653&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39653&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39653&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=39653&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39653&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=39653&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=39653&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39653&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=39653&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39653&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39653&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=39653&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=39653&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=39653&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39653&r=mysqlcfg

#33828 [WFx]: processes opened with proc_open may freeze on fatal error

2005-07-23 Thread vesely at tana dot it 
 ID:   33828
 User updated by:  vesely at tana dot it
 Reported By:  vesely at tana dot it
 Status:   Wont fix
 Bug Type: Unknown/Other Function
 Operating System: Unix
 PHP Version:  4.4.0
 New Comment:

Perhaps you may check the following code, please?

When migrating to 5.x we will have to review c'tors
anyway, so it seems fine to me. Strange as it looks,
I wouldn't bet about unwanted side effects. If you
feel like recommending it, I'll post a pointer to this
bug in the relevant manual page.

Workaround code:

open();
   }

   function open() {
  $this->proc = proc_open("cat -",
 array(
0 => array("pipe", "r"),
1 => array("file", "/dev/null", "w"),
2 => array("file", "/dev/null", "w")),
 $this->pipes);
  $GLOBALS[uniqid("my_class_proc_open_")] = $this->proc;
   }
}

$p = new my_class();
$p->open();

printf("%s proc hangs on fatal PHP error?\n",
   is_resource($p->proc) ? "Open" : "Not open");
non_existing_function("does not hang: just aborts");
// not reached...
?>


Previous Comments:


[2005-07-22 23:15:22] [EMAIL PROTECTED]

It's fixed in 5.x, but I don't think that the fix will get into 4.4.0
ever, as it was just a small part of exec()/proc_open() overall
rewrite.
So I'd say you have to live with that (or use 5.x instead, this is a
perfect reason to start using it).




[2005-07-22 20:33:13] vesely at tana dot it

Description:

If the proc_open was inside a class object,
then on a fatal error the child process
is not killed. (Both CLI and Apache.)

That behaviour makes it difficult to develop
scripts based on classes using proc_open.

If the $proc is not inside a class object,
I obtained a similar freezing doing $proc = 0
before the fatal error.


Reproduce code:
---
proc = proc_open("cat -",
 array(
0 => array("pipe", "r"),
1 => array("file", "/dev/null", "w"),
2 => array("file", "/dev/null", "w")),
 $this->pipes); 
   }
}

$p = new my_class();
printf("%s proc hangs on fatal PHP error?\n",
   is_resource($p->proc) ? "Open" : "Not open");
non_existing_function("hangs if open");
// not reached...
?>







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

#33828 [NEW]: processes opened with proc_open may freeze on fatal error

2005-07-22 Thread vesely at tana dot it 
From: vesely at tana dot it
Operating system: Unix
PHP version:  4.4.0
PHP Bug Type: Reproducible crash
Bug description:  processes opened with proc_open may freeze on fatal error

Description:

If the proc_open was inside a class object,
then on a fatal error the child process
is not killed. (Both CLI and Apache.)

That behaviour makes it difficult to develop
scripts based on classes using proc_open.

If the $proc is not inside a class object,
I obtained a similar freezing doing $proc = 0
before the fatal error.


Reproduce code:
---
proc = proc_open("cat -",
 array(
0 => array("pipe", "r"),
1 => array("file", "/dev/null", "w"),
2 => array("file", "/dev/null", "w")),
 $this->pipes); 
   }
}

$p = new my_class();
printf("%s proc hangs on fatal PHP error?\n",
   is_resource($p->proc) ? "Open" : "Not open");
non_existing_function("hangs if open");
// not reached...
?>



-- 
Edit bug report at http://bugs.php.net/?id=33828&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=33828&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=33828&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=33828&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33828&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33828&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=33828&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=33828&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=33828&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33828&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=33828&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=33828&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=33828&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33828&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=33828&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33828&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=33828&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33828&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=33828&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=33828&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=33828&r=mysqlcfg

#33781 [Opn]: add "stream_set_timeout" support for pipes

2005-07-20 Thread vesely at tana dot it 
 ID:   33781
 User updated by:  vesely at tana dot it
 Reported By:  vesely at tana dot it
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: Unix
 PHP Version:  4.4.0
 New Comment:

I have a couple of notes on that example. The function
attempts to fread 8Kbytes, whilst a positive response from
stream_select only guarantees that 1 byte can be read w/o
blocking. Further, 60 secs is really eons.

I'm using this:

   function guarded_fgets($pipes)
   {
  $line = "";
  $time = 2;
  $c = "c";
  while ($time >= 0 && ord($c) != 10)
  {
 $read = array($pipes[1]);
 while (!feof($read[0]) &&
($n = stream_select($read, $w = NULL, $e = NULL, $time))
!== FALSE &&
$n > 0 &&
strlen($c = fgetc($read[0])) > 0 &&
ord($c) != 10)
   $line .= $c;
 --$time;
  }

  if (ord($c) != 10)
  {
 // error handling
  }

  return $line;
   }


Previous Comments:


[2005-07-20 14:54:54] [EMAIL PROTECTED]

The simple solution is to NOT use fgets() when you're on a deadline,
because of the greedy read semantic.

Use fread() instead, in conjunction with stream_select() (which is what
is used internally to implement the timeout).

Here's an example from our test suite:

function system_with_timeout($commandline)
{
$data = "";

$proc = proc_open($commandline, array(
0 => array('pipe', 'r'),
1 => array('pipe', 'w'),
2 => array('pipe', 'w')
), $pipes, null, null, array("suppress_errors" => true));

if (!$proc)
return false;

fclose($pipes[0]);

while (true) {
/* hide errors from interrupted syscalls */
$r = $pipes;
$w = null;
$e = null;
$n = @stream_select($r, $w, $e, 60);

if ($n === 0) {
/* timed out */
$data .= "\n ** ERROR: process timed out **\n";
proc_terminate($proc);
return $data;
} else if ($n > 0) {
$line = fread($pipes[1], 8192);
if (strlen($line) == 0) {
/* EOF */
break;
}
$data .= $line;
}
}
$stat = proc_get_status($proc);
if ($stat['signaled']) {
$data .= "\nTermsig=".$stat['stopsig'];
}
$code = proc_close($proc);
return $data;
}



[2005-07-20 09:40:21] vesely at tana dot it

Description:

When using the Apache module it is not possible
to use pcntl_alarm (why?). OTOH stream_set_timeout
does not work on the "pipe" in descriptorspec.

Of course, if the program really doesn't know _if_
there is any data to read, it should use stream_select
and fgetc in a loop. Frequently enough, the program
knows what it is doing and wants to sleep on fgets
until data is available on the pipe. If anything goes
wrong here, the two processes may hang waiting for
each other. Meanwhile, the user angrily reloads the
page knocking out yet another Apache's child...

"NEEDED: a timeout for stdout pipe, otherwise a fgets on
$pipes[1] can lag forever...)" has been for years in
http://www.php.net/manual/en/function.proc-open.php#20866

The global script timeout is quite hard to manage from
an included function. stream_select and fgets is good
but is not bullet-proof. A request for a timer already
exists (bug #9676), hence I guess I should ask for some
"guarded-pipe" where the select-fgetc loop is coded in C
using a time limit that can be set via stream_set_timeout.
Is that cool?






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

#33781 [NEW]: Alarm needed for proc_open pipes

2005-07-20 Thread vesely at tana dot it 
From: vesely at tana dot it
Operating system: Unix
PHP version:  4.4.0
PHP Bug Type: Feature/Change Request
Bug description:  Alarm needed for proc_open pipes

Description:

When using the Apache module it is not possible
to use pcntl_alarm (why?). OTOH stream_set_timeout
does not work on the "pipe" in descriptorspec.

Of course, if the program really doesn't know _if_
there is any data to read, it should use stream_select
and fgetc in a loop. Frequently enough, the program
knows what it is doing and wants to sleep on fgets
until data is available on the pipe. If anything goes
wrong here, the two processes may hang waiting for
each other. Meanwhile, the user angrily reloads the
page knocking out yet another Apache's child...

"NEEDED: a timeout for stdout pipe, otherwise a fgets on
$pipes[1] can lag forever...)" has been for years in
http://www.php.net/manual/en/function.proc-open.php#20866

The global script timeout is quite hard to manage from
an included function. stream_select and fgets is good
but is not bullet-proof. A request for a timer already
exists (bug #9676), hence I guess I should ask for some
"guarded-pipe" where the select-fgetc loop is coded in C
using a time limit that can be set via stream_set_timeout.
Is that cool?


-- 
Edit bug report at http://bugs.php.net/?id=33781&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=33781&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=33781&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=33781&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33781&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33781&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=33781&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=33781&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=33781&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33781&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=33781&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=33781&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=33781&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33781&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=33781&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33781&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=33781&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33781&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=33781&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=33781&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=33781&r=mysqlcfg

#27018 [Bgs]: urlencode should not do non-ascii characters

2004-01-24 Thread vesely at tana dot it 
 ID:   27018
 User updated by:  vesely at tana dot it
 Reported By:  vesely at tana dot it
 Status:   Bogus
 Bug Type: URL related
 Operating System: Irrelevant
 PHP Version:  Irrelevant
 New Comment:

iconv_mime_encode would be nearly fine for me
(until I don't use multy-byte) except that it
writes "Subject: blah" a la SMTP. I will have
to remove the leading "Subject: ", [raw]urlencode
the "blah" and append the result to the url,
after an "&Subject=". And will I trust using
substr($iconverted,9) or should I use a regex
to match the colon?

Please... :-) Nasty as national chars in headers are,
if at least they could be used correctly life might
be better. And since much html is created using
PHP and url-functions, a well documented dedicated
function may improve overall conformancy. In facts
many programmers --I for one-- are not sure what is
the correct encoding of a mailto tags among the three
on my test page.

BTW, why configure doesn't include iconv automatically?

Thanks
Ale


Previous Comments:


[2004-01-23 17:05:18] [EMAIL PROTECTED]

Use mb_encode_mimeheader() / iconv_mime_encode()

http://www.php.net/mb_encode_mimeheader
http://www.php.net/iconv_mime_encode.

just RTFM.



----------------

[2004-01-23 07:21:09] vesely at tana dot it

Description:

Hi,
is it possible to reopen bug 6173?

Briefly, national characters are not field
separators in any url scheme. If they are
urlencoded, they may be traslated the wrong
way by users with incompatible code tables.

The answer to bug 6173 cites rfc1738, which is 10
years old and also says that

"   A mailto URL takes the form:
"  mailto:

The bug is relevant for urls like
mailto:[EMAIL PROTECTED]
that already violate rfc1738.

I prepared a test page in
http://www.tana.it/urlencoded.html

The problem could be solved by adding a function to
support rfc1342, that must be called before rawurlencode.

Thank you for your patience
Ale

Reproduce code:
---
rawurlencode("è is not e")

Expected result:

%3D%3Fiso-8859-1%3FQ%3F%3DE8%3F%3D%20is%20not%20e

Actual result:
--
%E8%20is%20not%20e





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

#27018 [NEW]: urlencode should not do non-ascii characters

2004-01-23 Thread vesely at tana dot it 
From: vesely at tana dot it
Operating system: Irrelevant
PHP version:  Irrelevant
PHP Bug Type: URL related
Bug description:  urlencode should not do non-ascii characters

Description:

Hi,
is it possible to reopen bug 6173?

Briefly, national characters are not field
separators in any url scheme. If they are
urlencoded, they may be traslated the wrong
way by users with incompatible code tables.

The answer to bug 6173 cites rfc1738, which is 10
years old and also says that

"   A mailto URL takes the form:
"  mailto:

The bug is relevant for urls like
mailto:[EMAIL PROTECTED]
that already violate rfc1738.

I prepared a test page in
http://www.tana.it/urlencoded.html

The problem could be solved by adding a function to
support rfc1342, that must be called before rawurlencode.

Thank you for your patience
Ale

Reproduce code:
---
rawurlencode("è is not e")

Expected result:

%3D%3Fiso-8859-1%3FQ%3F%3DE8%3F%3D%20is%20not%20e

Actual result:
--
%E8%20is%20not%20e

-- 
Edit bug report at http://bugs.php.net/?id=27018&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=27018&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=27018&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=27018&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=27018&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27018&r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=27018&r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=27018&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27018&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=27018&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27018&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27018&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=27018&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27018&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=27018&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=27018&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27018&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27018&r=float

#26305 [NEW]: Segmentation Fault when endlessly including the same file

2003-11-18 Thread vesely at tana dot it 
From: vesely at tana dot it
Operating system: Solaris
PHP version:  4.3.4
PHP Bug Type: Reproducible crash
Bug description:  Segmentation Fault when endlessly including the same file 

Description:

Yes, I've been so stupid to do that.
(I thought ../ could be relative to the file
being included rather than the file being executed.)

However, triggering a segmentation fault isn't the
nicest way out of that. How does php deal with VERY
big sources?

Reproduce code:
---
somedir/subdir/example.php:

   require("../common.inc");

somedir/common.inc:

   require("../common.inc");


Expected result:

Fatal: out of memory

Actual result:
--
Segmentation Fault (core dumped)

-- 
Edit bug report at http://bugs.php.net/?id=26305&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=26305&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=26305&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=26305&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=26305&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26305&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=26305&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26305&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=26305&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26305&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26305&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=26305&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26305&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=26305&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=26305&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26305&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26305&r=float

#26304 [Opn]: Unexpected data loss when opening dba file

2003-11-18 Thread vesely at tana dot it 
 ID:   26304
 User updated by:  vesely at tana dot it
 Reported By:  vesely at tana dot it
 Status:   Open
 Bug Type: DBM/DBA related
 Operating System: Solaris
 PHP Version:  4.3.4
 New Comment:

Also, that correction around line 67 in dba_db4.c
(DBA_OPEN_FUNC) is bogus: if stat returns 0 you want
to say DB_UNKNOWN, since you cannot say it is DB_BTREE
when it was created by some other program.

To reproduce the bug you should create a DB with a different
type, e.g. in C if you just include db.h and then call
the dbm_open compatibility layer. The Sleepycat message
will then say "call implies an access method which is
inconsistent with previous calls."


Previous Comments:


[2003-11-18 12:09:46] vesely at tana dot it

Description:

Opening a file in 'c' mode (see example below)
truncates the file!! The docs say '"c" for read/write
access and database creation if it doesn't currently exist.'

I cannot understand that comment at line 658 in
ext/dba/dba.c, as it seems to imply that truncating
the database is necessary for locking it (??).

Reproduce code:
---
dba_open("important_data.db", "c", "db4");

Expected result:

open db (create if doesn't exist)

Actual result:
--
truncated db





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

#26304 [NEW]: Unexpected data loss when opening dba file

2003-11-18 Thread vesely at tana dot it 
From: vesely at tana dot it
Operating system: Solaris
PHP version:  4.3.4
PHP Bug Type: DBM/DBA related
Bug description:  Unexpected data loss when opening dba file

Description:

Opening a file in 'c' mode (see example below)
truncates the file!! The docs say '"c" for read/write
access and database creation if it doesn't currently exist.'

I cannot understand that comment at line 658 in
ext/dba/dba.c, as it seems to imply that truncating
the database is necessary for locking it (??).

Reproduce code:
---
dba_open("important_data.db", "c", "db4");

Expected result:

open db (create if doesn't exist)

Actual result:
--
truncated db

-- 
Edit bug report at http://bugs.php.net/?id=26304&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=26304&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=26304&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=26304&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=26304&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26304&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=26304&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26304&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=26304&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26304&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26304&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=26304&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26304&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=26304&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=26304&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26304&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26304&r=float

#25745 [Fbk->Opn]: Character type functions fail on negative chars

2003-10-03 Thread vesely at tana dot it 
 ID:  25745
 User updated by: vesely at tana dot it
 Reported By: vesely at tana dot it
-Status:  Feedback
+Status:  Open
 Bug Type:*Languages/Translation
 PHP Version: 4.3.2
 Assigned To: moriyoshi
 New Comment:

I got 817 compiling with gcc 3.2 on sun sparc solaris8,
depending on the __ctype table, results may vary.


Previous Comments:


[2003-10-03 11:46:02] [EMAIL PROTECTED]

Hmm, please put the correct OS name you confirmed the bug with.





[2003-10-03 11:43:40] [EMAIL PROTECTED]

Yet another casting problem :)



[2003-10-03 11:41:03] vesely at tana dot it

Description:

The upper half of the codes are badly reported, e.g
ctype_alpha("è") returns true even under C locale.

As a workaround one may call ctype_alpha(ord("è")),
which works correctly.

Alternatively, the following patch fixes that:

--- php-4.3.2/ext/ctype/ctype.c%2003-10-03 13:13:46.870457000
+0200
+++ php-4.3.2/ext/ctype/ctype.c 2003-10-03 13:13:46.880455000 +0200
@@ -100,7 +100,7 @@
RETURN_BOOL(iswhat(Z_LVAL_P(c))); \
case IS_STRING: \
{ \
-   char *p; \
+   unsigned char *p; \
int n, len; \
p=Z_STRVAL_P(c); \
len = Z_STRLEN_P(c); \



Ciao
Ale
---
below I list character type functions for
easing bug searches

ctype_alnum ctype_alpha ctype_cntrl ctype_digit
ctype_graph ctype_lower ctype_print ctype_punct
ctype_space ctype_upper ctype_xdigit 

Reproduce code:
---


Expected result:

0

Actual result:
--
817





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

#25745 [NEW]: Character type functions fail on negative chars

2003-10-03 Thread vesely at tana dot it 
From: vesely at tana dot it
Operating system: 
PHP version:  4.3.2
PHP Bug Type: *Languages/Translation
Bug description:  Character type functions fail on negative chars

Description:

The upper half of the codes are badly reported, e.g
ctype_alpha("è") returns true even under C locale.

As a workaround one may call ctype_alpha(ord("è")),
which works correctly.

Alternatively, the following patch fixes that:

--- php-4.3.2/ext/ctype/ctype.c%2003-10-03 13:13:46.870457000
+0200
+++ php-4.3.2/ext/ctype/ctype.c 2003-10-03 13:13:46.880455000 +0200
@@ -100,7 +100,7 @@
RETURN_BOOL(iswhat(Z_LVAL_P(c))); \
case IS_STRING: \
{ \
-   char *p; \
+   unsigned char *p; \
int n, len; \
p=Z_STRVAL_P(c); \
len = Z_STRLEN_P(c); \



Ciao
Ale
---
below I list character type functions for
easing bug searches

ctype_alnum ctype_alpha ctype_cntrl ctype_digit
ctype_graph ctype_lower ctype_print ctype_punct
ctype_space ctype_upper ctype_xdigit 

Reproduce code:
---


Expected result:

0

Actual result:
--
817

-- 
Edit bug report at http://bugs.php.net/?id=25745&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=25745&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=25745&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=25745&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=25745&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25745&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=25745&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25745&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=25745&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25745&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25745&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=25745&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25745&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=25745&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=25745&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25745&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=25745&r=float

#18648 [Com]: Single entry form POST gives incorrect variable content

2003-07-20 Thread vesely at tana dot it 
 ID:   18648
 Comment by:   vesely at tana dot it
 Reported By:  ms at ecs dot soton dot ac dot uk
 Status:   Bogus
 Bug Type: Apache2 related
 Operating System: All
 PHP Version:  5CVS-2003-01-29 (dev) / 4CVS-20020121 (stable)
 New Comment:

For completeness, I'd like to mention that
the setting suggested

> [4 Feb 3:05pm CST] [EMAIL PROTECTED] wrote
>
> # good (d)
> AddType application/x-httpd-php .php

works owlright except that if a request for xxx.php
arrives w/o extension like

   GET /xxx HTTP/1.1
   Accept: text/*

Apache responds "406 Not Acceptable" and lists
xxx.php as a possible alternative of MIME type
application/x-httpd-php. If the "Options MultiViews"
is in effect, Apache serves xxx.php when that is
the shortest (or only) choice.

Adding a "MultiViewsMatch Handlers Filter" or
renaming to xxx.html.php don't help. I think we need
to use PHP as a filter; 4.3.2 mentions having set a
new handler but doesn't say this bug is closed.

BTW, what's the reason why we "Do not use Apache 2.0
and PHP in a production environment neither on Unix
nor on Windows."? (That warning comes from
http://www.php.net/manual/en/install.apache2.php)


Previous Comments:


[2003-06-16 15:26:12] sbeam at syxyz dot net

yes my bad, the directives were in /etc/httpd/conf.d/php.conf
I am new to Apache 2.0 and did not expect them there. Thanks.



[2003-06-12 10:11:30] CJ dot Hammond at t-online dot de

Please look in the /etc/httpd/conf.d/ folder. There might be a php.conf
file (or likewise, as all files get included). Any Directive within
will have the same effect as directives in /etc/httpd/conf/httpd.conf
!!!

Later,
/jochen



[2003-06-02 20:45:56] sbeam at syxyz dot net

NOT fixed on default RedHat 9.0 setup (Apache 2.0.40 and PHP 4.2.2):
same form.html and test.php as original poster on 30 Jul 2002. Same
exact result. Also there is NO SetOutputFilter or other stuff in
httpd.conf, and adding "AddInputFilter PHP .php" has no effect. RedHat
does not currently provide any higher version of PHP binaries. Only
option is to recompile?



[2003-05-04 08:36:37] anrdaemon at mtu-net dot ru

Thanx to [EMAIL PROTECTED]
/me stupid...

AddInputFilter PHP .php

solves all problems.



[2003-03-05 07:32:56] jorton at redhat dot com

The default configuration in Red Hat Linux has only the 
section.  This bug appears to occur if the "AddType x-httpd-php .php"
is added *as well* as the  section.

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=76559



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

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

#22657 [Bgs]: Weak parsing in rfc1867.c

2003-03-12 Thread vesely at tana dot it 
 ID:   22657
 User updated by:  vesely at tana dot it
 Reported By:  vesely at tana dot it
 Status:   Bogus
 Bug Type: HTTP related
 Operating System: Any
 PHP Version:  4.3.0
 New Comment:

> buf_begin can be NULL, no DOS possible -> BOGUS1

it is not initialized to NULL, it is never tested for not
being NULL, and around line 232, function fill_buffer

  if (self->bytes_in_buffer > 0 && self->buf_begin != self->buffer) {
memmove(self->buffer, self->buf_begin, self->bytes_in_buffer);
}

should grant the job will be done. Why do you say
it can be NULL? If I have some more time next week
I'll try and prepare a proof of concept.

>  searching for ',' is correct this works around a bug
>  in some IE version -> BOGUS2

Ha ha! I should have guessed it... :-)


Previous Comments:


[2003-03-12 16:06:33] [EMAIL PROTECTED]

buf_begin can be NULL, no DOS possible -> BOGUS1

searching for ',' is correct this works around a bug
in some IE version -> BOGUS2

----------------

[2003-03-12 03:44:37] vesely at tana dot it

Hi,
watch out rfc1867.c around line 342, in function
next_line() there is (was?) the following code:

if (ptr) {
/* ... */   
} else {
/* ... */

line[self->bufsize] = 0;
self->buf_begin = ptr;/* <=== */
self->bytes_in_buffer = 0;
}

ptr is obviously NULL, buf_begin should never be NULL
or the program may crash. So this is a potential
vulnerability for DOS attackers who submit long lines.

Since you're there, would you mind to check why at line
721, in the rfc1867_post_handler function, there is

boundary_end = strchr(boundary, ',');

Shouldn't it be ';' (semicolon) rather than ',' (comma)?
(Just wandering)




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

#22657 [NEW]: Weak parsing in rfc1867.c

2003-03-12 Thread vesely at tana dot it 
From: vesely at tana dot it
Operating system: Any
PHP version:  4.3.0
PHP Bug Type: HTTP related
Bug description:  Weak parsing in rfc1867.c

Hi,
watch out rfc1867.c around line 342, in function
next_line() there is (was?) the following code:

if (ptr) {
/* ... */   
} else {
/* ... */

line[self->bufsize] = 0;
self->buf_begin = ptr;/* <=== */
self->bytes_in_buffer = 0;
}

ptr is obviously NULL, buf_begin should never be NULL
or the program may crash. So this is a potential
vulnerability for DOS attackers who submit long lines.

Since you're there, would you mind to check why at line
721, in the rfc1867_post_handler function, there is

boundary_end = strchr(boundary, ',');

Shouldn't it be ';' (semicolon) rather than ',' (comma)?
(Just wandering)
-- 
Edit bug report at http://bugs.php.net/?id=22657&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22657&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22657&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22657&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22657&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22657&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22657&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22657&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22657&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22657&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22657&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22657&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22657&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22657&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22657&r=gnused