#40213 [Fbk-Opn]: easter_date() returns wrong timestamp if ...

2007-03-06 Thread oliver dot block at lycos dot de 
 ID:   40213
 User updated by:  oliver dot block at lycos dot de
 Reported By:  oliver dot block at lycos dot de
-Status:   Feedback
+Status:   Open
 Bug Type: Calendar related
 Operating System: Linux
 PHP Version:  5.2.1RC3
 New Comment:

But it saves a lot of time and work. - I've feared that it may not
convince you.:)


Previous Comments:


[2007-03-06 12:11:37] [EMAIL PROTECTED]

Naaah, calling mktime() with call_user_function() is just a hack, not a
solution.
I've said we probably need to rewrite it from scratch and merge it into
ext/date to use ext/date _internal_ functions directly, not through the
user API.



[2007-01-29 22:03:11] oliver dot block at lycos dot de

I modified some of the testfiles from the former archives, because of
wrong test results. It happens that easter date and DST shift occur on
the same day. If so, date('Y-m-d H:i:s', easter_date($year)) will
return a time portion of 01:00:00 and not 00:00:00

You find the archive here:

http://www.block-online.eu/phptests/tests_easter_date.tar.gz



[2007-01-25 21:04:02] oliver dot block at lycos dot de

You will find the diff file here now:

http://mitglied.lycos.de/oblock/php/easter.c.diff.gz



[2007-01-25 20:20:22] [EMAIL PROTECTED]

404 not found..



[2007-01-25 20:16:28] oliver dot block at lycos dot de

Let's start with the first function.:) 
You will find a diff file here:

http://mitglied.lycos.de/oblock/easter.c.diff

I also created more test files

http://mitglied.lycos.de/oblock/easter_date_test.tar.gz

Please check everthing and decide if you want to include it.



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

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

#40213 [Opn]: easter_date() returns wrong timestamp if ...

2007-01-29 Thread oliver dot block at lycos dot de 
 ID:   40213
 User updated by:  oliver dot block at lycos dot de
 Reported By:  oliver dot block at lycos dot de
 Status:   Open
 Bug Type: Calendar related
 Operating System: Linux
 PHP Version:  5.2.1RC3
 New Comment:

I modified some of the testfiles from the former archives, because of
wrong test results. It happens that easter date and DST shift occur on
the same day. If so, date('Y-m-d H:i:s', easter_date($year)) will
return a time portion of 01:00:00 and not 00:00:00

You find the archive here:

http://www.block-online.eu/phptests/tests_easter_date.tar.gz


Previous Comments:


[2007-01-25 21:04:02] oliver dot block at lycos dot de

You will find the diff file here now:

http://mitglied.lycos.de/oblock/php/easter.c.diff.gz



[2007-01-25 20:20:22] [EMAIL PROTECTED]

404 not found..



[2007-01-25 20:16:28] oliver dot block at lycos dot de

Let's start with the first function.:) 
You will find a diff file here:

http://mitglied.lycos.de/oblock/easter.c.diff

I also created more test files

http://mitglied.lycos.de/oblock/easter_date_test.tar.gz

Please check everthing and decide if you want to include it.



[2007-01-24 13:54:13] [EMAIL PROTECTED]

Basically we need to rewrite ext/calendar from scratch (to use ext/date
types and utilities) and probably merge it into ext/date.
Volunteers are welcome.



[2007-01-23 19:29:22] oliver dot block at lycos dot de

Description:

If the timezone is set to another value than the system timezone,
easter_date() will return a timestamp with respect to the systems local
time, not with respect to the set timezone. 
That leads to wrong results of date/time function, e.g. date() which
handle the (default) timestamp that is set my php
(ini_set('date.timezone', 'UTC') or date_default_timezone_set() ).

The problem occurs, if the timezone set by php is east of the
system's timezone, if e.g. php timezone is 'UTC' and systems timezone
is 'Europe/Berlin'

Reproduce code:
---
/ext/calendar/tests/easter_date.phpt


Expected result:

the test

/ext/calendar/tests/easter_date.phpt

should pass.

Actual result:
--
the test

