from:"ramsey"

Req #64493 [Asn]: array_column: 2nd param should be optional to use entire rows as result values

2013-04-22 Thread ramsey

Edit report at https://bugs.php.net/bug.php?id=64493&edit=1

 ID: 64493
 Updated by: ram...@php.net
 Reported by:mtanalin at yandex dot ru
 Summary:array_column: 2nd param should be optional to use
 entire rows as result values
 Status: Assigned
 Type:   Feature/Change Request
 Package:Arrays related
 PHP Version:5.5.0beta1
 Assigned To:ramsey
 Block user comment: N
 Private report: N

 New Comment:

I have added a pull request that provides this functionality.

https://github.com/php/php-src/pull/331


Previous Comments:

[2013-03-22 17:18:00] mtanalin at yandex dot ru

Description:

array_column() function (new in PHP 5.5: https://wiki.php.net/rfc/array_column 
) is a very nice addition, but its design is incomplete currently.

What is missing is the ability to have entire rows (not just a column) as 
values of each element (indexed by a specified-column's values) in array 
returned by the function.

This could be achieved by making array_column's second parameter ($columnKey) 
optional. `null` value could be used to indicate that the parameter is omitted:

array_column($rows, null, 'id');

When both 2nd and 3nd parameters are omitted, an error should be triggered (or 
an exception thrown) usual way.

2nd parameter's optionality is needed to make it possible to quickly select 
exact row by exact column value while still having access to ALL columns of a 
row, not just one of the columns.

Otherwise, web-developers will still be forced to use pure-script workarounds 
like:

array_combine(array_column($rows, 'id'), $rows);

Even worse, if array_column() function in its current design will be added in 
PHP 5.5.0, but the subfeature proposed here will be added in some future 
version different from exactly 5.5.0, it would then be problematic to polyfill 
it performant and future-proof way (most likely we then would be forced to rely 
on exact PHP version while relying on implementation version instead of direct 
feature detection is usually considered bad form; we can easily determine 
function existence with function_exists('array_column'), but [AFAIK] we cannot 
determine supported types of function parameters as easily.)

Hopefully, this proposal can be implemented in PHP 5.5.0 thus making design of 
array_column() more complete and more applicable in real-world web programming.

Thanks.

P.S. Of course, anyway, having array_column() even in its current design is 
much better than not having it at all.

Test script:
---
For example, for the following input array:

$rows = [
[
'id'=> '3',
'title' => 'Foo',
'date'  => '2013-03-25'
],
[
'id'=> '5',
'title' => 'Bar',
'date'  => '2012-05-20'
]
];

array_column($rows, null, 'id') should return the following resulting array:

[
'3' => [
'id'=> '3',
'title' => 'Foo',
'date'  => '2013-03-25'
],
'5' => [
'id'=> '5',
'title' => 'Bar',
'date'  => '2012-05-20'
]
]

Expected result:

Second parameter ($columnKey) of array_column() function should be optional to 
make it possible to have entire rows as values of elements (indexed by a 
specified-column's values) of returned array.

Actual result:
--
Second parameter is not optional, so we are forced to use pure-script 
workarounds like:

array_combine(array_column($rows, 'id'), $rows);

to be able to quickly access exact row while still having ability to access any 
(not just one) column of the row.






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

Bug #61336 [Opn]: file_get_contents() no longer returns false on 4xx responses

2012-03-29 Thread ramsey

Edit report at https://bugs.php.net/bug.php?id=61336&edit=1

 ID: 61336
 Updated by: ram...@php.net
 Reported by:ram...@php.net
 Summary:file_get_contents() no longer returns false on 4xx
 responses
 Status: Open
 Type:   Bug
 Package:Filesystem function related
 Operating System:   CentOS 6.2
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

I've just done a clean install of Ubuntu 11.10 on VirtualBox and then built PHP 
5.4 from the PHP-5.4 branch. I am still encountering this problem.

As this point, the single commonality between environments is that I'm using 
VirtualBox. Could this problem be a result of the way in which VirtualBox 
accesses the network?


Previous Comments:

[2012-03-29 23:19:19] ram...@php.net

I've just checked out the PHP-5.3 branch on the same environments and built it 
with exactly the same config values as my 5.4 builds. `php --version` shows me 
this: PHP 5.3.11-dev (cli) (built: Mar 29 2012 19:12:58)

It appears that I'm having the exact same problem with the latest checkout from 
PHP 5.3 in these same two environments (Debian 6.0.4 and CentOS 6.2). Either I 
have a problem in both of these environments, or the code that is broken in 5.4 
has recently been merged to 5.3. Unfortunately, others that I have asked to 
test this cannot reproduce it in their environments, so that points to a 
problem with my environment. Any help identifying that problem is greatly 
appreciated. I have posted detailed instructions on exactly what I have done to 
set up each environment.


[2012-03-29 22:42:48] ram...@php.net

On that same Debian 6.0.4 VM (using VirtualBox), I built PHP from the latest 
checkout of the PHP-5.4 branch. `php --version` gives me the following version 
line: PHP 5.4.1RC1-dev (cli) (built: Mar 29 2012 18:34:37)

When I run my test script with this build of PHP, I am still having the same 
problem.


[2012-03-13 20:24:57] ram...@php.net

I've just tried this on a clean Debian 6.0.4 virtual machine, and I'm having 
the 
same problem there (I've tried even with ignore_errors set to false).

Here are the PHP build notes for my Debian installation: 
http://pastie.org/3588244


[2012-03-13 15:20:20] ram...@php.net

I'm still seeing the problem with ignore_errors set to false. See below for how 
I'm setting ignore_errors. For full details on how my environment is set up, 
you 
can refer to http://benramsey.com/blog/2012/03/build-php-54-on-centos-62/.


 array(
'ignore_errors' => false
)
));

$response = 
file_get_contents('http://us3.php.net/manual/en/function.foobar.php', false, 
$context);

var_dump($http_response_header);
var_dump($response);


[2012-03-10 14:21:41] cataphr...@php.net

I can't reproduce this. Probably the default context has ignore_errors on. 
Verify that it doesn't and try to pass a context that has ignore_errors set to 
false.




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

https://bugs.php.net/bug.php?id=61336


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

Bug #61336 [Opn]: file_get_contents() no longer returns false on 4xx responses

2012-03-29 Thread ramsey

Edit report at https://bugs.php.net/bug.php?id=61336&edit=1

 ID: 61336
 Updated by: ram...@php.net
 Reported by:ram...@php.net
 Summary:file_get_contents() no longer returns false on 4xx
 responses
 Status: Open
 Type:   Bug
 Package:Filesystem function related
 Operating System:   CentOS 6.2
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

I've just checked out the PHP-5.3 branch on the same environments and built it 
with exactly the same config values as my 5.4 builds. `php --version` shows me 
this: PHP 5.3.11-dev (cli) (built: Mar 29 2012 19:12:58)

It appears that I'm having the exact same problem with the latest checkout from 
PHP 5.3 in these same two environments (Debian 6.0.4 and CentOS 6.2). Either I 
have a problem in both of these environments, or the code that is broken in 5.4 
has recently been merged to 5.3. Unfortunately, others that I have asked to 
test this cannot reproduce it in their environments, so that points to a 
problem with my environment. Any help identifying that problem is greatly 
appreciated. I have posted detailed instructions on exactly what I have done to 
set up each environment.


Previous Comments:

[2012-03-29 22:42:48] ram...@php.net

On that same Debian 6.0.4 VM (using VirtualBox), I built PHP from the latest 
checkout of the PHP-5.4 branch. `php --version` gives me the following version 
line: PHP 5.4.1RC1-dev (cli) (built: Mar 29 2012 18:34:37)

When I run my test script with this build of PHP, I am still having the same 
problem.


[2012-03-13 20:24:57] ram...@php.net

I've just tried this on a clean Debian 6.0.4 virtual machine, and I'm having 
the 
same problem there (I've tried even with ignore_errors set to false).

Here are the PHP build notes for my Debian installation: 
http://pastie.org/3588244


[2012-03-13 15:20:20] ram...@php.net

I'm still seeing the problem with ignore_errors set to false. See below for how 
I'm setting ignore_errors. For full details on how my environment is set up, 
you 
can refer to http://benramsey.com/blog/2012/03/build-php-54-on-centos-62/.


 array(
'ignore_errors' => false
)
));

$response = 
file_get_contents('http://us3.php.net/manual/en/function.foobar.php', false, 
$context);

var_dump($http_response_header);
var_dump($response);


[2012-03-10 14:21:41] cataphr...@php.net

I can't reproduce this. Probably the default context has ignore_errors on. 
Verify that it doesn't and try to pass a context that has ignore_errors set to 
false.


[2012-03-09 22:41:50] s...@php.net

Just for the record, repro script works for me on Windows / 5.4.0 VC9 NTS




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

https://bugs.php.net/bug.php?id=61336


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

Bug #61336 [Opn]: file_get_contents() no longer returns false on 4xx responses

2012-03-29 Thread ramsey

Edit report at https://bugs.php.net/bug.php?id=61336&edit=1

 ID: 61336
 Updated by: ram...@php.net
 Reported by:ram...@php.net
 Summary:file_get_contents() no longer returns false on 4xx
 responses
 Status: Open
 Type:   Bug
 Package:Filesystem function related
 Operating System:   CentOS 6.2
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

On that same Debian 6.0.4 VM (using VirtualBox), I built PHP from the latest 
checkout of the PHP-5.4 branch. `php --version` gives me the following version 
line: PHP 5.4.1RC1-dev (cli) (built: Mar 29 2012 18:34:37)

When I run my test script with this build of PHP, I am still having the same 
problem.


Previous Comments:

[2012-03-13 20:24:57] ram...@php.net

I've just tried this on a clean Debian 6.0.4 virtual machine, and I'm having 
the 
same problem there (I've tried even with ignore_errors set to false).

Here are the PHP build notes for my Debian installation: 
http://pastie.org/3588244


[2012-03-13 15:20:20] ram...@php.net

I'm still seeing the problem with ignore_errors set to false. See below for how 
I'm setting ignore_errors. For full details on how my environment is set up, 
you 
can refer to http://benramsey.com/blog/2012/03/build-php-54-on-centos-62/.


 array(
'ignore_errors' => false
)
));

$response = 
file_get_contents('http://us3.php.net/manual/en/function.foobar.php', false, 
$context);

var_dump($http_response_header);
var_dump($response);


[2012-03-10 14:21:41] cataphr...@php.net

I can't reproduce this. Probably the default context has ignore_errors on. 
Verify that it doesn't and try to pass a context that has ignore_errors set to 
false.


[2012-03-09 22:41:50] s...@php.net

Just for the record, repro script works for me on Windows / 5.4.0 VC9 NTS


