from:"cornelius dot howl at gmail dot com"

[PHP-BUG] Bug #64554 [NEW]: var_export does not export absolute namespace for classname

2013-03-30 Thread cornelius dot howl at gmail dot com

From: cornelius dot howl at gmail dot com
Operating system: Any
PHP version:  5.4.13
Package:  *General Issues
Bug Type: Bug
Bug description:var_export does not export absolute namespace for classname 

Description:

---
>From manual page:
http://www.php.net/function.var-export#refsect1-function.var-
export-description
---

If I defined a class "Foo\Bar\C" that implements __set_state method, then
use 
var_export to export the php code, and put this exported code to another 
namespace, it will causes "class not found".

because the exported class name is "Foo\Bar\C" not "\Foo\Bar\C", the class
can not 
be found without the root namespace.  :(

var_export should always export the root namespace.


-- 
Edit bug report at https://bugs.php.net/bug.php?id=64554&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=64554&r=trysnapshot54
Try a snapshot (PHP 5.3):   
https://bugs.php.net/fix.php?id=64554&r=trysnapshot53
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=64554&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=64554&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=64554&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64554&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=64554&r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=64554&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64554&r=support
Expected behavior:  https://bugs.php.net/fix.php?id=64554&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64554&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64554&r=submittedtwice
register_globals:   https://bugs.php.net/fix.php?id=64554&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64554&r=php4
Daylight Savings:   https://bugs.php.net/fix.php?id=64554&r=dst
IIS Stability:  https://bugs.php.net/fix.php?id=64554&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64554&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64554&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64554&r=nozend
MySQL Configuration Error:  https://bugs.php.net/fix.php?id=64554&r=mysqlcfg

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

2013-03-09 Thread cornelius dot howl at gmail dot com

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

 ID: 48795
 Comment by: cornelius dot howl at gmail dot com
 Reported by:gwy...@php.net
 Summary:Building intl 64-bit fails on OS X
 Status: Verified
 Type:   Bug
 Package:Compile Failure
 Operating System:   OS X 10.5 & 10.6; Linux
 PHP Version:5.3 SVN; 5.4.0RC1
 Block user comment: N
 Private report: N

 New Comment:

For this issue, here is the patch in phpbrew 

https://github.com/c9s/phpbrew/commit/18ef766d0e013ee87ac7d86e338ebec89fbeb445


Previous Comments:

[2013-03-09 10:12:31] cornelius dot howl at gmail dot com

Quick fix for this 5.3.28 should work


edit Makefile and found the rule of

ext/intl/msgformat/msgformat_helpers.cpp

change the $(CC) to $(CXX)

then run:

sed -i '/EXTRA_LIBS = /s|$| -lstdc++|' Makefile


[2013-03-08 16:27:05] saltwaterc at gmail dot com

sed -i '/EXTRA_LIBS = /s|$| -lstdc++|' Makefile

One liner fix for those who still do (scripted) builds on 5.3.x.
5.3.22 still fails on Ubuntu 12.04.


[2012-10-26 02:59:59] pgarvin76 at gmail dot com

This is still and issue on 5.3.18, but 5.4.8 built without error. Interestingly 
if you build intl as shared you don't get the compile error (how I am currently 
getting around issue). I am on Ubuntu 12.04.


[2012-09-11 16:27:47] re...@php.net

Same for me, I can't compile either. hope there is a solution


[2012-05-08 13:11:12] k...@php.net

Also happens again with PHP 5.3.12 on Ubuntu 12.04 -- stas fix confirmed. A 
generic solution would be nice, indeed.




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=48795


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

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

2013-03-09 Thread cornelius dot howl at gmail dot com

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

 ID: 48795
 Comment by: cornelius dot howl at gmail dot com
 Reported by:gwy...@php.net
 Summary:Building intl 64-bit fails on OS X
 Status: Verified
 Type:   Bug
 Package:Compile Failure
 Operating System:   OS X 10.5 & 10.6; Linux
 PHP Version:5.3 SVN; 5.4.0RC1
 Block user comment: N
 Private report: N

 New Comment:

Quick fix for this 5.3.28 should work


edit Makefile and found the rule of

ext/intl/msgformat/msgformat_helpers.cpp

change the $(CC) to $(CXX)

then run:

sed -i '/EXTRA_LIBS = /s|$| -lstdc++|' Makefile


Previous Comments:

[2013-03-08 16:27:05] saltwaterc at gmail dot com

sed -i '/EXTRA_LIBS = /s|$| -lstdc++|' Makefile

One liner fix for those who still do (scripted) builds on 5.3.x.
5.3.22 still fails on Ubuntu 12.04.


[2012-10-26 02:59:59] pgarvin76 at gmail dot com

This is still and issue on 5.3.18, but 5.4.8 built without error. Interestingly 
if you build intl as shared you don't get the compile error (how I am currently 
getting around issue). I am on Ubuntu 12.04.


[2012-09-11 16:27:47] re...@php.net

Same for me, I can't compile either. hope there is a solution


[2012-05-08 13:11:12] k...@php.net

Also happens again with PHP 5.3.12 on Ubuntu 12.04 -- stas fix confirmed. A 
generic solution would be nice, indeed.


[2012-03-13 15:46:33] dan at cdchase dot com

It would be helpful if the build system imported any already set CFLAGS. As 
I've experienced this issue before, so I've set the appropriate CFLAGS in my 
default environment. But, the automated install routine does not honor these. I 
have to manually install for them to be honored.




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=48795


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

[PHP-BUG] Req #61298 [NEW]: Add an short alias DS for DIRECTORY_SEPARATOR

2012-03-05 Thread cornelius dot howl at gmail dot com

From: 
Operating system: 
PHP version:  5.4.0
Package:  *Directory/Filesystem functions
Bug Type: Feature/Change Request
Bug description:Add an short alias DS for DIRECTORY_SEPARATOR

Description:

Really hope there is a DS alias for DIRECTORY_SEPARATOR, and
PATH_SEPARATOR.

because it's too easy to make a typo, these keywords are hard to type.

$path = 'root' . DS . 'to' . 'path' . DS . 'subpath' . DS . 'subpath' . DS
. 
'file.txt';

rather than:

$path = 'root' . DIRECTORY_SEPARATOR . 'to' . 'path' . DIRECTORY_SEPARATOR
. 
'subpath' . DIRECTORY_SEPARATOR . 'subpath' . DIRECTORY_SEPARATOR .
'file.txt';

the later is uglier. 


-- 
Edit bug report at https://bugs.php.net/bug.php?id=61298&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61298&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61298&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=61298&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61298&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=61298&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61298&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=61298&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=61298&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=61298&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=61298&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=61298&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=61298&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=61298&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61298&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=61298&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61298&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=61298&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=61298&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=61298&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=61298&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=61298&r=mysqlcfg

Req #47615 [Com]: PDO parameter binding is in clear violation of the ISO 9075 standard

2012-03-05 Thread cornelius dot howl at gmail dot com

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

 ID: 47615
 Comment by: cornelius dot howl at gmail dot com
 Reported by:kenaniah at gmail dot com
 Summary:PDO parameter binding is in clear violation of the
 ISO 9075 standard
 Status: Open
 Type:   Feature/Change Request
 Package:PDO related
 Operating System:   *
 PHP Version:5.2.9
 Block user comment: N
 Private report: N

 New Comment:

BTW, My PHP version 5.3.10.

pdo_pgsql

PDO Driver for PostgreSQL => enabled
PostgreSQL(libpq) Version => 9.1.2
Module version => 1.0.2
Revision =>  $Id: pdo_pgsql.c 321634 2012-01-01 13:15:04Z felipe $ 

pdo_sqlite