/ext/calendar/tests/easter_date.phpt

will fail.





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

#40213 [Opn]: easter_date() returns wrong timestamp if ...

2007-01-25 Thread oliver dot block at lycos dot de 
 ID:   40213
 User updated by:  oliver dot block at lycos dot de
 Reported By:  oliver dot block at lycos dot de
 Status:   Open
 Bug Type: Calendar related
 Operating System: Linux
 PHP Version:  5.2.1RC3
 New Comment:

Let's start with the first function.:) 
You will find a diff file here:

http://mitglied.lycos.de/oblock/easter.c.diff

I also created more test files

http://mitglied.lycos.de/oblock/easter_date_test.tar.gz

Please check everthing and decide if you want to include it.


Previous Comments:


[2007-01-24 13:54:13] [EMAIL PROTECTED]

Basically we need to rewrite ext/calendar from scratch (to use ext/date
types and utilities) and probably merge it into ext/date.
Volunteers are welcome.



[2007-01-23 19:29:22] oliver dot block at lycos dot de

Description:

If the timezone is set to another value than the system timezone,
easter_date() will return a timestamp with respect to the systems local
time, not with respect to the set timezone. 
That leads to wrong results of date/time function, e.g. date() which
handle the (default) timestamp that is set my php
(ini_set('date.timezone', 'UTC') or date_default_timezone_set() ).

The problem occurs, if the timezone set by php is east of the
system's timezone, if e.g. php timezone is 'UTC' and systems timezone
is 'Europe/Berlin'

Reproduce code:
---
/ext/calendar/tests/easter_date.phpt


Expected result:

the test

/ext/calendar/tests/easter_date.phpt

should pass.

Actual result:
--
the test

/ext/calendar/tests/easter_date.phpt

will fail.





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

#40213 [Opn]: easter_date() returns wrong timestamp if ...

2007-01-25 Thread oliver dot block at lycos dot de 
 ID:   40213
 User updated by:  oliver dot block at lycos dot de
 Reported By:  oliver dot block at lycos dot de
 Status:   Open
 Bug Type: Calendar related
 Operating System: Linux
 PHP Version:  5.2.1RC3
 New Comment:

You will find the diff file here now:

http://mitglied.lycos.de/oblock/php/easter.c.diff.gz


Previous Comments:


[2007-01-25 20:20:22] [EMAIL PROTECTED]

404 not found..



[2007-01-25 20:16:28] oliver dot block at lycos dot de

Let's start with the first function.:) 
You will find a diff file here:

http://mitglied.lycos.de/oblock/easter.c.diff

I also created more test files

http://mitglied.lycos.de/oblock/easter_date_test.tar.gz

Please check everthing and decide if you want to include it.



[2007-01-24 13:54:13] [EMAIL PROTECTED]

Basically we need to rewrite ext/calendar from scratch (to use ext/date
types and utilities) and probably merge it into ext/date.
Volunteers are welcome.



[2007-01-23 19:29:22] oliver dot block at lycos dot de

Description:

If the timezone is set to another value than the system timezone,
easter_date() will return a timestamp with respect to the systems local
time, not with respect to the set timezone. 
That leads to wrong results of date/time function, e.g. date() which
handle the (default) timestamp that is set my php
(ini_set('date.timezone', 'UTC') or date_default_timezone_set() ).

The problem occurs, if the timezone set by php is east of the
system's timezone, if e.g. php timezone is 'UTC' and systems timezone
is 'Europe/Berlin'

Reproduce code:
---
/ext/calendar/tests/easter_date.phpt


Expected result:

the test

/ext/calendar/tests/easter_date.phpt

should pass.

Actual result:
--
the test

/ext/calendar/tests/easter_date.phpt

will fail.





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

#40213 [NEW]: easter_date() returns wrong timestamp if ...

2007-01-23 Thread oliver dot block at lycos dot de 
From: oliver dot block at lycos dot de
Operating system: Linux
PHP version:  5.2.1RC3
PHP Bug Type: Calendar related
Bug description:  easter_date() returns wrong timestamp if ...

Description:

If the timezone is set to another value than the system timezone,
easter_date() will return a timestamp with respect to the systems local
time, not with respect to the set timezone. 
That leads to wrong results of date/time function, e.g. date() which
handle the (default) timestamp that is set my php
(ini_set('date.timezone', 'UTC') or date_default_timezone_set() ).

The problem occurs, if the timezone set by php is east of the system's
timezone, if e.g. php timezone is 'UTC' and systems timezone is
'Europe/Berlin'

Reproduce code:
---
/ext/calendar/tests/easter_date.phpt


Expected result:

the test

/ext/calendar/tests/easter_date.phpt

should pass.

Actual result:
--
the test

/ext/calendar/tests/easter_date.phpt

will fail.

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

#37159 [Bgs-Csd]: imap_fetchstructure returns wrong encoding

2006-04-27 Thread oliver dot block at lycos dot de 
 ID:   37159
 User updated by:  oliver dot block at lycos dot de
 Reported By:  oliver dot block at lycos dot de
-Status:   Bogus
+Status:   Closed
 Bug Type: IMAP related
 Operating System: Unix
 PHP Version:  5.1.2
 New Comment:

With strong support of Mark Crispin, author of the 
c-client library, it turned out, that the bug is neither 
in php nor in the c-client library.  
The cause of the behavior of the imap_fetchstructure 
function is a bug in the imap server of my ISP.  
It does not return imapr4 complaint data. 
 
Best Regards, 
 
Oliver Block


Previous Comments:


[2006-04-22 15:12:33] oliver dot block at lycos dot de

workaround: 
 
check the header for existing 
 
Content-Transfer-Encoding: 
 
field if you receive an object returning encoding equal to 
5. 
 
If there is none, a 7bit encoding should be assumed 
(according to RFC2045). 
 
Best Regards, 
 
Oliver



[2006-04-22 13:19:49] oliver dot block at lycos dot de

Thanks for your response. I'll do that. 
Yes, it is a bug. I am sure.



[2006-04-22 08:11:54] [EMAIL PROTECTED]

This is what IMAP c-client returns to PHP and we can't fix or change it
in any way.
If you consider it a bug - please report to c-client developers.
Thanks.



[2006-04-21 22:35:12] oliver dot block at lycos dot de

Description:

applying imap_fetchstructure to a message return wrong encoding value,
if the message has NO Content-Encoding field.

Reproduce code:
---
$stream = imap_open($server, $username, $password);

$msg_struct = imap_fetchstructure($stream, $uid, FT_UID);

$encoding = $msg_struct-encoding;



Expected result:

If I apply this on a message with NO Content-Encoding field,
$encoding should be equal to 0 -- according to RFC2045, Sect. 6.1.


Actual result:
--
If I apply this code on a message with NO Content-Encoding field,
$encoding is equal to 5.





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

#37159 [Bgs]: imap_fetchstructure returns wrong encoding

2006-04-22 Thread oliver dot block at lycos dot de 
 ID:   37159
 User updated by:  oliver dot block at lycos dot de
 Reported By:  oliver dot block at lycos dot de
 Status:   Bogus
 Bug Type: IMAP related
 Operating System: Unix
 PHP Version:  5.1.2
 New Comment:

Thanks for your response. I'll do that. 
Yes, it is a bug. I am sure.


Previous Comments:


[2006-04-22 08:11:54] [EMAIL PROTECTED]

This is what IMAP c-client returns to PHP and we can't fix or change it
in any way.
If you consider it a bug - please report to c-client developers.
Thanks.



[2006-04-21 22:35:12] oliver dot block at lycos dot de

Description:

applying imap_fetchstructure to a message return wrong encoding value,
if the message has NO Content-Encoding field.

Reproduce code:
---
$stream = imap_open($server, $username, $password);

$msg_struct = imap_fetchstructure($stream, $uid, FT_UID);

$encoding = $msg_struct-encoding;



Expected result:

If I apply this on a message with NO Content-Encoding field,
$encoding should be equal to 0 -- according to RFC2045, Sect. 6.1.


Actual result:
--
If I apply this code on a message with NO Content-Encoding field,
$encoding is equal to 5.





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