[2012-03-09 21:59:47] ram...@php.net

Description:

In PHP 5.3, file_get_contents() returns false on 4xx responses. In PHP 5.4, 
file_get_contents() is returning the actual response body, rather than false.

Test script:
---
http://us3.php.net/manual/en/function.foobar.php');

var_dump($http_response_header);
var_dump($response);

Expected result:

With warnings turned on, this is what I get in PHP 5.3 and what I expect to see 
in PHP 5.4:

PHP Warning:  
file_get_contents(http://us3.php.net/manual/en/function.foobar.php): failed to 
open stream: HTTP request failed! HTTP/1.0 404 Not Found
 in /Users/ramsey/Desktop/file_get_contents.php on line 3
PHP Stack trace:
PHP   1. {main}() /Users/ramsey/Desktop/file_get_contents.php:0
PHP   2. file_get_contents() /Users/ramsey/Desktop/file_get_contents.php:3
array(11) {
  [0]=>
  string(22) "HTTP/1.0 404 Not Found"
  [1]=>
  string(35) "Date: Fri, 09 Mar 2012 21:57:32 GMT"
  [2]=>
  string(29) "Server: Apache/2.2.3 (CentOS)"
  [3]=>
  string(23) "X-Powered-By: PHP/5.3.2"
  [4]=>
  string(20) "Content-language: en"
  [5]=>
  string(88) "Set-Cookie: LAST_LANG=en; expires=Sat, 09-Mar-2013 21:57:32 GMT; 
path=/; domain=.php.net"
  [6]=>
  string(102) "Set-Cookie: COUNTRY=USA%2C64.2.187.194; expires=Fri, 16-Mar-2012 
21:57:32 GMT; path=/; domain=.php.net"
  [7]=>
  string(21) "Status: 404 Not Found"
  [8]=>
  string(20) "Content-Length: 4219"
  [9]=>
  string(17) "Connection: close"
  [10]=>
  string(37) "Content-Type: text/html;charset=utf-8"
}
bool(false)

Actual result:
--
array(11) {
  [0]=>
  string(22) "HTTP/1.1 404 Not Found"
  [1]=>
  string(35) "Date: Fri, 09 Mar 2012 21:58:44 GMT"
  [2]=>
  string(29) "Server: Apache/2.2.3 (CentOS)"
  [3]=>
  string(23) "X-Powered-By: PHP/5.3.2"
  [4]=>
  string(20) "Content-language: en"
  [5]=>
  string(88) "Set-Cookie: LAST_LANG=en; expires=Sat, 09-Mar-2013 21:58:44 GMT; 
path=/; domain=.php.net"
  [6]=>
  string(102) "Set-Cookie: COUNTRY=USA%2C64.2.187.194; expires=Fri, 16-Mar-2012 
21:58:44 GMT; path=/; domain=.php.net"
  [7]=>
  string(21) "Status: 404 Not Found"
  [8]=>
  string(20) "Content-Length: 4219"
  [9]=>
  string(17) "Connection: close"
  [10]=>
  string(37) "Content-Type: text/html;charset=utf-8"
}
string(4219) "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en">

 PHP: 404 Not Found

Bug #61336 [Fbk->Opn]: file_get_contents() no longer returns false on 4xx responses

2012-03-28 Thread ramsey

Edit report at https://bugs.php.net/bug.php?id=61336&edit=1

 ID: 61336
 Updated by: ram...@php.net
 Reported by:ram...@php.net
 Summary:file_get_contents() no longer returns false on 4xx
 responses
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:Filesystem function related
 Operating System:   CentOS 6.2
 PHP Version:5.4.0
 Block user comment: N
 Private report: N



Previous Comments:

[2012-03-13 20:24:57] ram...@php.net

I've just tried this on a clean Debian 6.0.4 virtual machine, and I'm having 
the 
same problem there (I've tried even with ignore_errors set to false).

Here are the PHP build notes for my Debian installation: 
http://pastie.org/3588244


[2012-03-13 15:20:20] ram...@php.net

I'm still seeing the problem with ignore_errors set to false. See below for how 
I'm setting ignore_errors. For full details on how my environment is set up, 
you 
can refer to http://benramsey.com/blog/2012/03/build-php-54-on-centos-62/.


 array(
'ignore_errors' => false
)
));

$response = 
file_get_contents('http://us3.php.net/manual/en/function.foobar.php', false, 
$context);

var_dump($http_response_header);
var_dump($response);


[2012-03-10 14:21:41] cataphr...@php.net

I can't reproduce this. Probably the default context has ignore_errors on. 
Verify that it doesn't and try to pass a context that has ignore_errors set to 
false.


[2012-03-09 22:41:50] s...@php.net

Just for the record, repro script works for me on Windows / 5.4.0 VC9 NTS


[2012-03-09 21:59:47] ram...@php.net

Description:

In PHP 5.3, file_get_contents() returns false on 4xx responses. In PHP 5.4, 
file_get_contents() is returning the actual response body, rather than false.

Test script:
---
http://us3.php.net/manual/en/function.foobar.php');

var_dump($http_response_header);
var_dump($response);

Expected result:

With warnings turned on, this is what I get in PHP 5.3 and what I expect to see 
in PHP 5.4:

PHP Warning:  
file_get_contents(http://us3.php.net/manual/en/function.foobar.php): failed to 
open stream: HTTP request failed! HTTP/1.0 404 Not Found
 in /Users/ramsey/Desktop/file_get_contents.php on line 3
PHP Stack trace:
PHP   1. {main}() /Users/ramsey/Desktop/file_get_contents.php:0
PHP   2. file_get_contents() /Users/ramsey/Desktop/file_get_contents.php:3
array(11) {
  [0]=>
  string(22) "HTTP/1.0 404 Not Found"
  [1]=>
  string(35) "Date: Fri, 09 Mar 2012 21:57:32 GMT"
  [2]=>
  string(29) "Server: Apache/2.2.3 (CentOS)"
  [3]=>
  string(23) "X-Powered-By: PHP/5.3.2"
  [4]=>
  string(20) "Content-language: en"
  [5]=>
  string(88) "Set-Cookie: LAST_LANG=en; expires=Sat, 09-Mar-2013 21:57:32 GMT; 
path=/; domain=.php.net"
  [6]=>
  string(102) "Set-Cookie: COUNTRY=USA%2C64.2.187.194; expires=Fri, 16-Mar-2012 
21:57:32 GMT; path=/; domain=.php.net"
  [7]=>
  string(21) "Status: 404 Not Found"
  [8]=>
  string(20) "Content-Length: 4219"
  [9]=>
  string(17) "Connection: close"
  [10]=>
  string(37) "Content-Type: text/html;charset=utf-8"
}
bool(false)

Actual result:
--
array(11) {
  [0]=>
  string(22) "HTTP/1.1 404 Not Found"
  [1]=>
  string(35) "Date: Fri, 09 Mar 2012 21:58:44 GMT"
  [2]=>
  string(29) "Server: Apache/2.2.3 (CentOS)"
  [3]=>
  string(23) "X-Powered-By: PHP/5.3.2"
  [4]=>
  string(20) "Content-language: en"
  [5]=>
  string(88) "Set-Cookie: LAST_LANG=en; expires=Sat, 09-Mar-2013 21:58:44 GMT; 
path=/; domain=.php.net"
  [6]=>
  string(102) "Set-Cookie: COUNTRY=USA%2C64.2.187.194; expires=Fri, 16-Mar-2012 
21:58:44 GMT; path=/; domain=.php.net"
  [7]=>
  string(21) "Status: 404 Not Found"
  [8]=>
  string(20) "Content-Length: 4219"
  [9]=>
  string(17) "Connection: close"
  [10]=>
  string(37) "Content-Type: text/html;charset=utf-8"
}
string(4219) "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en">

 PHP: 404 Not Found

#50291 [Csd->Opn]: incorrect usage of autoconf diversions

2010-01-23 Thread ramsey

 ID:   50291
 Updated by:   ram...@php.net
 Reported By:  vapier at gentoo dot org
-Status:   Closed
+Status:   Open
 Bug Type: *Compile Issues
 Operating System: Linux
 PHP Version:  5.3.1
 New Comment:

I'm having this problem with a fresh checkout (revision 293858) from 
the PHP_5_3 branch. I running on Mac OS X 10.6.2 and have autoconf 
2.65 from macports.

$ ./buildconf
$ ./configure
cat: confdefs.h: No such file or directory
./configure: line 389: ac_fn_c_try_run: command not found
./configure: line 405: 5: Bad file descriptor
./configure: line 406: 6: Bad file descriptor
cat: confdefs.h: No such file or directory
./configure: line 445: ac_fn_c_try_run: command not found
..

I'm not having the problem when running configure on the 5.3.1 tar 
package.


Previous Comments:


[2009-11-25 01:37:52] ras...@php.net

Thanks, this motivated me to clean up our m4 crap and make it work with
the latest versions of autoconf.  Should still clean up the template
warnings eventually, but those are non-fatal and everything builds
nicely now with autoconf-2.65 for me.



[2009-11-25 00:01:36] vapier at gentoo dot org

Description:

autoconf-2.64+ has changed behavior with diversions in such a way that
php breaks.  the autoconf documentation has explained that using these
functions with any diversion not explicitly documented is subject to
breakage, and php is doing just that.

http://www.gnu.org/software/autoconf/manual/autoconf.html#Diversion-support

you can also review the discussion on the autoconf lists:
http://lists.gnu.org/archive/html/bug-autoconf/2009-11/msg00045.html

Reproduce code:
---
the code can either be changed to stop using divert() completely (since
it doesnt seem to accomplish anything), or increase the numbers used to
something higher than 1000.

Actual result:
--
after regenerating autotools, we see:
$ ./configure
cat: confdefs.h: No such file or directory
./configure: line 410: ac_fn_c_try_run: command not found
./configure: line 426: 5: Bad file descriptor
./configure: line 427: 6: Bad file descriptor
cat: confdefs.h: No such file or directory
./configure: line 466: ac_fn_c_try_run: command not found
cat: confdefs.h: No such file or directory






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

#48795 [Ver]: Building intl 64-bit fails on OS X

2009-09-15 Thread ramsey

 ID:   48795
 Updated by:   ram...@php.net
 Reported By:  gwy...@php.net
 Status:   Verified
 Bug Type: Compile Failure
-Operating System: Darwin9 (MacOS X 10.5)
+Operating System: Mac OS X 10.5.8
-PHP Version:  5.3CVS-2009-07-04 (CVS)
+PHP Version:  5.3SVN-2009-09-14 (SVN)
 New Comment:

I'm having the same exact problem using --enable-intl
--with-icu-dir=/path/to/icu

I installed ICU with macports, and so I'm using /opt/local as my path
to ICU.


Previous Comments:


[2009-07-16 20:09:52] jplock at gmail dot com

I'm using OSX 10.5 as well and I'm getting the same error when trying
to build PHP 5.3.0 with intl enabled.

Undefined symbols:
  "___gxx_personality_v0", referenced from:
  ___gxx_personality_v0$non_lazy_ptr in msgformat_helpers.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [libs/libphp5.bundle] Error 1



LDFLAGS="/usr/lib/gcc/i686-apple-darwin9/4.0.1/libstdc++.dylib"
export LDFLAGS

./configure \
--disable-all \
--with-libxml-dir=/usr \
--with-apxs2=/usr/local/apache22/bin/apxs \
--with-regex=php \
--with-zend-vm=CALL \
--with-curl=/usr \
--with-curlwrappers \
--with-gd \
--with-gettext=/usr \
--with-iconv \
--with-pear=/usr/local/lib/php \
--with-mysqli=mysqlnd \
--with-pdo-mysql=mysqlnd \
--with-openssl=/usr \
--with-pcre-regex \
--with-zlib-dir=/usr \
--with-xsl=/usr \
--with-jpeg-dir=/usr \
--with-png-dir=/usr \
--with-icu-dir=/usr/local \
--enable-tokenizer \
--enable-ctype \
--enable-mbstring \
--enable-session \
--enable-simplexml \
--enable-xml \
--enable-hash \
--enable-libxml \
--enable-dom \
--enable-filter \
--enable-fileinfo \
--enable-bcmath \
--enable-json \
--enable-intl \
--enable-pdo \
--enable-pcntl \
--enable-shmop \
--enable-phar \
--enable-posix \
--enable-sockets



[2009-07-04 00:47:46] gwy...@php.net

Description:

This is a reference to PECL bug #16575
. Since intl will shortly be
part of core instead of PECL, I feel this bug belongs here. Here's my
addition to the issue:

This is due to intl/msgformat/msgformat_helpers.cpp being a C++ file
and GCC not handling that case cleanly. The exact error is specifically
due to GCC not linking to libstdc++. Which is, actually, kinda
reasonable since it's been invoked as a plain C compiler. Anyway, you
can get around the problem for now by adding
"/usr/lib/gcc/i686-apple-darwin9/4.2.1/libstdc++.dylib" (if you're
building with gcc-4.2) or
"/usr/lib/gcc/i686-apple-darwin9/4.0.1/libstdc++.dylib" (if you're
building with gcc-4.0, the default) to your LDFLAGS. That's right,
WITHOUT -l or -L. I wouldn't consider this a real solution, but a better
solution is pending further research into the subject.

Reproduce code:
---
$ CFLAGS='-arch x86_64' CXXFLAGS='-arch x86_64' LDFLAGS='-arch x86_64'
./configure --enable-intl --with-icu=/path/to/icu
$ make


Expected result:

Build complete.
Don't forget to run 'make test'.

$ 

Actual result:
--
Undefined symbols:
 "___gxx_personality_v0", referenced from:
 EH_frame1 in msgformat_helpers.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [sapi/cgi/php-cgi] Error 1
$ 






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

#49242 [Fbk]: Expose function in Zend API for comparing arrays by identity

2009-08-13 Thread ramsey

 ID:   49242
 Updated by:   ram...@php.net
 Reported By:  ram...@php.net
 Status:   Feedback
 Bug Type: Feature/Change Request
 Operating System: n/a
 PHP Version:  5.3SVN-2009-08-13 (SVN)
 New Comment:

Here you go: http://pastie.org/pastes/582230


Previous Comments:


[2009-08-13 08:50:37] der...@php.net

Could you post a link to the patch perhaps? It got mangled up in here.



[2009-08-13 03:18:10] ram...@php.net

Patch for zend_compare_arrays_identity():

Index: Zend/zend_operators.c
===
--- Zend/zend_operators.c   (revision 287194)
+++ Zend/zend_operators.c   (working copy)
@@ -2011,12 +2011,24 @@
 }
 /* }}} */
 