PDO Driver for SQLite 3.x => enabled
SQLite Library => 3.7.10

pgsql

PostgreSQL Support => enabled
PostgreSQL(libpq) Version => 9.1.2
Multibyte character support => enabled
SSL support => enabled
Active Persistent Links => 0
Active Links => 0


Previous Comments:
------------
[2012-03-05 18:11:35] cornelius dot howl at gmail dot com

Same here. 


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

$db->query( <<prepare('INSERT INTO products 
( name,sn,subtitle,hide,token,price,content,spec,created_by,created_on) 
VALUES 
(:name,:sn,:subtitle,:hide,:token,:price,:content,:spec,:created_by,:created_on)
 
');
$stm->execute(array( 
  ':name' =>  'Test',
  ':sn' =>  'Test',
  ':subtitle' => '123',
  ':hide' => false,
  ':token' =>  'd862899f5c4b38f6b6a161e77c2936fb5541deb5',
  ':price' =>  0,
  ':content' => '123',
  ':spec' => '123',
  ':created_by' => 1,
  ':created_on' => '2012-03-06T01:37:50+08:00',
));

foreach( $db->query('select * from products') as $item ) {
var_dump( $item ); 
}






Which throws


PHP Fatal error:  Uncaught exception 'PDOException' with message 
'SQLSTATE[22P02]: 
Invalid text representation: 7 ERROR:  invalid input syntax for type boolean: 
""' 
in /Users/c9s/git/Work/phifty/pdo_test.php:44
Stack trace:
#0 /Users/c9s/git/Work/phifty/pdo_test.php(44): PDOStatement->execute(Array)
#1 {main}
  thrown in /Users/c9s/git/Work/phifty/pdo_test.php on line 44

Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[22P02]: 
Invalid text representation: 7 ERROR:  invalid input syntax for type boolean: 
""' 
in /Users/c9s/git/Work/phifty/pdo_test.php on line 44

PDOException: SQLSTATE[22P02]: Invalid text representation: 7 ERROR:  invalid 
input syntax for type boolean: "" in /Users/c9s/git/Work/phifty/pdo_test.php on 
line 44


[2009-03-10 18:32:51] kenaniah at gmail dot com

Description:

Referencing ISO 9075, PDO does not properly bind boolean parameters when the 
parameter type has not been made known to PDO.

According to the standard, booleans represent a truth, false, or unknown value. 
According to the SQL language definition (feel free to reference SQL-92), the 
SQL equivalents for a boolean value are TRUE, FALSE, and NULL respectively.

The PDO core should automatically convert boolean values to their proper SQL 
counterparts, and it should be the role of the client driver to deal with these 
values if the database platform in question does not support the ISO standard. 

Rather than listing workarounds, we ask that the PDO core be brought into 
compliance with the SQL standards, and that individual database drivers be 
modified to handle the cases in which their underlying database is not 
standards compliant. 

Reproduce code:
---
$res = $db->prepare('SELECT id FROM table WHERE mybool = ?');
$res->execute(array(false));

Expected result:

SQL statement sent to server:

SELECT id FROM table WHERE mybool = FALSE

(unless modified by DB driver due to a lack of standards compliance on the part 
of the DB)

Actual result:
--
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[22P02]: Invalid text representation: 7 ERROR:  invalid input
syntax for type boolean: ""' 

^^for Postgres driver (Postgres is an standard compliant DB as far as booleans 
are concerned)






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

Req #47615 [Com]: PDO parameter binding is in clear violation of the ISO 9075 standard

2012-03-05 Thread cornelius dot howl at gmail dot com

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

 ID: 47615
 Comment by: cornelius dot howl at gmail dot com
 Reported by:kenaniah at gmail dot com
 Summary:PDO parameter binding is in clear violation of the
 ISO 9075 standard
 Status: Open
 Type:   Feature/Change Request
 Package:PDO related
 Operating System:   *
 PHP Version:5.2.9
 Block user comment: N
 Private report: N

 New Comment:

Same here. 


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

$db->query( <<prepare('INSERT INTO products 
( name,sn,subtitle,hide,token,price,content,spec,created_by,created_on) 
VALUES 
(:name,:sn,:subtitle,:hide,:token,:price,:content,:spec,:created_by,:created_on)
 
');
$stm->execute(array( 
  ':name' =>  'Test',
  ':sn' =>  'Test',
  ':subtitle' => '123',
  ':hide' => false,
  ':token' =>  'd862899f5c4b38f6b6a161e77c2936fb5541deb5',
  ':price' =>  0,
  ':content' => '123',
  ':spec' => '123',
  ':created_by' => 1,
  ':created_on' => '2012-03-06T01:37:50+08:00',
));

foreach( $db->query('select * from products') as $item ) {
var_dump( $item ); 
}






Which throws


PHP Fatal error:  Uncaught exception 'PDOException' with message 
'SQLSTATE[22P02]: 
Invalid text representation: 7 ERROR:  invalid input syntax for type boolean: 
""' 
in /Users/c9s/git/Work/phifty/pdo_test.php:44
Stack trace:
#0 /Users/c9s/git/Work/phifty/pdo_test.php(44): PDOStatement->execute(Array)
#1 {main}
  thrown in /Users/c9s/git/Work/phifty/pdo_test.php on line 44

Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[22P02]: 
Invalid text representation: 7 ERROR:  invalid input syntax for type boolean: 
""' 
in /Users/c9s/git/Work/phifty/pdo_test.php on line 44

PDOException: SQLSTATE[22P02]: Invalid text representation: 7 ERROR:  invalid 
input syntax for type boolean: "" in /Users/c9s/git/Work/phifty/pdo_test.php on 
line 44


Previous Comments:

[2009-03-10 18:32:51] kenaniah at gmail dot com

Description:

Referencing ISO 9075, PDO does not properly bind boolean parameters when the 
parameter type has not been made known to PDO.

According to the standard, booleans represent a truth, false, or unknown value. 
According to the SQL language definition (feel free to reference SQL-92), the 
SQL equivalents for a boolean value are TRUE, FALSE, and NULL respectively.

The PDO core should automatically convert boolean values to their proper SQL 
counterparts, and it should be the role of the client driver to deal with these 
values if the database platform in question does not support the ISO standard. 

Rather than listing workarounds, we ask that the PDO core be brought into 
compliance with the SQL standards, and that individual database drivers be 
modified to handle the cases in which their underlying database is not 
standards compliant. 

Reproduce code:
---
$res = $db->prepare('SELECT id FROM table WHERE mybool = ?');
$res->execute(array(false));

Expected result:

SQL statement sent to server:

SELECT id FROM table WHERE mybool = FALSE

(unless modified by DB driver due to a lack of standards compliance on the part 
of the DB)

Actual result:
--
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[22P02]: Invalid text representation: 7 ERROR:  invalid input
syntax for type boolean: ""' 

^^for Postgres driver (Postgres is an standard compliant DB as far as booleans 
are concerned)






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

Bug #55224 [Com]: make fails if configured with --with-gd=DIR

2012-03-02 Thread cornelius dot howl at gmail dot com

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

 ID: 55224
 Comment by: cornelius dot howl at gmail dot com
 Reported by:manuel at bouza dot ch
 Summary:make fails if configured with --with-gd=DIR
 Status: Open
 Type:   Bug
 Package:GD related
 Operating System:   MAC OSX 10.6.8
 PHP Version:5.4SVN-2011-07-18 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

I think the problem is caused from:

gd.c:  typedef FILE gdIOCtx;

I commented this line, and compiler works. :-)


Previous Comments:

[2012-03-02 09:54:09] cornelius dot howl at gmail dot com

Same here. I got this in clang compiler:  (PHP5.4 on Mac OS 10.8)

GD version: 

#define GD_VERSION_STRING "2.0.35"


ext/gd//gd_ctx.c:51:43: error: no member named 'data' in 'struct gdIOCtx'
php_stream * stream = (php_stream *)ctx->data;
~~~  ^
ext/gd//gd_ctx.c:58:43: error: no member named 'data' in 'struct gdIOCtx'
php_stream * stream = (php_stream *)ctx->data;
~~~  ^
ext/gd//gd_ctx.c:67:10: error: no member named 'data' in 'struct gdIOCtx'
if(ctx->data) {
   ~~~  ^
ext/gd//gd_ctx.c:68:40: error: no member named 'data' in 'struct gdIOCtx'
php_stream_close((php_stream *) ctx->data);
~^
/Users/c9s/.phpbrew/build/php-5.4.0/main/php_streams.h:287:52: note: expanded 
from:
#define php_stream_close(stream)_php_stream_free((stream), 
PHP_STREAM_FREE_CLOSE TSRMLS_CC)
  ^
In file included from /Users/c9s/.phpbrew/build/php-5.4.0/ext/gd/gd.c:103:
ext/gd//gd_ctx.c:69:8: error: no member named 'data' in 'struct gdIOCtx'
ctx->data = NULL;
~~~  ^
ext/gd//gd_ctx.c:153:8: error: no member named 'data' in 'struct gdIOCtx'
ctx->data = (void *)stream;
~~~  ^


[2011-07-22 09:14:05] manuel at bouza dot ch

make does not fail if configured with --with-gd (using native library)


[2011-07-19 02:53:09] manuel at bouza dot ch

It's libgd version 2.0.35.


[2011-07-18 22:26:12] ahar...@php.net

What version of libgd do you have installed in /opt/local?


[2011-07-18 04:36:00] manuel at bouza dot ch

Description:

If PHP is configured with --with-gd for compilation, make fails and aborts with 
an 
error.


Test script:
---
On my MAC OSX 10.6.8, I configured PHP as follows for compilation:

> ./configure \
--prefix=/opt/local/php-5.4-dev \
--with-config-file-path=/opt/local/php-5.4-dev/etc \
--enable-fpm \
--with-fpm-user=_www \
--with-fpm-group=_www \
--enable-sockets \
--enable-mbstring \
--enable-pcntl \
--enable-soap \
--enable-sockets \
--enable-zip \
--with-zlib \
--with-curl \
--with-gd=/opt/local \
--with-jpeg-dir=/opt/local \
--with-png-dir=/opt/local \
--with-zlib-dir \
--with-gettext=/opt/local \
--with-mcrypt=/opt/local \
--with-mysql=mysqlnd \
--with-mysqli=mysqlnd \
--with-pdo-mysql=mysqlnd \
--with-pdo-sqlite \
--with-tidy \
--with-pear \
--with-iconv

> make

Produces error as stated in actual result (see below).


Expected result:

I expect make to complete successfully when --with-gd is specified for 
configuration.

Actual result:
--
Make fails and aborts with the following error: 

/bin/sh /Users/manuel.bouza/tmp/php-5.4-dev/libtool --silent 
--preserve-dup-deps 
--mode=compile cc -I/opt/local/include -Iext/gd/ -I/Users/manuel.bouza/tmp/php-
5.4-dev/ext/gd/ -DPHP_ATOM_INC -I/Users/manuel.bouza/tmp/php-5.4-dev/include -
I/Users/manuel.bouza/tmp/php-5.4-dev/main -I/Users/manuel.bouza/tmp/php-5.4-dev 
-I/Users/manuel.bouza/tmp/php-5.4-dev/ext/date/lib -
I/Users/manuel.bouza/tmp/php-5.4-dev/ext/ereg/regex -I/usr/include/libxml2 -
I/opt/local/include -I/usr/local/include -I/Users/manuel.bouza/tmp/php-5.4-
dev/ext/mbstring/oniguruma -I/Users/manuel.bouza/tmp/php-5.4-
dev/ext/mbstring/libmbfl -I/Users/manuel.bouza/tmp/php-5.4-
dev/ext/mbstring/libmbfl/mbfl -I/Users/manuel.bouza/tmp/php-5.4-
dev/ext/sqlite3/libsqlite -I/usr/include/tidy -I/Users/manuel.bouza/tmp/php-5.4-
dev/TSRM -I/Users/manuel.bouza/tmp/php-5.4-dev/Zend  -no-cpp-precomp  -
I/usr/local/include -g -O2 -fvisibility=hidden -DZEND_SIGNALS  -c 
/Users/manuel.bouza/tmp/php-5.4-dev/ext/gd/gd.c -o ext/gd/gd.lo 
In f

Bug #55224 [Com]: make fails if configured with --with-gd=DIR

2012-03-02 Thread cornelius dot howl at gmail dot com

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

 ID: 55224
 Comment by: cornelius dot howl at gmail dot com
 Reported by:manuel at bouza dot ch
 Summary:make fails if configured with --with-gd=DIR
 Status: Open
 Type:   Bug
 Package:GD related
 Operating System:   MAC OSX 10.6.8
 PHP Version:5.4SVN-2011-07-18 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

Same here. I got this in clang compiler:  (PHP5.4 on Mac OS 10.8)

GD version: 

#define GD_VERSION_STRING "2.0.35"


ext/gd//gd_ctx.c:51:43: error: no member named 'data' in 'struct gdIOCtx'
php_stream * stream = (php_stream *)ctx->data;
~~~  ^
ext/gd//gd_ctx.c:58:43: error: no member named 'data' in 'struct gdIOCtx'
php_stream * stream = (php_stream *)ctx->data;
~~~  ^
ext/gd//gd_ctx.c:67:10: error: no member named 'data' in 'struct gdIOCtx'
if(ctx->data) {
   ~~~  ^
ext/gd//gd_ctx.c:68:40: error: no member named 'data' in 'struct gdIOCtx'
php_stream_close((php_stream *) ctx->data);
~^
/Users/c9s/.phpbrew/build/php-5.4.0/main/php_streams.h:287:52: note: expanded 
from:
#define php_stream_close(stream)_php_stream_free((stream), 
PHP_STREAM_FREE_CLOSE TSRMLS_CC)
  ^
In file included from /Users/c9s/.phpbrew/build/php-5.4.0/ext/gd/gd.c:103:
ext/gd//gd_ctx.c:69:8: error: no member named 'data' in 'struct gdIOCtx'
ctx->data = NULL;
~~~  ^
ext/gd//gd_ctx.c:153:8: error: no member named 'data' in 'struct gdIOCtx'
ctx->data = (void *)stream;
~~~  ^


Previous Comments:

[2011-07-22 09:14:05] manuel at bouza dot ch

make does not fail if configured with --with-gd (using native library)


[2011-07-19 02:53:09] manuel at bouza dot ch

It's libgd version 2.0.35.


[2011-07-18 22:26:12] ahar...@php.net

What version of libgd do you have installed in /opt/local?


[2011-07-18 04:36:00] manuel at bouza dot ch

Description:

If PHP is configured with --with-gd for compilation, make fails and aborts with 
an 
error.


Test script:
---
On my MAC OSX 10.6.8, I configured PHP as follows for compilation:

> ./configure \
--prefix=/opt/local/php-5.4-dev \
--with-config-file-path=/opt/local/php-5.4-dev/etc \
--enable-fpm \
--with-fpm-user=_www \
--with-fpm-group=_www \
--enable-sockets \
--enable-mbstring \
--enable-pcntl \
--enable-soap \
--enable-sockets \
--enable-zip \
--with-zlib \
--with-curl \
--with-gd=/opt/local \
--with-jpeg-dir=/opt/local \
--with-png-dir=/opt/local \
--with-zlib-dir \
--with-gettext=/opt/local \
--with-mcrypt=/opt/local \
--with-mysql=mysqlnd \
--with-mysqli=mysqlnd \
--with-pdo-mysql=mysqlnd \
--with-pdo-sqlite \
--with-tidy \
--with-pear \
--with-iconv

> make

Produces error as stated in actual result (see below).


Expected result:

I expect make to complete successfully when --with-gd is specified for 
configuration.

Actual result:
--
Make fails and aborts with the following error: 

/bin/sh /Users/manuel.bouza/tmp/php-5.4-dev/libtool --silent 
--preserve-dup-deps 
--mode=compile cc -I/opt/local/include -Iext/gd/ -I/Users/manuel.bouza/tmp/php-
5.4-dev/ext/gd/ -DPHP_ATOM_INC -I/Users/manuel.bouza/tmp/php-5.4-dev/include -
I/Users/manuel.bouza/tmp/php-5.4-dev/main -I/Users/manuel.bouza/tmp/php-5.4-dev 
-I/Users/manuel.bouza/tmp/php-5.4-dev/ext/date/lib -
I/Users/manuel.bouza/tmp/php-5.4-dev/ext/ereg/regex -I/usr/include/libxml2 -
I/opt/local/include -I/usr/local/include -I/Users/manuel.bouza/tmp/php-5.4-
dev/ext/mbstring/oniguruma -I/Users/manuel.bouza/tmp/php-5.4-
dev/ext/mbstring/libmbfl -I/Users/manuel.bouza/tmp/php-5.4-
dev/ext/mbstring/libmbfl/mbfl -I/Users/manuel.bouza/tmp/php-5.4-
dev/ext/sqlite3/libsqlite -I/usr/include/tidy -I/Users/manuel.bouza/tmp/php-5.4-
dev/TSRM -I/Users/manuel.bouza/tmp/php-5.4-dev/Zend  -no-cpp-precomp  -
I/usr/local/include -g -O2 -fvisibility=hidden -DZEND_SIGNALS  -c 
/Users/manuel.bouza/tmp/php-5.4-dev/ext/gd/gd.c -o ext/gd/gd.lo 
In file included from /Users/manuel.bouza/tmp/php-5.4-dev/ext/gd/gd.c:103:
/Users/manuel.bouza/tmp/php-5.4-dev/ext/gd/gd_ctx.c: In function 
â_php_image_stream_putcâ:
/Users/manuel.bouza/tmp/php-5.4-dev/ext/gd/gd_ctx.c:51: error: âstruct 
gdIOC

Bug #61126 [Nab]: associative array syntax

2012-02-21 Thread cornelius dot howl at gmail dot com

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

 ID: 61126
 User updated by:cornelius dot howl at gmail dot com
 Reported by:cornelius dot howl at gmail dot com
 Summary:associative array syntax
 Status: Not a bug
 Type:   Bug
 Package:*General Issues
 Operating System:   Any
 PHP Version:5.4.0RC7
 Block user comment: N
 Private report: N

 New Comment:

Making new function to handle undefined key makes code slow. function call is 
really slow in PHP, and wrapping with a function makes code ugly.

I mean, an undefined hash should throw an error or notice (the behavior is 
right).

but when using an undefined key from a defined hash, PHP should not throw an 
error.


Previous Comments:

[2012-02-18 11:45:03] ni...@php.net

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

You access an undefined index so you obviously get a notice, nothing will 
change about that.

If you want, you can define a function like

function getWithDefault(&$var, $default = null) {
return isset($var) ? $var : $default;
}
$abc = getWithDefault($def['abc'], 'ghi');

----
[2012-02-17 17:54:01] cornelius dot howl at gmail dot com

Description:

When using undefined $args['method'] this should not throw an error, instead, 
it 
should return undef or null.

In Perl or Ruby, Python, we usually write:

   $value = $hash{key} || 'default value';

But in PHP, we have to write such code, that's such inefficient:

   $value = isset($hash['key']) ? $hash['key'] : 'default';

Yes, we can use '@', but the '@' makes PHP runs more slower.

It will be better if we can have the following syntax:

   $value = $hash['key'] || 'default value';

so that if you have multiple hashes:

   $value = $hash['key'] || $hash2['key'] || $hash3['key'] || 'last value';

then we don't have to write:

   $value = isset($hash['key']) ? $hash['key'] : isset($hash2['key']) ? 
$hash2['key'] : $hash2['key']  # whatever



Thanks







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

[PHP-BUG] Bug #61126 [NEW]: associative array syntax

2012-02-17 Thread cornelius dot howl at gmail dot com

From: 
Operating system: Any
PHP version:  5.4.0RC7
Package:  *General Issues
Bug Type: Bug
Bug description:associative array syntax

Description:

When using undefined $args['method'] this should not throw an error,
instead, it 
should return undef or null.

In Perl or Ruby, Python, we usually write:

   $value = $hash{key} || 'default value';

But in PHP, we have to write such code, that's such inefficient:

   $value = isset($hash['key']) ? $hash['key'] : 'default';

Yes, we can use '@', but the '@' makes PHP runs more slower.

It will be better if we can have the following syntax:

   $value = $hash['key'] || 'default value';

so that if you have multiple hashes:

   $value = $hash['key'] || $hash2['key'] || $hash3['key'] || 'last
value';

then we don't have to write:

   $value = isset($hash['key']) ? $hash['key'] : isset($hash2['key']) ? 
$hash2['key'] : $hash2['key']  # whatever



Thanks


-- 
Edit bug report at https://bugs.php.net/bug.php?id=61126&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61126&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61126&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=61126&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61126&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=61126&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61126&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=61126&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=61126&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=61126&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=61126&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=61126&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=61126&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=61126&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61126&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=61126&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61126&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=61126&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=61126&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=61126&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=61126&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=61126&r=mysqlcfg

[PHP-BUG] Bug #60890 [NEW]: Can not read tgz file through Phar class, but related path works

2012-01-26 Thread cornelius dot howl at gmail dot com

From: 
Operating system: Mac OS 10.6
PHP version:  5.3.9
Package:  PHAR related
Bug Type: Bug
Bug description:Can not read tgz file through Phar class, but related path works

Description:

Can not read tgz file with realpath, offsetGet works, offsetSet doesnt
work.

$p['file'] = 'content';  

will fail.

See: https://gist.github.com/1682446

Test script:
---
https://gist.github.com/1682446

Actual result:
--
See: https://gist.github.com/1682446

-- 
Edit bug report at https://bugs.php.net/bug.php?id=60890&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60890&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60890&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=60890&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60890&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=60890&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60890&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=60890&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=60890&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=60890&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=60890&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=60890&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=60890&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=60890&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60890&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=60890&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60890&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=60890&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=60890&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=60890&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=60890&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=60890&r=mysqlcfg

[PHP-BUG] Bug #64554 [NEW]: var_export does not export absolute namespace for classname

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

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

[PHP-BUG] Req #61298 [NEW]: Add an short alias DS for DIRECTORY_SEPARATOR

Req #47615 [Com]: PDO parameter binding is in clear violation of the ISO 9075 standard

Req #47615 [Com]: PDO parameter binding is in clear violation of the ISO 9075 standard

Bug #55224 [Com]: make fails if configured with --with-gd=DIR

Bug #55224 [Com]: make fails if configured with --with-gd=DIR

Bug #61126 [Nab]: associative array syntax

[PHP-BUG] Bug #61126 [NEW]: associative array syntax

[PHP-BUG] Bug #60890 [NEW]: Can not read tgz file through Phar class, but related path works

11 matches

Site Navigation

Mail list logo

Footer information