#37159 [Bgs]: imap_fetchstructure returns wrong encoding

2006-04-22 Thread oliver dot block at lycos dot de 
 ID:   37159
 User updated by:  oliver dot block at lycos dot de
 Reported By:  oliver dot block at lycos dot de
 Status:   Bogus
 Bug Type: IMAP related
 Operating System: Unix
 PHP Version:  5.1.2
 New Comment:

workaround: 
 
check the header for existing 
 
Content-Transfer-Encoding: 
 
field if you receive an object returning encoding equal to 
5. 
 
If there is none, a 7bit encoding should be assumed 
(according to RFC2045). 
 
Best Regards, 
 
Oliver


Previous Comments:


[2006-04-22 13:19:49] oliver dot block at lycos dot de

Thanks for your response. I'll do that. 
Yes, it is a bug. I am sure.



[2006-04-22 08:11:54] [EMAIL PROTECTED]

This is what IMAP c-client returns to PHP and we can't fix or change it
in any way.
If you consider it a bug - please report to c-client developers.
Thanks.



[2006-04-21 22:35:12] oliver dot block at lycos dot de

Description:

applying imap_fetchstructure to a message return wrong encoding value,
if the message has NO Content-Encoding field.

Reproduce code:
---
$stream = imap_open($server, $username, $password);

$msg_struct = imap_fetchstructure($stream, $uid, FT_UID);

$encoding = $msg_struct-encoding;



Expected result:

If I apply this on a message with NO Content-Encoding field,
$encoding should be equal to 0 -- according to RFC2045, Sect. 6.1.


Actual result:
--
If I apply this code on a message with NO Content-Encoding field,
$encoding is equal to 5.





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

#37159 [NEW]: imap_fetchstructure returns wrong encoding

2006-04-21 Thread oliver dot block at lycos dot de 
From: oliver dot block at lycos dot de
Operating system: Unix
PHP version:  5.1.2
PHP Bug Type: IMAP related
Bug description:  imap_fetchstructure returns wrong encoding

Description:

applying imap_fetchstructure to a message return wrong encoding value, if
the message has NO Content-Encoding field.

Reproduce code:
---
$stream = imap_open($server, $username, $password);

$msg_struct = imap_fetchstructure($stream, $uid, FT_UID);

$encoding = $msg_struct-encoding;



Expected result:

If I apply this on a message with NO Content-Encoding field,
$encoding should be equal to 0 -- according to RFC2045, Sect. 6.1.


Actual result:
--
If I apply this code on a message with NO Content-Encoding field,
$encoding is equal to 5.

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

#37109 [NEW]: imap_header - malicious processing of multiple 'from'-headers

2006-04-17 Thread oliver dot block at lycos dot de 
From: oliver dot block at lycos dot de
Operating system: Unix
PHP version:  5.1.2
PHP Bug Type: IMAP related
Bug description:  imap_header - malicious processing of multiple 'from'-headers

Description:

When someone send mail with multiple from-header containing mulitple
mailboxes, for example:

From: name1 [EMAIL PROTECTED], name2 [EMAIL PROTECTED], name3
[EMAIL PROTECTED]

the function imap_header() (maybe others too) should keep this edresses in
the from-field.

Unfortunately the imap_function does not keep this data in the from-field,
but in the _sender_ field.

The same is applicable to fromaddress and senderaddress fields!

Reproduce code:
---
?php
$stream = imap_open($server,$username,$password);

$header = imap_header($stream, $msgno); 
// $msgno is a valid message no to a message with multiple mailboxes in
'From:' header field 

print htmlheadheadbodypre;
print_r($header);
print /pre/body/html;

imap_close($stream);

?

Expected result:

[from] = Array
 [0] = stdClass Object
(
[personal] = name1
[mailbox] = mbox1
[host] = hotmail.com
)

[1] = stdClass Object
(
[personal] = name2
[mailbox] = mbox2
[host] = yahoo.com
)

[2] = stdClass Object
(
[personal] = name3
[mailbox] = mbox3
[host] = web.de
)