+ZEND_API void zend_compare_symbol_tables_identity(zval *result,
HashTable *ht1, HashTable *ht2 TSRMLS_DC) /* {{{ */
+{
+   ZVAL_LONG(result, zend_hash_compare(ht1, ht2, (compare_func_t)
hash_zval_compare_function, 1 TSRMLS_CC));
+}
+/* }}} */
+
 ZEND_API void zend_compare_arrays(zval *result, zval *a1, zval *a2
TSRMLS_DC) /* {{{ */
 {
zend_compare_symbol_tables(result, Z_ARRVAL_P(a1), Z_ARRVAL_P(a2)
TSRMLS_CC);
 }
 /* }}} */
 
+ZEND_API void zend_compare_arrays_identity(zval *result, zval *a1,
zval *a2 TSRMLS_DC) /* {{{ */
+{
+   zend_compare_symbol_tables_identity(result, Z_ARRVAL_P(a1),
Z_ARRVAL_P(a2) TSRMLS_CC);
+}
+/* }}} */
+
 ZEND_API void zend_compare_objects(zval *result, zval *o1, zval *o2
TSRMLS_DC) /* {{{ */
 {
Z_TYPE_P(result) = IS_LONG;
Index: Zend/zend_operators.h
===
--- Zend/zend_operators.h   (revision 287194)
+++ Zend/zend_operators.h   (working copy)
@@ -319,6 +319,7 @@
 ZEND_API void zendi_smart_strcmp(zval *result, zval *s1, zval *s2);
 ZEND_API void zend_compare_symbol_tables(zval *result, HashTable *ht1,
HashTable *ht2 TSRMLS_DC);
 ZEND_API void zend_compare_arrays(zval *result, zval *a1, zval *a2
TSRMLS_DC);
+ZEND_API void zend_compare_arrays_identity(zval *result, zval *a1,
zval *a2 TSRMLS_DC);
 ZEND_API void zend_compare_objects(zval *result, zval *o1, zval *o2
TSRMLS_DC);
 
 ZEND_API int zend_atoi(const char *str, int str_len);



[2009-08-13 03:16:40] ram...@php.net

Description:

I'm using the embed SAPI, and I came across an issue when using
zend_hash_compare().

I wanted to use the provided hash_zval_compare_function() as the
callback function for the compar parameter. However, I cannot use this,
since it is not exposed. I could use zend_compare_arrays(), but it
doesn't allow me to pass in a 1 as the value of the ordered parameter
sent to zend_hash_compare(). Since I want to compare arrays like
comparing with the identity operator, then I need to use
zend_hash_compare() and create my own callback that does exactly what
hash_zval_compare_function() does, thus reinventing the wheel.

Either:

1) Expose hash_zval_compare_function() so it can be used by third-party
apps

- or -

2) Make a second version of zend_compare_arrays() that allows you to
compare arrays by identity (i.e. zend_compare_arrays_identity()?)






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

#49242 [Opn]: Expose function in Zend API for comparing arrays by identity

2009-08-12 Thread ramsey

 ID:   49242
 Updated by:   ram...@php.net
 Reported By:  ram...@php.net
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: n/a
 PHP Version:  5.3SVN-2009-08-13 (SVN)
 New Comment:

Patch for zend_compare_arrays_identity():

Index: Zend/zend_operators.c
===
--- Zend/zend_operators.c   (revision 287194)
+++ Zend/zend_operators.c   (working copy)
@@ -2011,12 +2011,24 @@
 }
 /* }}} */
 
+ZEND_API void zend_compare_symbol_tables_identity(zval *result,
HashTable *ht1, HashTable *ht2 TSRMLS_DC) /* {{{ */
+{
+   ZVAL_LONG(result, zend_hash_compare(ht1, ht2, (compare_func_t)
hash_zval_compare_function, 1 TSRMLS_CC));
+}
+/* }}} */
+
 ZEND_API void zend_compare_arrays(zval *result, zval *a1, zval *a2
TSRMLS_DC) /* {{{ */
 {
zend_compare_symbol_tables(result, Z_ARRVAL_P(a1), Z_ARRVAL_P(a2)
TSRMLS_CC);
 }
 /* }}} */
 
+ZEND_API void zend_compare_arrays_identity(zval *result, zval *a1,
zval *a2 TSRMLS_DC) /* {{{ */
+{
+   zend_compare_symbol_tables_identity(result, Z_ARRVAL_P(a1),
Z_ARRVAL_P(a2) TSRMLS_CC);
+}
+/* }}} */
+
 ZEND_API void zend_compare_objects(zval *result, zval *o1, zval *o2
TSRMLS_DC) /* {{{ */
 {
Z_TYPE_P(result) = IS_LONG;
Index: Zend/zend_operators.h
===
--- Zend/zend_operators.h   (revision 287194)
+++ Zend/zend_operators.h   (working copy)
@@ -319,6 +319,7 @@
 ZEND_API void zendi_smart_strcmp(zval *result, zval *s1, zval *s2);
 ZEND_API void zend_compare_symbol_tables(zval *result, HashTable *ht1,
HashTable *ht2 TSRMLS_DC);
 ZEND_API void zend_compare_arrays(zval *result, zval *a1, zval *a2
TSRMLS_DC);
+ZEND_API void zend_compare_arrays_identity(zval *result, zval *a1,
zval *a2 TSRMLS_DC);
 ZEND_API void zend_compare_objects(zval *result, zval *o1, zval *o2
TSRMLS_DC);
 
 ZEND_API int zend_atoi(const char *str, int str_len);


Previous Comments:


[2009-08-13 03:16:40] ram...@php.net

Description:

I'm using the embed SAPI, and I came across an issue when using
zend_hash_compare().

I wanted to use the provided hash_zval_compare_function() as the
callback function for the compar parameter. However, I cannot use this,
since it is not exposed. I could use zend_compare_arrays(), but it
doesn't allow me to pass in a 1 as the value of the ordered parameter
sent to zend_hash_compare(). Since I want to compare arrays like
comparing with the identity operator, then I need to use
zend_hash_compare() and create my own callback that does exactly what
hash_zval_compare_function() does, thus reinventing the wheel.

Either:

1) Expose hash_zval_compare_function() so it can be used by third-party
apps

- or -

2) Make a second version of zend_compare_arrays() that allows you to
compare arrays by identity (i.e. zend_compare_arrays_identity()?)






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

#44462 [Opn]: Can not compile embed sapi on OSX

2009-07-07 Thread ramsey

 ID:   44462
 Updated by:   ram...@php.net
 Reported By:  graham+php at nexopia dot com
 Status:   Open
 Bug Type: Compile Failure
 Operating System: OSX
 PHP Version:  5.2CVS-2009-03-25
 New Comment:

Looks like issue #48318 is a duplicate issue, and it includes another
patch to fix this issue.


Previous Comments:


[2009-07-07 18:41:21] ram...@php.net

Strange to see this ticket still not resolved after over a year has
passed. I'm having this issue, too...

On OS X 10.5.7, building PHP fails when built with --enable-embed. This
occurs in both 5.3.0 and 5.2.10.

./configure --enable-embed
make

Result from 5.3.0:

[...] sapi/embed/php_embed.lo main/internal_functions.lo -liconv
-liconv -lm -lxml2 -lz -licucore -lm -lxml2 -lz -licucore -lm -lxml2 -lz
-licucore -lm -lxml2 -lz -licucore -lm -lxml2 -lz -licucore -lm -lxml2
-lz -licucore -lm  -o libphp5.la
ld: duplicate symbol _spl_ce_SplDoublyLinkedList in
ext/spl/.libs/spl_dllist.o and ext/spl/.libs/php_spl.o
collect2: ld returned 1 exit status
make: *** [libphp5.la] Error 1


Result from 5.2.10:

[...] sapi/embed/php_embed.lo main/internal_functions.lo -liconv
-liconv -lm -lxml2 -lz -licucore -lm -lxml2 -lz -licucore -lm -lxml2 -lz
-licucore -lm -lxml2 -lz -licucore -lm -lxml2 -lz -licucore -lm -lxml2
-lz -licucore -lm  -o libphp5.la
ld: duplicate symbol _yytext in Zend/.libs/zend_ini_scanner.o and
Zend/.libs/zend_language_scanner.o
collect2: ld returned 1 exit status
make: *** [libphp5.la] Error 1




[2009-06-13 21:05:14] aaron at tenderlovemaking dot com

This is happening for me as well:

ld: duplicate symbol _yytext in Zend/.libs/zend_ini_scanner.o and 
Zend/.libs/zend_language_scanner.o
collect2: ld returned 1 exit status
make: *** [libphp5.la] Error 1
[apatter...@jordan2 php-5.2.9]$

I can attach my config.log if it helps.



[2009-06-05 19:27:45] ralph at smashlabs dot com

I can confirm this is still an issue


  ld: duplicate symbol _spl_ce_SplDoublyLinkedList in
ext/spl/.libs/spl_dllist.o and ext/spl/.libs/php_spl.o
  collect2: ld returned 1 exit status
  make: *** [libphp5.la] Error 1 


I can compile statically though.  Can you reopen?



[2009-04-09 01:00:00] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, 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".



[2009-04-01 11:25:00] j...@php.net

There is no working patch here. Or are you saying you can not compile 
PHP (without the experimental embed sapi)? FYI: it works fine for me.




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

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

#44462 [NoF->Opn]: Can not compile embed sapi on OSX

2009-07-07 Thread ramsey

 ID:   44462
 Updated by:   ram...@php.net
 Reported By:  graham+php at nexopia dot com
-Status:   No Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: OSX
 PHP Version:  5.2CVS-2009-03-25
 New Comment:

Strange to see this ticket still not resolved after over a year has
passed. I'm having this issue, too...

On OS X 10.5.7, building PHP fails when built with --enable-embed. This
occurs in both 5.3.0 and 5.2.10.

./configure --enable-embed
make

Result from 5.3.0:

[...] sapi/embed/php_embed.lo main/internal_functions.lo -liconv
-liconv -lm -lxml2 -lz -licucore -lm -lxml2 -lz -licucore -lm -lxml2 -lz
-licucore -lm -lxml2 -lz -licucore -lm -lxml2 -lz -licucore -lm -lxml2
-lz -licucore -lm  -o libphp5.la
ld: duplicate symbol _spl_ce_SplDoublyLinkedList in
ext/spl/.libs/spl_dllist.o and ext/spl/.libs/php_spl.o
collect2: ld returned 1 exit status
make: *** [libphp5.la] Error 1


Result from 5.2.10:

[...] sapi/embed/php_embed.lo main/internal_functions.lo -liconv
-liconv -lm -lxml2 -lz -licucore -lm -lxml2 -lz -licucore -lm -lxml2 -lz
-licucore -lm -lxml2 -lz -licucore -lm -lxml2 -lz -licucore -lm -lxml2
-lz -licucore -lm  -o libphp5.la
ld: duplicate symbol _yytext in Zend/.libs/zend_ini_scanner.o and
Zend/.libs/zend_language_scanner.o
collect2: ld returned 1 exit status
make: *** [libphp5.la] Error 1



Previous Comments:


[2009-06-13 21:05:14] aaron at tenderlovemaking dot com

This is happening for me as well:

ld: duplicate symbol _yytext in Zend/.libs/zend_ini_scanner.o and 
Zend/.libs/zend_language_scanner.o
collect2: ld returned 1 exit status
make: *** [libphp5.la] Error 1
[apatter...@jordan2 php-5.2.9]$

I can attach my config.log if it helps.



[2009-06-05 19:27:45] ralph at smashlabs dot com

I can confirm this is still an issue


  ld: duplicate symbol _spl_ce_SplDoublyLinkedList in
ext/spl/.libs/spl_dllist.o and ext/spl/.libs/php_spl.o
  collect2: ld returned 1 exit status
  make: *** [libphp5.la] Error 1 


I can compile statically though.  Can you reopen?



[2009-04-09 01:00:00] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, 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".



[2009-04-01 11:25:00] j...@php.net

There is no working patch here. Or are you saying you can not compile 
PHP (without the experimental embed sapi)? FYI: it works fine for me.




[2009-03-25 18:28:07] graham+php at nexopia dot com

Incidentally, this bug is now a year old, has a functioning patch that
resolves the issue, and has still not been fixed upstream.



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

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

#48837 [Fbk]: Building --with-curlwrappers can cause bad/illegal format or missing URL errors

2009-07-07 Thread ramsey

 ID:   48837
 Updated by:   ram...@php.net
 Reported By:  ram...@php.net
 Status:   Feedback
 Bug Type: cURL related
 Operating System: Ubuntu 9.04
 PHP Version:  5.3.0
 Assigned To:  fb-req-jani
 New Comment:

Oddly enough, I cannot reproduce this now in 5.3.0 or 5.2.10, though I
was having this problem the other day. When I build either version with
--with-curlwrappers and use the same code I used the other day, it
appears to work fine now. As far as I know, nothing else on the system
has changed in the meantime.

I guess you can feel free to bogus this issue, since I can't reproduce
it.


Previous Comments:


[2009-07-07 17:17:45] j...@php.net

Does this happen with PHP 5.2.10?



[2009-07-07 16:59:06] ram...@php.net

Description:

I received the error "URL using bad/illegal format or missing URL" on
some require_once() calls when PHP was built with --with-curlwrappers.

Building PHP without --with-curlwrappers fixed the problem.

Reproduce code:
---
I was using a vanilla install of Zend Framework when I noticed the
problem.

Expected result:

The file did exist at the location being required, and the include_path
was correct, so I expected the file to be required.

Actual result:
--
Warning: require_once(): URL using bad/illegal format or missing URL in
/home/ramsey/dev/zftest/lib/Zend/Loader/PluginLoader.php on line 396
Warning:
require_once(/home/ramsey/dev/zftest/lib/Zend/Loader/PluginLoader/Exception.php):
failed to open stream: operation failed in
/home/ramsey/dev/zftest/lib/Zend/Loader/PluginLoader.php on line 396
Fatal error: require_once(): Failed opening required
'Zend/Loader/PluginLoader/Exception.php'
(include_path='/home/ramsey/dev/zftest/lib') in
/home/ramsey/dev/zftest/lib/Zend/Loader/PluginLoader.php on line 396





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

#36797 [Asn]: Problem using UTF-8 database with pdo_oci

2007-06-06 Thread ramsey

 ID:   36797
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mauroi at digbang dot com
 Status:   Assigned
 Bug Type: PDO related
 Operating System: Win XP SP2
 PHP Version:  5.1.2
-Assigned To:  wez
+Assigned To:  ramsey
 New Comment:

Assigning to myself to update the PDO_OCI documentation to include
discussion about setting charsets for Oracle.


Previous Comments:


[2007-06-06 20:02:18] [EMAIL PROTECTED]

[EMAIL PROTECTED] and I debugged this issue for hours, and here's
what it came down to.

We fixed this issue by doing the following:

1. As suggested, the DSN string was modified to contain
'charset=AL32UTF8'

2. Apache now has an environment variable NLS_LANG set as follows:
NLS_LANG='AMERICAN_AMERICA.AL32UTF8'

3. Make sure that $ORACLE_HOME/nls/data and all files within are
world-readable.



[2007-06-05 19:15:39] [EMAIL PROTECTED]

As information, I use  'oci:...charset=AL32UTF8' with latest IC and
oracle 10g as server and works (5.2.2 and cvs).



[2007-06-05 18:45:56] [EMAIL PROTECTED]

Note that I'm not using HTML entities in the field, but rather, actual
Japanese characters. The bug report here appears to convert these chars
to HTML entities.



[2007-06-05 18:44:26] [EMAIL PROTECTED]

Here's some more reproduce code:

setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

// Create table
$dbh->exec('create table my_test_table(my_field varchar2(100))');