Actual result:
--
[sender] = Array
 [0] = stdClass Object
(
[personal] = name1
[mailbox] = mbox1
[host] = hotmail.com
)

[1] = stdClass Object
(
[personal] = name2
[mailbox] = mbox2
[host] = yahoo.com
)

[2] = stdClass Object
(
[personal] = name3
[mailbox] = mbox3
[host] = web.de
)


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

#37109 [Opn]: imap_header - malicious processing of multiple 'from'-headers

2006-04-17 Thread oliver dot block at lycos dot de 
 ID:   37109
 User updated by:  oliver dot block at lycos dot de
 Reported By:  oliver dot block at lycos dot de
 Status:   Open
 Bug Type: IMAP related
 Operating System: Unix
 PHP Version:  5.1.2
 New Comment:

imap_rfc822_parse_headers does deliver the correct _from_ 
field.


Previous Comments:


[2006-04-17 17:43:19] oliver dot block at lycos dot de

Description:

When someone send mail with multiple from-header containing mulitple
mailboxes, for example:

From: name1 [EMAIL PROTECTED], name2 [EMAIL PROTECTED], name3
[EMAIL PROTECTED]

the function imap_header() (maybe others too) should keep this edresses
in the from-field.

Unfortunately the imap_function does not keep this data in the
from-field, but in the _sender_ field.

The same is applicable to fromaddress and senderaddress fields!

Reproduce code:
---
?php
$stream = imap_open($server,$username,$password);

$header = imap_header($stream, $msgno); 
// $msgno is a valid message no to a message with multiple mailboxes in
'From:' header field 

print htmlheadheadbodypre;
print_r($header);
print /pre/body/html;

imap_close($stream);

?

Expected result:

[from] = Array
 [0] = stdClass Object
(
[personal] = name1
[mailbox] = mbox1
[host] = hotmail.com
)

[1] = stdClass Object
(
[personal] = name2
[mailbox] = mbox2
[host] = yahoo.com
)

[2] = stdClass Object
(
[personal] = name3
[mailbox] = mbox3
[host] = web.de
)


Actual result:
--
[sender] = Array
 [0] = stdClass Object
(
[personal] = name1
[mailbox] = mbox1
[host] = hotmail.com
)

[1] = stdClass Object
(
[personal] = name2
[mailbox] = mbox2
[host] = yahoo.com
)

[2] = stdClass Object
(
[personal] = name3
[mailbox] = mbox3
[host] = web.de
)






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

#37113 [NEW]: Malicious Memory Management(?)

2006-04-17 Thread oliver dot block at lycos dot de 
From: oliver dot block at lycos dot de
Operating system: Unix
PHP version:  5.1.2
PHP Bug Type: PCRE related
Bug description:  Malicious Memory Management(?)

Description:

preg_replace_callback returns content that should not be in memory!

Reproduce code:
---
input:

1. Tue, 11 Apr 2006 17:09:22 GMT
2. Tue, 11 Apr 2006 20:26:57 + (GMT)
3. 


function check_date($s)
{
   $muster = /(Mon, |Tue, |Wed, |Thu, |Fri, |Sat, |Sun, )?(\d\d?) (.{3})
(\d\d\d\d) (\d\d:\d\d(:\d\d)?) (([+-](\d\d(\d\d)))|GMT)/;
   $result = ;
   $result = preg_replace_callback($muster, create_function('$match',
 '$mon = array(Jan = 01, Feb = 02, Mar =
03,
   Apr = 04, May = 05, Jun =
06,
   Jul = 07, Aug = 08, Sep =
09,
   Okt = 10, Nov = 11, Dez =
12);
  $mm = $mon[$match[3]];
  return {$match[2]}.{$mm}.{$match[4]};
 '),
 $s);
   return $result;
}


Expected result:

1. 11.04.2006
2. 11.04.2006
3. 


Actual result:
--
1. 11.04.2006
2. 11.04.2006 (GMT)
3. 


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

#37113 [Bgs]: Malicious Memory Management(?)

2006-04-17 Thread oliver dot block at lycos dot de 
 ID:   37113
 User updated by:  oliver dot block at lycos dot de
 Reported By:  oliver dot block at lycos dot de
 Status:   Bogus
 Bug Type: PCRE related
 Operating System: Unix
 PHP Version:  5.1.2
 New Comment:

But it does not return $match[7] which might contain GMT 
but _not_ (GMT).


Previous Comments:


[2006-04-17 22:59:43] [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.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

Your regex fetches the GMT, so where is the problem.



[2006-04-17 21:08:55] oliver dot block at lycos dot de

Description:

preg_replace_callback returns content that should not be in memory!

Reproduce code:
---
input:

1. Tue, 11 Apr 2006 17:09:22 GMT
2. Tue, 11 Apr 2006 20:26:57 + (GMT)
3. 


function check_date($s)
{
   $muster = /(Mon, |Tue, |Wed, |Thu, |Fri, |Sat, |Sun, )?(\d\d?)
(.{3})
(\d\d\d\d) (\d\d:\d\d(:\d\d)?) (([+-](\d\d(\d\d)))|GMT)/;
   $result = ;
   $result = preg_replace_callback($muster, create_function('$match',
 '$mon = array(Jan = 01, Feb = 02, Mar =
03,
   Apr = 04, May = 05, Jun =
06,
   Jul = 07, Aug = 08, Sep =
09,
   Okt = 10, Nov = 11, Dez =
12);
  $mm = $mon[$match[3]];
  return {$match[2]}.{$mm}.{$match[4]};
 '),
 $s);
   return $result;
}


Expected result:

1. 11.04.2006
2. 11.04.2006
3. 


Actual result:
--
1. 11.04.2006
2. 11.04.2006 (GMT)
3. 






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

#37109 [Bgs]: imap_header - malicious processing of multiple 'from'-headers

2006-04-17 Thread oliver dot block at lycos dot de 
 ID:   37109
 User updated by:  oliver dot block at lycos dot de
 Reported By:  oliver dot block at lycos dot de
 Status:   Bogus
 Bug Type: IMAP related
 Operating System: Unix
 PHP Version:  5.1.2
 New Comment:

I don't know, if I do understand you correctly. You mean 
the c-client library returns that (wrong) data? 
 
What about the data in imap_rcf822_parse_headers?


Previous Comments:


[2006-04-17 23:00:13] [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.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

The function what the imap library returns, PHP has nothing 
with how the data is parsed internally.



[2006-04-17 20:19:49] oliver dot block at lycos dot de

imap_rfc822_parse_headers does deliver the correct _from_ 
field.



[2006-04-17 17:43:19] oliver dot block at lycos dot de

Description:

When someone send mail with multiple from-header containing mulitple
mailboxes, for example:

From: name1 [EMAIL PROTECTED], name2 [EMAIL PROTECTED], name3
[EMAIL PROTECTED]

the function imap_header() (maybe others too) should keep this edresses
in the from-field.

Unfortunately the imap_function does not keep this data in the
from-field, but in the _sender_ field.

The same is applicable to fromaddress and senderaddress fields!

Reproduce code:
---
?php
$stream = imap_open($server,$username,$password);

$header = imap_header($stream, $msgno); 
// $msgno is a valid message no to a message with multiple mailboxes in
'From:' header field 

print htmlheadheadbodypre;
print_r($header);
print /pre/body/html;

imap_close($stream);

?

Expected result:

[from] = Array
 [0] = stdClass Object
(
[personal] = name1
[mailbox] = mbox1
[host] = hotmail.com
)

[1] = stdClass Object
(
[personal] = name2
[mailbox] = mbox2
[host] = yahoo.com
)

[2] = stdClass Object
(
[personal] = name3
[mailbox] = mbox3
[host] = web.de
)


Actual result:
--
[sender] = Array
 [0] = stdClass Object
(
[personal] = name1
[mailbox] = mbox1
[host] = hotmail.com
)

[1] = stdClass Object
(
[personal] = name2
[mailbox] = mbox2
[host] = yahoo.com
)

[2] = stdClass Object
(
[personal] = name3
[mailbox] = mbox3
[host] = web.de
)






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