// Insert data
$dbh->exec('insert into my_test_table(my_field) values (\'foo\')');
$dbh->exec('insert into my_test_table(my_field) values
(\'日本語 \')');

// Get data
foreach ($dbh->query('select my_field from my_test_table') as $row) {
var_dump($row);
}

$dbh->exec('drop table my_test_table');
?>


ACTUAL OUTPUT:

array(2) {
  ["MY_FIELD"]=>
  string(3) "foo"
  [0]=>
  string(3) "foo"
}
array(2) {
  ["MY_FIELD"]=>
  string(4) "??? "
  [0]=>
  string(4) "??? "
}


EXPECTED OUTPUT:

array(2) {
  ["MY_FIELD"]=>
  string(3) "foo"
  [0]=>
  string(3) "foo"
}
array(2) {
  ["MY_FIELD"]=>
  string(4) "日本語 "
  [0]=>
  string(4) "日本語 "
}



[2007-06-05 16:23:00] [EMAIL PROTECTED]

I'm also having the same problem in PHP 5.2.2. I've set
NLS_LANG=AMERICAN_AMERICA.AL32UTF8 and my PDO DSN is
oci:dbname=foo;charset=UTF-8. These don't seem to have any affect. The
characters I send to the DB through PDO_OCI are still getting converted
to ???. The DB charset is AL32UTF8. I'm using Linux.

When I change the DSN charset to AL32UTF8, then there is no output on
the page, nor are there errors reported in the error log. PHP appears to
crash but gives no response as to why.



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

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

#36797 [Asn]: Problem using UTF-8 database with pdo_oci

2007-06-06 Thread ramsey

 ID:   36797
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mauroi at digbang dot com
 Status:   Assigned
 Bug Type: PDO related
 Operating System: Win XP SP2
 PHP Version:  5.1.2
 Assigned To:  wez
 New Comment:

[EMAIL PROTECTED] and I debugged this issue for hours, and here's
what it came down to.

We fixed this issue by doing the following:

1. As suggested, the DSN string was modified to contain
'charset=AL32UTF8'

2. Apache now has an environment variable NLS_LANG set as follows:
NLS_LANG='AMERICAN_AMERICA.AL32UTF8'

3. Make sure that $ORACLE_HOME/nls/data and all files within are
world-readable.


Previous Comments:


[2007-06-05 19:15:39] [EMAIL PROTECTED]

As information, I use  'oci:...charset=AL32UTF8' with latest IC and
oracle 10g as server and works (5.2.2 and cvs).



[2007-06-05 18:45:56] [EMAIL PROTECTED]

Note that I'm not using HTML entities in the field, but rather, actual
Japanese characters. The bug report here appears to convert these chars
to HTML entities.



[2007-06-05 18:44:26] [EMAIL PROTECTED]

Here's some more reproduce code:

setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

// Create table
$dbh->exec('create table my_test_table(my_field varchar2(100))');

// Insert data
$dbh->exec('insert into my_test_table(my_field) values (\'foo\')');
$dbh->exec('insert into my_test_table(my_field) values
(\'日本語 \')');

// Get data
foreach ($dbh->query('select my_field from my_test_table') as $row) {
var_dump($row);
}

$dbh->exec('drop table my_test_table');
?>


ACTUAL OUTPUT:

array(2) {
  ["MY_FIELD"]=>
  string(3) "foo"
  [0]=>
  string(3) "foo"
}
array(2) {
  ["MY_FIELD"]=>
  string(4) "??? "
  [0]=>
  string(4) "??? "
}


EXPECTED OUTPUT:

array(2) {
  ["MY_FIELD"]=>
  string(3) "foo"
  [0]=>
  string(3) "foo"
}
array(2) {
  ["MY_FIELD"]=>
  string(4) "日本語 "
  [0]=>
  string(4) "日本語 "
}



[2007-06-05 16:23:00] [EMAIL PROTECTED]

I'm also having the same problem in PHP 5.2.2. I've set
NLS_LANG=AMERICAN_AMERICA.AL32UTF8 and my PDO DSN is
oci:dbname=foo;charset=UTF-8. These don't seem to have any affect. The
characters I send to the DB through PDO_OCI are still getting converted
to ???. The DB charset is AL32UTF8. I'm using Linux.

When I change the DSN charset to AL32UTF8, then there is no output on
the page, nor are there errors reported in the error log. PHP appears to
crash but gives no response as to why.



[2006-03-20 15:29:43] mauroi at digbang dot com

I've tried but the same happens.
I've also tried the complete NLS_LANG (AMERICAN_AMERICA.AL32UTF8) with
no success.

Thanks!



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

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

#36797 [Asn]: Problem using UTF-8 database with pdo_oci

2007-06-05 Thread ramsey

 ID:   36797
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mauroi at digbang dot com
 Status:   Assigned
 Bug Type: PDO related
 Operating System: Win XP SP2
 PHP Version:  5.1.2
 Assigned To:  wez
 New Comment:

Note that I'm not using HTML entities in the field, but rather, actual
Japanese characters. The bug report here appears to convert these chars
to HTML entities.


Previous Comments:


[2007-06-05 18:44:26] [EMAIL PROTECTED]

Here's some more reproduce code:

setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

// Create table
$dbh->exec('create table my_test_table(my_field varchar2(100))');

// Insert data
$dbh->exec('insert into my_test_table(my_field) values (\'foo\')');
$dbh->exec('insert into my_test_table(my_field) values
(\'日本語 \')');

// Get data
foreach ($dbh->query('select my_field from my_test_table') as $row) {
var_dump($row);
}

$dbh->exec('drop table my_test_table');
?>


ACTUAL OUTPUT:

array(2) {
  ["MY_FIELD"]=>
  string(3) "foo"
  [0]=>
  string(3) "foo"
}
array(2) {
  ["MY_FIELD"]=>
  string(4) "??? "
  [0]=>
  string(4) "??? "
}


EXPECTED OUTPUT:

array(2) {
  ["MY_FIELD"]=>
  string(3) "foo"
  [0]=>
  string(3) "foo"
}
array(2) {
  ["MY_FIELD"]=>
  string(4) "日本語 "
  [0]=>
  string(4) "日本語 "
}



[2007-06-05 16:23:00] [EMAIL PROTECTED]

I'm also having the same problem in PHP 5.2.2. I've set
NLS_LANG=AMERICAN_AMERICA.AL32UTF8 and my PDO DSN is
oci:dbname=foo;charset=UTF-8. These don't seem to have any affect. The
characters I send to the DB through PDO_OCI are still getting converted
to ???. The DB charset is AL32UTF8. I'm using Linux.

When I change the DSN charset to AL32UTF8, then there is no output on
the page, nor are there errors reported in the error log. PHP appears to
crash but gives no response as to why.



[2006-03-20 15:29:43] mauroi at digbang dot com

I've tried but the same happens.
I've also tried the complete NLS_LANG (AMERICAN_AMERICA.AL32UTF8) with
no success.

Thanks!



[2006-03-20 15:25:04] [EMAIL PROTECTED]

Try with "AL32UTF8" instead of "UTF-8".



[2006-03-20 15:22:13] mauroi at digbang dot com

Description:

I'm trying to use a AL32UTF8 database with PDO, but it seems that the
charset is not correctly set (I get funny characters in the output).
I've tried the method described in
(http://www.oracle.com/technology/pub/articles/php_experts/otn_pdo_oracle5.html)
with no success.
I'm using Oracle instant client for Windows.

Reproduce code:
---
sql:

create table foo (field varchar(10));

php:

$a = new PDO('oci:dbname=server;charset=UTF-8', 'user', 'password');

$a->beginTransaction();

$b = $a->prepare('insert into foo (field) values (?)');
$b->bindValue(1, 'áéíóú');
$b->execute();

$c = $a->prepare('select * from foo');
$c->execute();
var_dump($c->fetchAll());

$a->rollBack();

Expected result:

the result with the row with áéíóú correctly displayed






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

#36797 [Asn]: Problem using UTF-8 database with pdo_oci

2007-06-05 Thread ramsey

 ID:   36797
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mauroi at digbang dot com
 Status:   Assigned
 Bug Type: PDO related
 Operating System: Win XP SP2
 PHP Version:  5.1.2
 Assigned To:  wez
 New Comment:

Here's some more reproduce code:

setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

// Create table
$dbh->exec('create table my_test_table(my_field varchar2(100))');

// Insert data
$dbh->exec('insert into my_test_table(my_field) values (\'foo\')');
$dbh->exec('insert into my_test_table(my_field) values
(\'日本語 \')');

// Get data
foreach ($dbh->query('select my_field from my_test_table') as $row) {
var_dump($row);
}

$dbh->exec('drop table my_test_table');
?>


ACTUAL OUTPUT:

array(2) {
  ["MY_FIELD"]=>
  string(3) "foo"
  [0]=>
  string(3) "foo"
}
array(2) {
  ["MY_FIELD"]=>
  string(4) "??? "
  [0]=>
  string(4) "??? "
}


EXPECTED OUTPUT:

array(2) {
  ["MY_FIELD"]=>
  string(3) "foo"
  [0]=>
  string(3) "foo"
}
array(2) {
  ["MY_FIELD"]=>
  string(4) "日本語 "
  [0]=>
  string(4) "日本語 "
}


Previous Comments:


[2007-06-05 16:23:00] [EMAIL PROTECTED]

I'm also having the same problem in PHP 5.2.2. I've set
NLS_LANG=AMERICAN_AMERICA.AL32UTF8 and my PDO DSN is
oci:dbname=foo;charset=UTF-8. These don't seem to have any affect. The
characters I send to the DB through PDO_OCI are still getting converted
to ???. The DB charset is AL32UTF8. I'm using Linux.

When I change the DSN charset to AL32UTF8, then there is no output on
the page, nor are there errors reported in the error log. PHP appears to
crash but gives no response as to why.



[2006-03-20 15:29:43] mauroi at digbang dot com

I've tried but the same happens.
I've also tried the complete NLS_LANG (AMERICAN_AMERICA.AL32UTF8) with
no success.

Thanks!



[2006-03-20 15:25:04] [EMAIL PROTECTED]

Try with "AL32UTF8" instead of "UTF-8".



[2006-03-20 15:22:13] mauroi at digbang dot com

Description:

I'm trying to use a AL32UTF8 database with PDO, but it seems that the
charset is not correctly set (I get funny characters in the output).
I've tried the method described in
(http://www.oracle.com/technology/pub/articles/php_experts/otn_pdo_oracle5.html)
with no success.
I'm using Oracle instant client for Windows.

Reproduce code:
---
sql:

create table foo (field varchar(10));

php:

$a = new PDO('oci:dbname=server;charset=UTF-8', 'user', 'password');

$a->beginTransaction();

$b = $a->prepare('insert into foo (field) values (?)');
$b->bindValue(1, 'áéíóú');
$b->execute();

$c = $a->prepare('select * from foo');
$c->execute();
var_dump($c->fetchAll());

$a->rollBack();

Expected result:

the result with the row with áéíóú correctly displayed






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

#36797 [Asn]: Problem using UTF-8 database with pdo_oci

2007-06-05 Thread ramsey

 ID:   36797
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mauroi at digbang dot com
 Status:   Assigned
 Bug Type: PDO related
 Operating System: Win XP SP2
 PHP Version:  5.1.2
 Assigned To:  wez
 New Comment:

I'm also having the same problem in PHP 5.2.2. I've set
NLS_LANG=AMERICAN_AMERICA.AL32UTF8 and my PDO DSN is
oci:dbname=foo;charset=UTF-8. These don't seem to have any affect. The
characters I send to the DB through PDO_OCI are still getting converted
to ???. The DB charset is AL32UTF8. I'm using Linux.

When I change the DSN charset to AL32UTF8, then there is no output on
the page, nor are there errors reported in the error log. PHP appears to
crash but gives no response as to why.


Previous Comments:


[2006-03-20 15:29:43] mauroi at digbang dot com

I've tried but the same happens.
I've also tried the complete NLS_LANG (AMERICAN_AMERICA.AL32UTF8) with
no success.

Thanks!



[2006-03-20 15:25:04] [EMAIL PROTECTED]

Try with "AL32UTF8" instead of "UTF-8".



[2006-03-20 15:22:13] mauroi at digbang dot com

Description:

I'm trying to use a AL32UTF8 database with PDO, but it seems that the
charset is not correctly set (I get funny characters in the output).
I've tried the method described in
(http://www.oracle.com/technology/pub/articles/php_experts/otn_pdo_oracle5.html)
with no success.
I'm using Oracle instant client for Windows.

Reproduce code:
---
sql:

create table foo (field varchar(10));

php:

$a = new PDO('oci:dbname=server;charset=UTF-8', 'user', 'password');

$a->beginTransaction();

$b = $a->prepare('insert into foo (field) values (?)');
$b->bindValue(1, 'áéíóú');
$b->execute();

$c = $a->prepare('select * from foo');
$c->execute();
var_dump($c->fetchAll());

$a->rollBack();

Expected result:

the result with the row with áéíóú correctly displayed






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

#34089 [Opn]: Configure fails build test for libxml2

2006-10-03 Thread ramsey

 ID:   34089
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Compile Failure
 Operating System: Mac OS X 10.4.8
 PHP Version:  6CVS-2006-10-03
 New Comment:

After an IRC conversation with Andrei, I recompiled ICU so that it did
not have --prefix=/usr/local/icu in the configure line. This put ICU in
a standard location. Then, I recompiled PHP with the following configure
line:

./configure --prefix=/Users/ramsey/Documents/Projects/PHP/build
--enable-debug --with-layout=PHP --without-mysql --disable-cgi
--with-libxml-dir=/sw --with-zlib --disable-pdo --without-sqlite
--enable-unicode

Configure, make, and make install went just fine.

Then, running "php6 -v" from the command line produced:
PHP 6.0.0-dev (cli) (built: Oct  3 2006 19:29:23) (DEBUG)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v3.0.0-dev, Copyright (c) 1998-2006 Zend Technologies

Perfect!

So, apparently, configure has a problem with finding ICU in a
non-standard location, even in specifying --with-icu-dir.


Previous Comments:


[2006-10-03 22:59:20] [EMAIL PROTECTED]

So, the last time I tried this was about a year ago. I decided to try
it again. Last time was with 6CVS-2005-10-17 and Mac OS X 10.4.2; now
it's with 6CVS-2006-10-03 and Mac OS X 10.4.8.

I have ICU 3.6 installed at /usr/local/icu

I'm using the following configure line:

./configure --with-layout=PHP
--prefix=/Users/ramsey/Documents/Projects/PHP/build
--with-libxml-dir=/sw --with-icu-dir=/usr/local/icu

(Note that I'm using libxml 2.6.22, installed through Fink, so it's at
/sw.)

When I run configure, I get the following error:

checking whether libxml build works... no
configure: error: build test failed.  Please check the config.log for
details.

The config.log reveals the following:

configure:27084: checking for location of ICU headers and libraries
configure:27123: result: found in /usr/local/icu
configure:27126: checking for ICU 3.4 or greater
configure:27134: result: found 3.6
configure:27266: result: 
configure:27268: result: [1mConfiguring extensions[m
configure:27285: checking whether to enable LIBXML support
configure:27323: result: yes
configure:27332: checking libxml2 install dir
configure:27350: result: /sw
configure:27362: checking for xml2-config path
configure:27376: result: /sw/bin/xml2-config
configure:27519: checking whether libxml build works
configure:27551: gcc -o conftest -g -O2  -no-cpp-precomp 
-L/usr/local/icu/lib -L/usr/local/icu/lib -L/sw/lib -L/sw/lib
conftest.c 
  
 -lm  -lm -licui18n -licuuc -licudata -lm -licuio -lxml2 -lz
-liconv -lm >&5
configure:27554: $? = 0
configure:27556: ./conftest
dyld: Library not loaded: libicui18n.dylib.36
  Referenced from:
/Users/ramsey/Documents/Projects/PHP/php-src/./conftest
  Reason: image not found
./configure: line 1:  1070 Trace/BPT trap 
./conftest$ac_exeext
configure:27559: $? = 133
configure: program exited with status 133
configure: failed program was:
| /* confdefs.h.  */
| 
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define YYTEXT_POINTER 1
| #define BIND_8_COMPAT 1
| #define HAVE_SOCKLEN_T 1
| #define HAVE_SOCKADDR_UN_SUN_LEN 1
| #define PHP_WRITE_STDOUT 1
| #define HAVE_SENDMAIL 1
| #define HAVE_SOCKET 1
| #define HAVE_SOCKETPAIR 1
| #define HAVE_HTONL 1
| #define HAVE_GETHOSTNAME 1
| #define HAVE_GETHOSTBYADDR 1
| #define HAVE_YP_GET_DEFAULT_DOMAIN 1
| #define HAVE_DLOPEN 1
| #define HAVE_LIBDL 1
| #define HAVE_LIBM 1
| #define HAVE_RES_SEARCH 1
| #define HAVE_INET_ATON 1
| #define HAVE_DN_SKIPNAME 1
| #define STDC_HEADERS 1
| #define HAVE_DIRENT_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_DIRENT_H 1
| #define HAVE_APPLICATIONSERVICES_APPLICATIONSERVICES_H 1
| #define HAVE_SYS_PARAM_H 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_TIME_H 1
| #define HAVE_NETINET_IN_H 1
| #define HAVE_ALLOCA_H 1
| #define HAVE_ARPA_INET_H 1
| #define HAVE_ARPA_NAMESER_H 1
| #define HAVE_ASSERT_H 1
| #define HAVE_FCNTL_H 1
| #define HAVE_GRP_H 1
| #define HAVE_LANGINFO_H 1
| #define HAVE_LIMITS_H 1
| #define HAVE_LOCALE_H 1
| #define HAVE_MONETARY_H 1
| #define HAVE_MACH_O_DYLD_H 1
| #define HAVE_NETDB_H 1
| #define HAVE_PWD_H 1
| #define HAVE_RESOLV_H 1
| #define HAVE_SIGNAL_H 1
| #define HAVE_STDARG_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_SYSLOG_H 1
| #define HAVE_SYSEXITS_H 1
| #define HAVE_SYS_IOCTL_H 1
| #define HAVE_SYS_FILE_H 1
| #define HAVE_SYS_MMAN_H 1
| #define HAVE_SYS_MOUNT_H 1
| #define HAVE_SYS_POLL_H 1
| #define HAVE_SYS_RESOURCE_H 1
| #define HAVE_SYS_SELECT_H 1
| #define HAVE_SYS_SOCKET_H 1
| #define HAVE_SYS_STATVFS_H 1
| #define HAVE_SYS_WAIT_H 1

#34089 [NoF->Opn]: Configure fails build test for libxml2

2006-10-03 Thread ramsey

 ID:   34089
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   No Feedback
+Status:   Open
 Bug Type: Compile Failure
-Operating System: Mac OS X 10.4.2
+Operating System: Mac OS X 10.4.8
-PHP Version:  6CVS-2005-10-07
+PHP Version:  6CVS-2006-10-03
 New Comment:

So, the last time I tried this was about a year ago. I decided to try
it again. Last time was with 6CVS-2005-10-17 and Mac OS X 10.4.2; now
it's with 6CVS-2006-10-03 and Mac OS X 10.4.8.

I have ICU 3.6 installed at /usr/local/icu

I'm using the following configure line:

./configure --with-layout=PHP
--prefix=/Users/ramsey/Documents/Projects/PHP/build
--with-libxml-dir=/sw --with-icu-dir=/usr/local/icu

(Note that I'm using libxml 2.6.22, installed through Fink, so it's at
/sw.)

When I run configure, I get the following error:

checking whether libxml build works... no
configure: error: build test failed.  Please check the config.log for
details.

The config.log reveals the following:

configure:27084: checking for location of ICU headers and libraries
configure:27123: result: found in /usr/local/icu
configure:27126: checking for ICU 3.4 or greater
configure:27134: result: found 3.6
configure:27266: result: 
configure:27268: result: [1mConfiguring extensions[m
configure:27285: checking whether to enable LIBXML support
configure:27323: result: yes
configure:27332: checking libxml2 install dir
configure:27350: result: /sw
configure:27362: checking for xml2-config path
configure:27376: result: /sw/bin/xml2-config
configure:27519: checking whether libxml build works
configure:27551: gcc -o conftest -g -O2  -no-cpp-precomp 
-L/usr/local/icu/lib -L/usr/local/icu/lib -L/sw/lib -L/sw/lib
conftest.c 
  
 -lm  -lm -licui18n -licuuc -licudata -lm -licuio -lxml2 -lz
-liconv -lm >&5
configure:27554: $? = 0
configure:27556: ./conftest
dyld: Library not loaded: libicui18n.dylib.36
  Referenced from:
/Users/ramsey/Documents/Projects/PHP/php-src/./conftest
  Reason: image not found
./configure: line 1:  1070 Trace/BPT trap 
./conftest$ac_exeext
configure:27559: $? = 133
configure: program exited with status 133
configure: failed program was:
| /* confdefs.h.  */
| 
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define YYTEXT_POINTER 1
| #define BIND_8_COMPAT 1
| #define HAVE_SOCKLEN_T 1
| #define HAVE_SOCKADDR_UN_SUN_LEN 1
| #define PHP_WRITE_STDOUT 1
| #define HAVE_SENDMAIL 1
| #define HAVE_SOCKET 1
| #define HAVE_SOCKETPAIR 1
| #define HAVE_HTONL 1
| #define HAVE_GETHOSTNAME 1
| #define HAVE_GETHOSTBYADDR 1
| #define HAVE_YP_GET_DEFAULT_DOMAIN 1
| #define HAVE_DLOPEN 1
| #define HAVE_LIBDL 1
| #define HAVE_LIBM 1
| #define HAVE_RES_SEARCH 1
| #define HAVE_INET_ATON 1
| #define HAVE_DN_SKIPNAME 1
| #define STDC_HEADERS 1
| #define HAVE_DIRENT_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_DIRENT_H 1
| #define HAVE_APPLICATIONSERVICES_APPLICATIONSERVICES_H 1
| #define HAVE_SYS_PARAM_H 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_TIME_H 1
| #define HAVE_NETINET_IN_H 1
| #define HAVE_ALLOCA_H 1
| #define HAVE_ARPA_INET_H 1
| #define HAVE_ARPA_NAMESER_H 1
| #define HAVE_ASSERT_H 1
| #define HAVE_FCNTL_H 1
| #define HAVE_GRP_H 1
| #define HAVE_LANGINFO_H 1
| #define HAVE_LIMITS_H 1
| #define HAVE_LOCALE_H 1
| #define HAVE_MONETARY_H 1
| #define HAVE_MACH_O_DYLD_H 1
| #define HAVE_NETDB_H 1
| #define HAVE_PWD_H 1
| #define HAVE_RESOLV_H 1
| #define HAVE_SIGNAL_H 1
| #define HAVE_STDARG_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_SYSLOG_H 1
| #define HAVE_SYSEXITS_H 1
| #define HAVE_SYS_IOCTL_H 1
| #define HAVE_SYS_FILE_H 1
| #define HAVE_SYS_MMAN_H 1
| #define HAVE_SYS_MOUNT_H 1
| #define HAVE_SYS_POLL_H 1
| #define HAVE_SYS_RESOURCE_H 1
| #define HAVE_SYS_SELECT_H 1
| #define HAVE_SYS_SOCKET_H 1
| #define HAVE_SYS_STATVFS_H 1
| #define HAVE_SYS_WAIT_H 1
| #define HAVE_TERMIOS_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_UTIME_H 1
| #define HAVE_SYS_UTSNAME_H 1
| #define HAVE_SYS_IPC_H 1
| #define HAVE_DLFCN_H 1
| #define HAVE_ASSERT_H 1
| #define HAVE_STRUCT_TM_TM_ZONE 1
| #define HAVE_TM_ZONE 1
| #define MISSING_FCLOSE_DECL 0
| #define HAVE_TM_GMTOFF 1
| #define HAVE_STRUCT_FLOCK 1
| #define HAVE_SOCKLEN_T 1
| #define SIZEOF_INTMAX_T 8
| #define SIZEOF_SIZE_T 4
| #define SIZEOF_SSIZE_T 4
| #define SIZEOF_PTRDIFF_T 4
| #define SIZEOF_LONG_LONG 8
| #define SIZEOF_LONG_LONG_INT 8
| #define SIZEOF_LONG 4
| #define SIZEOF_INT 4
| #define HAVE_SOCKADDR_STORAGE 1
| #define HAVE_SOCKADDR_SA_LEN 1
| #define HAVE_VPRINTF 1
| #define HAVE_ALPHASORT 1
| #define HAVE_ASCTIME_R 1
| #define HAVE_CHROOT 1
| #define HAVE_CTIME_R 1
| #define HAVE_CRYPT 1
| #define HAVE_FLOCK 1
| #define HAVE_FTOK 1
| #define HAVE_FUNOPEN 1
| #define HA

#37368 [Asn]: Incorrect timestamp returned for strtotime()

2006-05-24 Thread ramsey

 ID:   37368
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Assigned
 Bug Type: Date/time related
 Operating System: Debian sarge
 PHP Version:  5.1.4
 Assigned To:  derick
 New Comment:

Actually, I meant that I expect the output to be (Wed should be changed
to Mon):

Mon, 08 May 2006 00:00:00 -0400
Mon, 15 May 2006 00:00:00 -0400
Mon, 22 May 2006 00:00:00 -0400
Mon, 29 May 2006 00:00:00 -0400
Mon, 05 Jun 2006 00:00:00 -0400


Previous Comments:


[2006-05-24 21:34:23] [EMAIL PROTECTED]

I'm not sure whether this is related, but I found a new issue with
strtotime(). It looks like the words "second" and "third" are not
working correctly. 

Reproduce code:
echo date('r', strtotime('May 1st first Monday')) . "\n";
echo date('r', strtotime('May 1st second Monday')) . "\n";
echo date('r', strtotime('May 1st third Monday')) . "\n";
echo date('r', strtotime('May 1st fourth Monday')) . "\n";
echo date('r', strtotime('May 1st fifth Monday')) . "\n";

I expect the output to be:

Mon, 08 May 2006 00:00:00 -0400
Wed, 15 May 2006 00:00:00 -0400
Wed, 22 May 2006 00:00:00 -0400
Mon, 29 May 2006 00:00:00 -0400
Mon, 05 Jun 2006 00:00:00 -0400

but the actual output (with PHP 5.1.4) is:

Mon, 08 May 2006 00:00:00 -0400
Wed, 31 Dec 1969 19:00:00 -0500
Wed, 31 Dec 1969 19:00:00 -0500
Mon, 29 May 2006 00:00:00 -0400
Mon, 05 Jun 2006 00:00:00 -0400

With PHP 4.4.2, the actual output is:

Tue, 01 May 2001 00:00:00 -0400
Mon, 01 May 2006 00:00:01 -0400
Thu, 01 May 2003 00:00:00 -0400
Sat, 01 May 2004 00:00:00 -0400
Sun, 01 May 2005 00:00:00 -0400



[2006-05-14 17:35:45] [EMAIL PROTECTED]

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.





[2006-05-08 17:16:01] [EMAIL PROTECTED]

Description:

When using strtotime() in PHP 5.1.4, it returns an inaccurate
timestamp, but PHP 5.0.4 and 4.4.2 return the correct timestamp.

Reproduce code:
---
php -r 'echo date("r", strtotime("Mon, 08 May 2006 13:06:44 -0400 +30
days"));'

Expected result:

Wed, 07 Jun 2006 13:06:44 -0400

Actual result:
--
Mon, 12 Jun 2006 13:06:44 -0400





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

#37368 [Csd->Opn]: Incorrect timestamp returned for strtotime()

2006-05-24 Thread ramsey

 ID:   37368
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Closed
+Status:   Open
 Bug Type: Date/time related
 Operating System: Debian sarge
 PHP Version:  5.1.4
 Assigned To:  derick
 New Comment:

I'm not sure whether this is related, but I found a new issue with
strtotime(). It looks like the words "second" and "third" are not
working correctly. 

Reproduce code:
echo date('r', strtotime('May 1st first Monday')) . "\n";
echo date('r', strtotime('May 1st second Monday')) . "\n";
echo date('r', strtotime('May 1st third Monday')) . "\n";
echo date('r', strtotime('May 1st fourth Monday')) . "\n";
echo date('r', strtotime('May 1st fifth Monday')) . "\n";

I expect the output to be:

Mon, 08 May 2006 00:00:00 -0400
Wed, 15 May 2006 00:00:00 -0400
Wed, 22 May 2006 00:00:00 -0400
Mon, 29 May 2006 00:00:00 -0400
Mon, 05 Jun 2006 00:00:00 -0400

but the actual output (with PHP 5.1.4) is:

Mon, 08 May 2006 00:00:00 -0400
Wed, 31 Dec 1969 19:00:00 -0500
Wed, 31 Dec 1969 19:00:00 -0500
Mon, 29 May 2006 00:00:00 -0400
Mon, 05 Jun 2006 00:00:00 -0400

With PHP 4.4.2, the actual output is:

Tue, 01 May 2001 00:00:00 -0400
Mon, 01 May 2006 00:00:01 -0400
Thu, 01 May 2003 00:00:00 -0400
Sat, 01 May 2004 00:00:00 -0400
Sun, 01 May 2005 00:00:00 -0400


Previous Comments:


[2006-05-14 17:35:45] [EMAIL PROTECTED]

This bug has been fixed in CVS.

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/.
 
Thank you for the report, and for helping us make PHP better.





[2006-05-08 17:16:01] [EMAIL PROTECTED]

Description:

When using strtotime() in PHP 5.1.4, it returns an inaccurate
timestamp, but PHP 5.0.4 and 4.4.2 return the correct timestamp.

Reproduce code:
---
php -r 'echo date("r", strtotime("Mon, 08 May 2006 13:06:44 -0400 +30
days"));'

Expected result:

Wed, 07 Jun 2006 13:06:44 -0400

Actual result:
--
Mon, 12 Jun 2006 13:06:44 -0400





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

#34087 [Opn->Bgs]: strtotime() does not work with date format "Y/m/d"

2005-08-11 Thread ramsey

 ID:   34087
 Updated by:   [EMAIL PROTECTED]
 Reported By:  osmium at 163 dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Date/time related
 Operating System: Windows Server 2003
 PHP Version:  5.1.0b3
 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

The manual states that strtotime() parses a date/time string according
to the GNU Date Input Formats syntax. The format "Y/m/d" is not a
supported GNU date input format (see the link below).

http://www.php.net/strtotime
http://www.gnu.org/software/tar/manual/html_chapter/tar_7.html


Previous Comments:


[2005-08-12 03:08:37] osmium at 163 dot com

Description:

I got nothing on the first line but a number "1123804800" on the second
line. Maybe format "Y/m/d" is not supported by strtotime().

However, I got two numbers in v5.0.3

Reproduce code:
---
";
echo "Y-m-d: ", strtotime("2005-8-12");
?>

Expected result:

Y/m/d: 1123804800
Y-m-d: 1123804800

Actual result:
--
Y/m/d: 
Y-m-d: 1123804800





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

#32074 [Opn]: OID's missing from PHP snmpwalk compared with command line snmpwalk

2005-02-23 Thread Gregg dot Nelson at Co dot Ramsey dot MN dot US

 ID:   32074
 User updated by:  Gregg dot Nelson at Co dot Ramsey dot MN dot US
 Reported By:  Gregg dot Nelson at Co dot Ramsey dot MN dot US
 Status:   Open
 Bug Type: SNMP related
 Operating System: ReHat 9.0
 PHP Version:  5.0.3
 New Comment:

After a more careful comparison of the command line snmpwalk and the
PHP snmpwalk it appears the items missing from the PHP snmpwalk are the
Counter64 items.


Previous Comments:


[2005-02-23 21:18:48] Gregg dot Nelson at Co dot Ramsey dot MN dot US

The following bash script shows that snmpwalk and snmpget/getnext
produce the same number of lines and output
when called from the command line

#!/bin/bash
#
#   Compare snmpwalk and snmpget/getnext output. 
#
#set -vx
walkoid="SNMPv2-SMI::enterprises.9.9.161"
lc=$(snmpwalk -v2c -crmsy 192.168.108.254 $walkoid|wc -l)
echo snmpwalk: $lc lines.
startmib="$walkoid.1.1.1.1.2.0"
nextmib=$startmib
oper="snmpget";lc=0
while :; do
mib=$($oper -v2c -crmsy 192.168.108.254 $nextmib)
oper="snmpgetnext"
if [ $(echo $mib|grep ".9.9.161"|wc -l) -eq 0 ];then break;fi
#   echo $mib
let lc=lc+1
nextmib=${mib%%\ =\ *}
done
echo snmpget/next: $lc lines.
exit



[2005-02-23 04:38:59] Gregg dot Nelson at Co dot Ramsey dot MN dot US

Description:

Running:

PHP-5.0.3
Net-SNMP-5.2.1
Apache-(httpd-2.0.530)

PHP config Line

./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-snmp

No changes to php.ini
---

Executing snmpwalk from command line (RH Linux 9) produces different
results from snmpwalk called from php.

I have a Cisco 6509 configured for Server Load Balancing.
The MIB tree for this starts at OID .1.3.6.1.4.1.9.9.161

With the following command from the Linux shell I get the folowing
results:
---
 snmpwalk -v2c -crmsy 192.168.108.254 .1.3.6.1.4.1.9.9.161

SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.2.0 = Counter32: 49602212
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.3.0 = Counter64: 49602212
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.4.0 = Counter32: 2776480
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.5.0 = Counter64: 2776480
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.6.0 = Counter32: 26014
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.7.0 = Counter64: 26014
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.8.0 = Counter32: 26013
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.9.0 = Counter64: 26013
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.10.0 = Counter32: 26014
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.11.0 = Counter64: 26014
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.12.0 = Counter32: 6
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.13.0 = Counter64: 6
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.14.0 = Counter32: 0
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.15.0 = Counter64: 0
SNMPv2-SMI::enterprises.9.9.161.1.2.1.1.2.0.8.67.65.70.69.84.69.83.84 =
INTEGER: 1
SNMPv2-SMI::enterprises.9.9.161.1.2.1.1.3.0.8.67.65.70.69.84.69.83.84 =
INTEGER: 3
SNMPv2-SMI::enterprises.9.9.161.1.2.1.1.4.0.8.67.65.70.69.84.69.83.84 =
Gauge32: 2
SNMPv2-SMI::enterprises.9.9.161.1.2.1.1.5.0.8.67.65.70.69.84.69.83.84 =
Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.2.1.1.6.0.8.67.65.70.69.84.69.83.84 =
INTEGER: 1
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.4.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= INTEGER: 2
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.4.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= INTEGER: 2
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.5.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.5.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.6.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.6.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.7.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 4294967295
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.7.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 4294967295
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.8.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 8
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.8.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 8
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.9.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 8
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.9.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 8
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.10.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.10.0.8.67.65.70.69.84.69.83.84.192

#32074 [Opn]: OID's missing from PHP snmpwalk compared with command line snmpwalk

2005-02-23 Thread Gregg dot Nelson at Co dot Ramsey dot MN dot US

 ID:   32074
 User updated by:  Gregg dot Nelson at Co dot Ramsey dot MN dot US
 Reported By:  Gregg dot Nelson at Co dot Ramsey dot MN dot US
 Status:   Open
 Bug Type: SNMP related
 Operating System: ReHat 9.0
 PHP Version:  5.0.3
 New Comment:

The following bash script shows that snmpwalk and snmpget/getnext
produce the same number of lines and output
when called from the command line

#!/bin/bash
#
#   Compare snmpwalk and snmpget/getnext output. 
#
#set -vx
walkoid="SNMPv2-SMI::enterprises.9.9.161"
lc=$(snmpwalk -v2c -crmsy 192.168.108.254 $walkoid|wc -l)
echo snmpwalk: $lc lines.
startmib="$walkoid.1.1.1.1.2.0"
nextmib=$startmib
oper="snmpget";lc=0
while :; do
mib=$($oper -v2c -crmsy 192.168.108.254 $nextmib)
oper="snmpgetnext"
if [ $(echo $mib|grep ".9.9.161"|wc -l) -eq 0 ];then break;fi
#   echo $mib
let lc=lc+1
nextmib=${mib%%\ =\ *}
done
echo snmpget/next: $lc lines.
exit


Previous Comments:


[2005-02-23 04:38:59] Gregg dot Nelson at Co dot Ramsey dot MN dot US

Description:

Running:

PHP-5.0.3
Net-SNMP-5.2.1
Apache-(httpd-2.0.530)

PHP config Line

./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-snmp

No changes to php.ini
---

Executing snmpwalk from command line (RH Linux 9) produces different
results from snmpwalk called from php.

I have a Cisco 6509 configured for Server Load Balancing.
The MIB tree for this starts at OID .1.3.6.1.4.1.9.9.161

With the following command from the Linux shell I get the folowing
results:
---
 snmpwalk -v2c -crmsy 192.168.108.254 .1.3.6.1.4.1.9.9.161

SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.2.0 = Counter32: 49602212
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.3.0 = Counter64: 49602212
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.4.0 = Counter32: 2776480
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.5.0 = Counter64: 2776480
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.6.0 = Counter32: 26014
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.7.0 = Counter64: 26014
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.8.0 = Counter32: 26013
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.9.0 = Counter64: 26013
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.10.0 = Counter32: 26014
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.11.0 = Counter64: 26014
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.12.0 = Counter32: 6
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.13.0 = Counter64: 6
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.14.0 = Counter32: 0
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.15.0 = Counter64: 0
SNMPv2-SMI::enterprises.9.9.161.1.2.1.1.2.0.8.67.65.70.69.84.69.83.84 =
INTEGER: 1
SNMPv2-SMI::enterprises.9.9.161.1.2.1.1.3.0.8.67.65.70.69.84.69.83.84 =
INTEGER: 3
SNMPv2-SMI::enterprises.9.9.161.1.2.1.1.4.0.8.67.65.70.69.84.69.83.84 =
Gauge32: 2
SNMPv2-SMI::enterprises.9.9.161.1.2.1.1.5.0.8.67.65.70.69.84.69.83.84 =
Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.2.1.1.6.0.8.67.65.70.69.84.69.83.84 =
INTEGER: 1
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.4.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= INTEGER: 2
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.4.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= INTEGER: 2
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.5.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.5.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.6.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.6.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.7.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 4294967295
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.7.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 4294967295
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.8.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 8
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.8.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 8
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.9.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 8
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.9.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 8
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.10.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.10.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.11.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 1
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.11.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 1
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.12.0.8.67.65.70.69.84.6

#32074 [NEW]: OID's missing from PHP snmpwalk compared with command line snmpwalk

2005-02-22 Thread Gregg dot Nelson at Co dot Ramsey dot MN dot US

From: Gregg dot Nelson at Co dot Ramsey dot MN dot US
Operating system: ReHat 9.0
PHP version:  5.0.3
PHP Bug Type: SNMP related
Bug description:  OID's missing from PHP snmpwalk compared with command line 
snmpwalk

Description:

Running:

PHP-5.0.3
Net-SNMP-5.2.1
Apache-(httpd-2.0.530)

PHP config Line

./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-snmp

No changes to php.ini
---

Executing snmpwalk from command line (RH Linux 9) produces different
results from snmpwalk called from php.

I have a Cisco 6509 configured for Server Load Balancing.
The MIB tree for this starts at OID .1.3.6.1.4.1.9.9.161

With the following command from the Linux shell I get the folowing
results:
---
 snmpwalk -v2c -crmsy 192.168.108.254 .1.3.6.1.4.1.9.9.161

SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.2.0 = Counter32: 49602212
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.3.0 = Counter64: 49602212
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.4.0 = Counter32: 2776480
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.5.0 = Counter64: 2776480
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.6.0 = Counter32: 26014
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.7.0 = Counter64: 26014
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.8.0 = Counter32: 26013
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.9.0 = Counter64: 26013
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.10.0 = Counter32: 26014
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.11.0 = Counter64: 26014
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.12.0 = Counter32: 6
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.13.0 = Counter64: 6
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.14.0 = Counter32: 0
SNMPv2-SMI::enterprises.9.9.161.1.1.1.1.15.0 = Counter64: 0
SNMPv2-SMI::enterprises.9.9.161.1.2.1.1.2.0.8.67.65.70.69.84.69.83.84 =
INTEGER: 1
SNMPv2-SMI::enterprises.9.9.161.1.2.1.1.3.0.8.67.65.70.69.84.69.83.84 =
INTEGER: 3
SNMPv2-SMI::enterprises.9.9.161.1.2.1.1.4.0.8.67.65.70.69.84.69.83.84 =
Gauge32: 2
SNMPv2-SMI::enterprises.9.9.161.1.2.1.1.5.0.8.67.65.70.69.84.69.83.84 =
Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.2.1.1.6.0.8.67.65.70.69.84.69.83.84 =
INTEGER: 1
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.4.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= INTEGER: 2
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.4.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= INTEGER: 2
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.5.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.5.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.6.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.6.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.7.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 4294967295
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.7.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 4294967295
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.8.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 8
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.8.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 8
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.9.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 8
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.9.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 8
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.10.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.10.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.11.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 1
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.11.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 1
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.12.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= INTEGER: 360
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.12.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= INTEGER: 360
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.13.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 1
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.13.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 1
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.14.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 1
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.14.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 1
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.15.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.15.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Gauge32: 0
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.16.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= Counter32: 5
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.16.0.8.67.65.70.69.84.69.83.84.192.168.110.46.0
= Counter32: 2
SNMPv2-SMI::enterprises.9.9.161.1.3.1.1.17.0.8.67.65.70.69.84.69.83.84.192.168.110.15.0
= INTEG

Req #64493 [Asn]: array_column: 2nd param should be optional to use entire rows as result values

Bug #61336 [Opn]: file_get_contents() no longer returns false on 4xx responses

Bug #61336 [Opn]: file_get_contents() no longer returns false on 4xx responses

Bug #61336 [Opn]: file_get_contents() no longer returns false on 4xx responses

Bug #61336 [Fbk->Opn]: file_get_contents() no longer returns false on 4xx responses

#50291 [Csd->Opn]: incorrect usage of autoconf diversions

#48795 [Ver]: Building intl 64-bit fails on OS X

#49242 [Fbk]: Expose function in Zend API for comparing arrays by identity

#49242 [Opn]: Expose function in Zend API for comparing arrays by identity

#44462 [Opn]: Can not compile embed sapi on OSX

#44462 [NoF->Opn]: Can not compile embed sapi on OSX

#48837 [Fbk]: Building --with-curlwrappers can cause bad/illegal format or missing URL errors

#36797 [Asn]: Problem using UTF-8 database with pdo_oci

#36797 [Asn]: Problem using UTF-8 database with pdo_oci

#36797 [Asn]: Problem using UTF-8 database with pdo_oci

#36797 [Asn]: Problem using UTF-8 database with pdo_oci

#36797 [Asn]: Problem using UTF-8 database with pdo_oci

#34089 [Opn]: Configure fails build test for libxml2

#34089 [NoF->Opn]: Configure fails build test for libxml2

#37368 [Asn]: Incorrect timestamp returned for strtotime()

#37368 [Csd->Opn]: Incorrect timestamp returned for strtotime()

#34087 [Opn->Bgs]: strtotime() does not work with date format "Y/m/d"

#32074 [Opn]: OID's missing from PHP snmpwalk compared with command line snmpwalk

#32074 [Opn]: OID's missing from PHP snmpwalk compared with command line snmpwalk

#32074 [NEW]: OID's missing from PHP snmpwalk compared with command line snmpwalk

25 matches

Site Navigation

Mail list logo

Footer information