Req #30432 [Com]: Add alternate syntax

[kriss at krizalys dot com]

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

 ID: 30432
 Comment by: kriss at krizalys dot com
 Reported by:vivers at one dot net
 Summary:Add alternate syntax
 Status: Wont fix
 Type:   Feature/Change Request
 Package:Feature/Change Request
 Operating System:   All
 PHP Version:5.0.2
 Block user comment: N
 Private report: N

 New Comment:

Whether or not this will ever be added to the official PHP release, there is a 
similar proposed patch for PHP 5.4 here:  https://bugs.php.net/bug.php?id=62164


Previous Comments:

[2011-10-31 12:03:29] christian dot reinecke at web dot de

Can you explain why you declined that?

Because I'm not the only one using the alternative syntax in views/templates, 
especially for if/elseif/else and some old-school pages that do not have 
anything like a controller require try/catch statements mixed in HTML, so that 
syntax would really help.


[2004-10-14 14:42:15] der...@php.net

Nope, we won't add more "old-style" alternative syntax like this.


[2004-10-14 14:33:16] vivers at one dot net

Description:

Can you add alternate syntax for try ... catch?  Something like:

try :
 ...
catch () :
 ...
endtry;

I'm using exceptions on presentation pages and this syntax would make the 
source much more readable.







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

Req #62169 [Com]: Use 'global' like a language structure

[joost dot koehoorn at gmail dot com]

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

 ID: 62169
 Comment by: joost dot koehoorn at gmail dot com
 Reported by:valentiny510 at yahoo dot es
 Summary:Use 'global' like a language structure
 Status: Open
 Type:   Feature/Change Request
 Package:*Programming Data Structures
 Operating System:   Windows XP
 PHP Version:5.4.3
 Block user comment: N
 Private report: N

 New Comment:

My solution would be to introduce global as a scope identifier, so you could 
use 
it as:

global::$object = new stdClass;
global::$object->test = 'This is just a test';

function test()
{
return global::$object->test;
}


Although I do believe globals are evil and static class variables should be 
used 
at all times, this is a neat addition to avoid the very ugly and unclear global 
keyword.

As it is now, you have to define a variable as global for it to resolve and act 
on 
the global variable. This makes code hard to read as it is not directly visible 
that this is the case. The above syntax would solve this problem.


Previous Comments:

[2012-06-02 01:01:48] valentiny510 at yahoo dot es

Imagine I have unset the, ( $GLOBALS )..
To access a 'global' object into the function, first must be called trowght 
global..

function test()
{
global $object;
return $object->some_method( );
}

I wonder if is posible to use (in the future :P) the 'global' like other 
language structures.. Ex:

function test()
{
return( global $object->some_method( ) );
}

I know ... you will ask me why not use the namespaces, reflections, references, 
traits, or whatever.. but .. its not the point ...


[2012-06-02 00:59:13] valentiny510 at yahoo dot es

In the first line I just wrote: "Imagine I have unset the ($GLOBALS)"

for some reason.. (is ugly, security, memory consumption, the host provider 
doesn't allow) or who knows why ...

I know how it works for now but the question is not about how to use "$GLOBALS".

anyway, thanks for the time spent to answer


[2012-05-30 13:35:41] riptide dot tempora at opinehub dot com

For now:
some_method( ) );
}
?>


[2012-05-26 20:31:16] valentiny510 at yahoo dot es

Description:

Imagine I have the, unset ( $GLOBAL )..
To access a 'global' object into the function, first must be called trowght 
global..

function test()
{
global $object;
return $object->some_method( );
}

I wonder if is posible to use (in the future :P) the 'global' like other 
language structures.. Ex:

function test()
{
return( global $object->some_method( ) );
}

I know ... you will ask me why not use the namespaces, reflections, references, 
traits, or whatever.. but .. its not the point ...








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

[PHP-BUG] Bug #63327 [NEW]: Crash (Bus Error) in mysqlnd due to wrong alignment

[rainer dot jung at kippdata dot de]

From: rainer dot jung at kippdata dot de
Operating system: Solaris Sparc
PHP version:  5.3.18
Package:  MSSQL related
Bug Type: Bug
Bug description:Crash (Bus Error) in mysqlnd due to wrong alignment

Description:

All info refers to PHP 5.3.18. The problem goes back to much older 5.3
versions though. It seems current HEAD contains the same problematic code.

The misalignment can happen as soon as
mysqlnd.collect_memory_statistics=On. It occurs on Solaris Sparc for 32 Bit
builds. It is strictly reproducible on my Solaris 8 system, but not on
Solaris 10. This is due to the fact, that a memory allocation for a size
that is only divisibleby 4 but not by 8 can return an address only
divisible by 4 (this happens on my Solaris 8 system) but it can also return
a block of memory starting at an address divisible by 8 (happens by
incident on my Solaris 10 system).

Crash happens in stack:

#0  0x002880f0 in php_mysqlnd_conn_init_pub (conn=0x70dcf4) at
/shared/build/autobuild/workdirs/20121021_163211/bld/php53/ext/mysqlnd/mysqlnd.c:2354
No locals.
#1  0x002880a0 in _mysqlnd_init (persistent=0 '\0') at
/shared/build/autobuild/workdirs/20121021_163211/bld/php53/ext/mysqlnd/mysqlnd.c:2380
ret = (MYSQLND *) 0x70dcf4
#2  0xfee742e0 in php_mysql_do_connect (ht=,
return_value=0x70dc40, return_value_ptr=0x0, this_ptr=, return_value_used=1,
persistent=) at
/shared/build/autobuild/workdirs/20121021_163211/bld/php53/ext/mysql/php_mysql.c:965
index_ptr = (zend_rsrc_list_entry *) 0x70e758
new_index_ptr = {ptr = 0x69e8f0, type = 2778356, refcount =
7393472}
user = 0x70db98 "myuser"
passwd = 0x70dc00 "mypass"
host_and_port = 0x70e808 "myserv:3306"
socket = 0x0
tmp = 
host = 0x70dc10 "myserv"
user_len = 6
passwd_len = 6
host_len = 11
hashed_details = 0x70dc80 "mysql_myserv:3306_myuser_mypass_131072"
hashed_details_length = 38
port = 3306
client_flags = 131072
mysql = 
free_host = 1 '\001'
new_link = 1 '\001'
connect_timeout = 60

Analysis shows, that actually the crash happens immediately before entering
php_mysqlnd_conn_init_pub(), namely in line 2352 of ext/mysqlnd/mysqlnd.c:

   2346 /* {{{ mysqlnd_conn::init */
   2347 static enum_func_status
   2348 MYSQLND_METHOD(mysqlnd_conn, init)(MYSQLND * conn TSRMLS_DC)
   2349 {
   2350 DBG_ENTER("mysqlnd_conn::init");
   2351 mysqlnd_stats_init(&conn->stats, STAT_LAST);
   2352 SET_ERROR_AFF_ROWS(conn);

The macro SET_ERROR_AFF_ROWS is defined in ext/mysqlnd/mysqlnd_priv.h as:

#define SET_ERROR_AFF_ROWS(s) (s)->upsert_status.affected_rows = (uint64_t)
~0

So it is important, that "affected_rows" is aligned correctly for 64 Bits.
So lets check the alignment of conn. On my Solaris Sparc system it has size
sizeof(MYSQLND), which is 776 so divisible by 8 and the structure should be
correctly aligned.

But: this is only true if memory statistics for mysqlnd are turned off. If
they are turned On, the allocation of conn is actually done for 776
+sizeof(size_t) bytes. This is due to the followinglines in
ext/mysqlnd/mysqlnd_debug.c:

814 #define REAL_SIZE(s) (collect_memory_statistics? (s) +
sizeof(size_t) : (s))
...
919 /* {{{ _mysqlnd_pecalloc */
920 void * _mysqlnd_pecalloc(unsigned int nmemb, size_t size, zend_bool
persistent MYSQLND_MEM_D)
921 {
...
932 ret = pecalloc(nmemb, REAL_SIZE(size),
persistent);

So here instead of allocating 776 bytes, we allocate 776+sizeof(size_t) =
776+4 = 780 bytes which is no longer divisible by 8! So memory allocation
not necessarily allocates at 8 bytes alignment.

To fix it I expect you need to replace sizeof(size_t) in the following
lines by a size that does not reduce alignment for any allocation done in
mysqlnd_debug.c. Using sizeof(uint64_t) might suffice for the time being.

814 #define REAL_SIZE(s) (collect_memory_statistics? (s) +
sizeof(size_t) : (s))
815 #define REAL_PTR(p) (collect_memory_statistics && (p)? (((char
*)(p)) - sizeof(size_t)) : (p))
816 #define FAKE_PTR(p) (collect_memory_statistics && (p)? (((char
*)(p)) + sizeof(size_t)) : (p))

In HEAD you can find the same problem in file mysqlnd_alloc.c.

Note: this problem is *not* the same as the alignment problem in mysqlnd I
reported 2.5 years ago in https://bugs.php.net/bug.php?id=51583.

Regards,

Rainer



Test script:
---
MySQL Test
';
  $connection = mysql_connect("$db_server:$db_port", $db_username,
$db_password, $db_name);
  if (! $connection) {
echo "ERROR - Unable to connect to database server
'$db_server:$db_port': ". mysql_error() . '';
  } else {
mysql_close($connection);
  }
?>


Actual result:
--
MySQL Test
Connecting ...Bus Error (core dumped)


-- 
Edit bug report at https://bugs.php.net/bug.php?id=63327&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fi

Bug #63327 [Opn]: Crash (Bus Error) in mysqlnd due to wrong alignment

[rainer dot jung at kippdata dot de]

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

 ID: 63327
 User updated by:rainer dot jung at kippdata dot de
 Reported by:rainer dot jung at kippdata dot de
 Summary:Crash (Bus Error) in mysqlnd due to wrong alignment
 Status: Open
 Type:   Bug
-Package:MSSQL related
+Package:MySQL related
 Operating System:   Solaris Sparc
 PHP Version:5.3.18
 Block user comment: N
 Private report: N

 New Comment:

Changed Package from MSSQL to MySQL. Original Package was chosen in error.


Previous Comments:

[2012-10-21 21:26:30] rainer dot jung at kippdata dot de

Description:

All info refers to PHP 5.3.18. The problem goes back to much older 5.3 versions 
though. It seems current HEAD contains the same problematic code.

The misalignment can happen as soon as mysqlnd.collect_memory_statistics=On. It 
occurs on Solaris Sparc for 32 Bit builds. It is strictly reproducible on my 
Solaris 8 system, but not on Solaris 10. This is due to the fact, that a memory 
allocation for a size that is only divisibleby 4 but not by 8 can return an 
address only divisible by 4 (this happens on my Solaris 8 system) but it can 
also return a block of memory starting at an address divisible by 8 (happens by 
incident on my Solaris 10 system).

Crash happens in stack:

#0  0x002880f0 in php_mysqlnd_conn_init_pub (conn=0x70dcf4) at 
/shared/build/autobuild/workdirs/20121021_163211/bld/php53/ext/mysqlnd/mysqlnd.c:2354
No locals.
#1  0x002880a0 in _mysqlnd_init (persistent=0 '\0') at 
/shared/build/autobuild/workdirs/20121021_163211/bld/php53/ext/mysqlnd/mysqlnd.c:2380
ret = (MYSQLND *) 0x70dcf4
#2  0xfee742e0 in php_mysql_do_connect (ht=, 
return_value=0x70dc40, return_value_ptr=0x0, this_ptr=, 
return_value_used=1,
persistent=) at 
/shared/build/autobuild/workdirs/20121021_163211/bld/php53/ext/mysql/php_mysql.c:965
index_ptr = (zend_rsrc_list_entry *) 0x70e758
new_index_ptr = {ptr = 0x69e8f0, type = 2778356, refcount = 7393472}
user = 0x70db98 "myuser"
passwd = 0x70dc00 "mypass"
host_and_port = 0x70e808 "myserv:3306"
socket = 0x0
tmp = 
host = 0x70dc10 "myserv"
user_len = 6
passwd_len = 6
host_len = 11
hashed_details = 0x70dc80 "mysql_myserv:3306_myuser_mypass_131072"
hashed_details_length = 38
port = 3306
client_flags = 131072
mysql = 
free_host = 1 '\001'
new_link = 1 '\001'
connect_timeout = 60

Analysis shows, that actually the crash happens immediately before entering 
php_mysqlnd_conn_init_pub(), namely in line 2352 of ext/mysqlnd/mysqlnd.c:

   2346 /* {{{ mysqlnd_conn::init */
   2347 static enum_func_status
   2348 MYSQLND_METHOD(mysqlnd_conn, init)(MYSQLND * conn TSRMLS_DC)
   2349 {
   2350 DBG_ENTER("mysqlnd_conn::init");
   2351 mysqlnd_stats_init(&conn->stats, STAT_LAST);
   2352 SET_ERROR_AFF_ROWS(conn);

The macro SET_ERROR_AFF_ROWS is defined in ext/mysqlnd/mysqlnd_priv.h as:

#define SET_ERROR_AFF_ROWS(s) (s)->upsert_status.affected_rows = (uint64_t) ~0

So it is important, that "affected_rows" is aligned correctly for 64 Bits. So 
lets check the alignment of conn. On my Solaris Sparc system it has size 
sizeof(MYSQLND), which is 776 so divisible by 8 and the structure should be 
correctly aligned.

But: this is only true if memory statistics for mysqlnd are turned off. If they 
are turned On, the allocation of conn is actually done for 776 +sizeof(size_t) 
bytes. This is due to the followinglines in ext/mysqlnd/mysqlnd_debug.c:

814 #define REAL_SIZE(s) (collect_memory_statistics? (s) + sizeof(size_t) : 
(s))
...
919 /* {{{ _mysqlnd_pecalloc */
920 void * _mysqlnd_pecalloc(unsigned int nmemb, size_t size, zend_bool 
persistent MYSQLND_MEM_D)
921 {
...
932 ret = pecalloc(nmemb, REAL_SIZE(size), persistent);

So here instead of allocating 776 bytes, we allocate 776+sizeof(size_t) = 776+4 
= 780 bytes which is no longer divisible by 8! So memory allocation not 
necessarily allocates at 8 bytes alignment.

To fix it I expect you need to replace sizeof(size_t) in the following lines by 
a size that does not reduce alignment for any allocation done in 
mysqlnd_debug.c. Using sizeof(uint64_t) might suffice for the time being.

814 #define REAL_SIZE(s) (collect_memory_statistics? (s) + sizeof(size_t) : 
(s))
815 #define REAL_PTR(p) (collect_memory_statistics && (p)? (((char *)(p)) - 
sizeof(size_t)) : (p))
816 #define FAKE_PTR(p) (collect_memory_statistics && (p)? (((char *)(p)) + 
sizeof(size_t)) : (p))

In HEAD you can find the same problem in file mysqlnd_alloc.c.

Note: this problem is *not* the same as the alignment problem in mysqlnd I 
reported 2.5 years ago in https://bugs.php.net/bug.php?id=5

Req #62169 [Opn->Wfx]: Use 'global' like a language structure

[nikic]

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

 ID: 62169
 Updated by: ni...@php.net
 Reported by:valentiny510 at yahoo dot es
 Summary:Use 'global' like a language structure
-Status: Open
+Status: Wont fix
 Type:   Feature/Change Request
 Package:*Programming Data Structures
 Operating System:   Windows XP
 PHP Version:5.4.3
 Block user comment: N
 Private report: N

 New Comment:

As already noted in this thread, using globals is highly discouraged and as 
such it does not make sense to add any further functionality improving their 
use.

Also (you say this yourself) you can use $GLOBALS. I don't understand why you 
don't want to use it. Language features aren't added simply because someone 
says "Hey, I want to access globals in one expression, but I don't want to use 
$GLOBALs, please add a feature that is fully equivalent but uses a different 
syntax".

But even with the constraint of not using $GLOBALS you can easily build a 
function that would do something equivalent:

function getGlobal($name) {
global $$name;
return $$name;
}

$foo = getGlobal('foo');

Marking this as Wontfix.


Previous Comments:

[2012-10-21 21:06:48] joost dot koehoorn at gmail dot com

My solution would be to introduce global as a scope identifier, so you could 
use 
it as:

global::$object = new stdClass;
global::$object->test = 'This is just a test';

function test()
{
return global::$object->test;
}


Although I do believe globals are evil and static class variables should be 
used 
at all times, this is a neat addition to avoid the very ugly and unclear global 
keyword.

As it is now, you have to define a variable as global for it to resolve and act 
on 
the global variable. This makes code hard to read as it is not directly visible 
that this is the case. The above syntax would solve this problem.


[2012-06-02 01:01:48] valentiny510 at yahoo dot es

Imagine I have unset the, ( $GLOBALS )..
To access a 'global' object into the function, first must be called trowght 
global..

function test()
{
global $object;
return $object->some_method( );
}

I wonder if is posible to use (in the future :P) the 'global' like other 
language structures.. Ex:

function test()
{
return( global $object->some_method( ) );
}

I know ... you will ask me why not use the namespaces, reflections, references, 
traits, or whatever.. but .. its not the point ...


[2012-06-02 00:59:13] valentiny510 at yahoo dot es

In the first line I just wrote: "Imagine I have unset the ($GLOBALS)"

for some reason.. (is ugly, security, memory consumption, the host provider 
doesn't allow) or who knows why ...

I know how it works for now but the question is not about how to use "$GLOBALS".

anyway, thanks for the time spent to answer


[2012-05-30 13:35:41] riptide dot tempora at opinehub dot com

For now:
some_method( ) );
}
?>


[2012-05-26 20:31:16] valentiny510 at yahoo dot es

Description:

Imagine I have the, unset ( $GLOBAL )..
To access a 'global' object into the function, first must be called trowght 
global..

function test()
{
global $object;
return $object->some_method( );
}

I wonder if is posible to use (in the future :P) the 'global' like other 
language structures.. Ex:

function test()
{
return( global $object->some_method( ) );
}

I know ... you will ask me why not use the namespaces, reflections, references, 
traits, or whatever.. but .. its not the point ...








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

Bug #63221 [Opn->Nab]: configure --prefix=/opt fails to search /opt/ for packages

[sixd]

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

 ID: 63221
 Updated by: s...@php.net
 Reported by:mamfelt at gmail dot com
 Summary:configure --prefix=/opt fails to search
 /opt/ for packages
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:*Configuration Issues
 Operating System:   AIX
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

The --prefix option is the directory that PHP will be installed. It isn't used 
as a search path.  Run "./configure --help" to check the option to use.  See  --
with-libxml-dir

PHP 5.4 uses the 2.59+ versions of the tools

To use a specific version of the build tools, install that version and then 
run, 
for example:
  export PHP_AUTOCONF=autoconf-2.13
  export PHP_AUTOHEADER=autoheader-2.13
  ./buildconf

If you use buildconf in older versions of PHP, you need to manually clear the 
caches first with:
  rm -rf config.cache autom4te.cache


Previous Comments:

[2012-10-05 10:06:49] mamfelt at gmail dot com

Description:

./configure --prefix /opt


Basically, to resolve this I "patch" configure so that all references to 
/usr/local are replaced by /opt.

Note: I have tried
./buildconf --force

but get the following message:
root@x104:[/data/prj/php/php-RC1-5.3.18]./buildconf --force
Forcing buildconf
buildconf: checking installation...
buildconf: You need autoconf 2.59 or lower to build this version of PHP.
   You are currently trying to use 2.68
   Most distros have separate autoconf 2.13 or 2.59 packages.
   On Debian/Ubuntu both autoconf2.13 and autoconf2.59 packages exist.
   Install autoconf2.13 and set the PHP_AUTOCONF env var to 
   autoconf2.13 and try again.
make: *** [buildmk.stamp] Error 1

==
I went to the autoconf downloads and see that autoconf-2.59 is rather ancient, 
and wonder if this problem is already resolved using newer tools?


[   ] autoconf-2.12.tar.gz  26-Nov-1996 03:00  401K  
[   ] autoconf-2.13.tar.gz  15-Jan-1999 16:03  433K  
[   ] autoconf-2.50-2.52.xdelta 18-Jul-2001 09:59   58K  
...
[   ] autoconf-2.59.tar.bz2 16-Dec-2003 15:53  903K  
[   ] autoconf-2.59.tar.bz2.sig 16-Dec-2003 15:52   65   
[   ] autoconf-2.59.tar.gz  16-Dec-2003 15:52  1.2M  
[   ] autoconf-2.59.tar.gz.sig  16-Dec-2003 15:52   65   
[   ] autoconf-2.60.tar.bz2 26-Jun-2006 13:02  1.0M  
...
[   ] autoconf-2.68.tar.xz  22-Sep-2010 18:54  1.1M  
[   ] autoconf-2.68.tar.xz.sig  22-Sep-2010 18:54  556   
[   ] autoconf-2.69.tar.gz  24-Apr-2012 23:17  1.8M  
[   ] autoconf-2.69.tar.gz.sig  24-Apr-2012 23:17  556   
[   ] autoconf-2.69.tar.xz  24-Apr-2012 23:17  1.2M  
[   ] autoconf-2.69.tar.xz.sig  24-Apr-2012 23:17  556   

Test script:
---
./configure --prefix=/opt

...
checking for xml2-config path... 
configure: error: xml2-config not found. Please check your libxml2 installation.

root@x104:[/data/prj/php/php-RC1-5.3.18]

Expected result:

...
...
++
| License:   |
| This software is subject to the PHP License, available in this |
| distribution in the file LICENSE.  By continuing this installation |
| process, you are bound by the terms of this license agreement. |
| If you do not agree with the terms of this license, you must abort |
| the installation process at this point.|
++

Thank you for using PHP.

Actual result:
--
checking for xml2-config path... 
configure: error: xml2-config not found. Please check your libxml2 installation.







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

Bug #60901 [Csd->ReO]: Oracle-11.2 is not detected (too new)

[sixd]

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

 ID: 60901
 Updated by: s...@php.net
 Reported by:lzsiga at freemail dot c3 dot hu
 Summary:Oracle-11.2 is not detected (too new)
-Status: Closed
+Status: Re-Opened
 Type:   Bug
 Package:OCI8 related
 Operating System:   AIX 6.1
 PHP Version:5.3.9
 Assigned To:sixd
 Block user comment: N
 Private report: N



Previous Comments:

[2012-10-20 10:51:49] rainer dot jung at kippdata dot de

The tail "fix" breaks compilation on Solaris for php version 5.3.18, which 
worked until version 5.3.17.

Not all "tail" implementations support "-n1". On Solaris default "tail" only 
support "-1".

You could switch to using a variable TAIL and auto detect a working tail 
implementation (understanding "-n"), which on Solaris would be the non standard 
/usr/xpg4/bin/tail. Users could overwrite with a new --with-tail switch.


[2012-09-14 08:00:23] lzsiga at freemail dot c3 dot hu

Okay, thank you for your help.


[2012-09-14 07:20:07] s...@php.net

I merged the "tail" fix.  I'm closing this bug out.  I understand you'll need 
to 
create a symlink like other platforms.


[2012-09-14 07:18:13] s...@php.net

Automatic comment on behalf of sixd
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=bbf5978e2641d924c2d4d1c47210756943a28f7b
Log: Fixed bug #60901 (Improve "tail" syntax for AIX installation)


[2012-09-13 08:16:20] lzsiga at freemail dot c3 dot hu

A new aspect of this problem: an over-zealous version of 'tail' wouldn't accept 
syntax 'tail -1' only 'tail -n1'

(in this line in configure:
  OCI8_LCS=`ls $OCI8_LCS_BASE.*.1 2> /dev/null | tail -1`  # Oracle 10g, 11g etc
)




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


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

Bug #54484 [Csd->ReO]: Empty string in json_decode doesn't set/reset json_last_error

[aharvey]

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

 ID: 54484
 Updated by: ahar...@php.net
 Reported by:wildcat at the-wildcat dot de
 Summary:Empty string in json_decode doesn't set/reset
 json_last_error
-Status: Closed
+Status: Re-Opened
 Type:   Bug
 Package:JSON related
 Operating System:   Linux
 PHP Version:5.3.6
-Assigned To:iliaa
+Assigned To:aharvey
 Block user comment: N
 Private report: N

 New Comment:

I don't think the above commit fixed the entire issue: it ensures that the 
error state is reset to 0 when json_decode() is called, but doesn't deal with 
actually setting an error state when we return NULL due to an empty string 
(which I agree should result in a syntax error state).

Assigning to self.


Previous Comments:

[2012-07-24 23:41:28] ras...@php.net

Automatic comment on behalf of iliaa
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=850db4b315eb56d261098a6f42df6a8375cbd937
Log: Fixed bug #54484 (Empty string in json_decode doesn't reset 
json_last_error()).


[2012-04-18 09:50:23] larue...@php.net

Automatic comment on behalf of iliaa
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=850db4b315eb56d261098a6f42df6a8375cbd937
Log: Fixed bug #54484 (Empty string in json_decode doesn't reset 
json_last_error()).


[2011-06-01 11:44:51] il...@php.net

This bug has been fixed in SVN.

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.




[2011-06-01 11:44:40] il...@php.net

Automatic comment from SVN on behalf of iliaa
Revision: http://svn.php.net/viewvc/?view=revision&revision=311708
Log: Fixed bug #54484 (Empty string in json_decode doesn't reset 
json_last_error()).


[2011-04-08 08:20:41] scott...@php.net

a string of length 0 skips the decoder and returns null. I'm thinking it should 
set the error code to 4 so I'll fix it to do so.




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


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

Req #55815 [Com]: PUT request data should be parsed just like POST

[tylerromeo at gmail dot com]

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

 ID: 55815
 Comment by: tylerromeo at gmail dot com
 Reported by:catch dot dave at gmail dot com
 Summary:PUT request data should be parsed just like POST
 Status: Open
 Type:   Feature/Change Request
 Package:Streams related
 Operating System:   All
 PHP Version:5.4.0beta1
 Block user comment: N
 Private report: N

 New Comment:

The http/1.1 RFC does not specify any data type for the request body of any 
request type, nor does the RFC for multipart/form-data specify the request type 
it must be used with in HTTP. And as has been demonstrated by previous 
comments, 
there exist legitimate cases where multipart/form-data would be useful in a PUT 
request.

Let me first say that putting PUT data into $_POST is a bad idea. Hopefully 
that 
is obvious enough. If this were to be implemented, it should use $_PUT (and 
$_FILES, if necessary, along with it).

The real question that needs to be asked is whether it's worth implementing. 
Technically, POST requests do not have any restriction on data types either. So 
really we could just tell all web developers to parse their POST requests from 
stdin like is suggested here for PUT. The reason PHP doesn't do that is because 
POST data is so often encoded in a standard data format and used as such that 
it 
helps developers tremendously to not force them to do such transformations 
themselves.

So the issue is whether enough users will be using multipart/form-data in PUT 
requests to warrant developers implementing a feature for it. Personally, I'm a 
fan of uniformity, and I believe that if we're parsing the request body for a 
POST request, then a PUT request should be treated no differently unless the 
spec has a restriction (which it doesn't).


Previous Comments:

[2012-07-08 18:38:30] johnston dot joshua at gmail dot com

Hi,

in regards to RFC 2616 and the comment:

"What this means is the HTTP RFC does not allow us to identify multipart/form-
data in a PUT request."

This section addresses the meaning of the request URI and NOT the request body. 

In a POST request, the request URI should point to an entity that HANDLES the 
request body in whichever way it sees fit. This COULD be by appending the 
enclosed entity as an annotation to the given request URI, or appending a new 
entity to a collection, etc.

In a PUT request, the enclosed entity should BE STORED AT or REPLACE the entity 
that exists at the given request URI.

There is no reason why the Entity in question cannot be a multipart entity.

Here is a real-world example to illustrate this point using a messageboard as 
an 
example.

A User creates a new topic:

(minimal headers shown for brevity)

POST /topics HTTP/1.1
Content-Type: multipart/form-data; boundary=--
-11401160922046879112964562566
Content-Length: ???
-11401160922046879112964562566
Content-Disposition: form-data; name="comment"

This is a comment here
-11401160922046879112964562566
Content-Disposition: form-data; name="attachment"; filename="attachment.png"
Content-Type: image/png

[binary image data here]
-11401160922046879112964562566--


HTTP/1.1 201 Created
Location: /topics/1


Now we have a new topic referenced by /topics/1. Lets say the original user 
wants 
to change his topic. HTTP says that you can use a PUT request to a given 
request 
URI to replace an entity. If I wanted to replace the entity containing an image 
and the comment I would issue

PUT /topics/1 HTTP/1.1
Content-Type: multipart/form-data; boundary=--
-11401160922046879112964562566
Content-Length: ???
-11401160922046879112964562566
Content-Disposition: form-data; name="comment"

This is a comment here
-11401160922046879112964562566
Content-Disposition: form-data; name="attachment"; filename="attachment.png"
Content-Type: image/png

[binary image data here]
-11401160922046879112964562566--


As you can see here, the multipart/form-data request body is 100% valid.


[2012-06-27 00:57:48] phazei at gmail dot com

Has this been reconsidered at all? Any update?


[2012-04-16 19:15:43] catch dot dave at gmail dot com

Hi theanomaly,

I'd like to address your points.

1. As per my original request the manual page of 
"http://php.net/manual/en/features.file-upload.put-
method.php" *does not* solve the problem, as it does not handle multipart form 
requests.

2. Implementing the parsing of multipart form data in PHP seems to be re-
inventing the wheel when the 
code to correctly parse this already e

Bug #60901 [ReO->Csd]: Oracle-11.2 is not detected (too new)

[sixd]

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

 ID: 60901
 Updated by: s...@php.net
 Reported by:lzsiga at freemail dot c3 dot hu
 Summary:Oracle-11.2 is not detected (too new)
-Status: Re-Opened
+Status: Closed
 Type:   Bug
 Package:OCI8 related
 Operating System:   AIX 6.1
 PHP Version:5.3.9
 Assigned To:sixd
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of sixd
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=dbb72de6c75796803ed6ed103763a12eebc9e78e
Log: Re-fixed bug #60901 (Improve "tail" syntax for AIX installation)


Previous Comments:

[2012-10-20 10:51:49] rainer dot jung at kippdata dot de

The tail "fix" breaks compilation on Solaris for php version 5.3.18, which 
worked until version 5.3.17.

Not all "tail" implementations support "-n1". On Solaris default "tail" only 
support "-1".

You could switch to using a variable TAIL and auto detect a working tail 
implementation (understanding "-n"), which on Solaris would be the non standard 
/usr/xpg4/bin/tail. Users could overwrite with a new --with-tail switch.


[2012-09-14 08:00:23] lzsiga at freemail dot c3 dot hu

Okay, thank you for your help.


[2012-09-14 07:20:07] s...@php.net

I merged the "tail" fix.  I'm closing this bug out.  I understand you'll need 
to 
create a symlink like other platforms.


[2012-09-14 07:18:13] s...@php.net

Automatic comment on behalf of sixd
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=bbf5978e2641d924c2d4d1c47210756943a28f7b
Log: Fixed bug #60901 (Improve "tail" syntax for AIX installation)


[2012-09-13 08:16:20] lzsiga at freemail dot c3 dot hu

A new aspect of this problem: an over-zealous version of 'tail' wouldn't accept 
syntax 'tail -1' only 'tail -n1'

(in this line in configure:
  OCI8_LCS=`ls $OCI8_LCS_BASE.*.1 2> /dev/null | tail -1`  # Oracle 10g, 11g etc
)




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


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

Bug #60901 [Csd]: Oracle-11.2 is not detected (too new)

[sixd]

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

 ID: 60901
 Updated by: s...@php.net
 Reported by:lzsiga at freemail dot c3 dot hu
 Summary:Oracle-11.2 is not detected (too new)
 Status: Closed
 Type:   Bug
 Package:OCI8 related
 Operating System:   AIX 6.1
 PHP Version:5.3.9
 Assigned To:sixd
 Block user comment: N
 Private report: N

 New Comment:

I re-fixed this and also pushed OCI8 1.4.9 with the fix to PECL.


Previous Comments:

[2012-10-22 05:55:50] s...@php.net

Automatic comment on behalf of sixd
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=dbb72de6c75796803ed6ed103763a12eebc9e78e
Log: Re-fixed bug #60901 (Improve "tail" syntax for AIX installation)


[2012-10-20 10:51:49] rainer dot jung at kippdata dot de

The tail "fix" breaks compilation on Solaris for php version 5.3.18, which 
worked until version 5.3.17.

Not all "tail" implementations support "-n1". On Solaris default "tail" only 
support "-1".

You could switch to using a variable TAIL and auto detect a working tail 
implementation (understanding "-n"), which on Solaris would be the non standard 
/usr/xpg4/bin/tail. Users could overwrite with a new --with-tail switch.


[2012-09-14 08:00:23] lzsiga at freemail dot c3 dot hu

Okay, thank you for your help.


[2012-09-14 07:20:07] s...@php.net

I merged the "tail" fix.  I'm closing this bug out.  I understand you'll need 
to 
create a symlink like other platforms.


[2012-09-14 07:18:13] s...@php.net

Automatic comment on behalf of sixd
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=bbf5978e2641d924c2d4d1c47210756943a28f7b
Log: Fixed bug #60901 (Improve "tail" syntax for AIX installation)




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


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

Bug #63305 [Fbk->Opn]: zend_mm_heap corrupted with traits

[johan dot groth at sorona dot se]

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

 ID: 63305
 User updated by:johan dot groth at sorona dot se
 Reported by:johan dot groth at sorona dot se
 Summary:zend_mm_heap corrupted with traits
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:Scripting Engine problem
-Operating System:   Windows 7 64-bit
+Operating System:   All
 PHP Version:5.4.8
 Block user comment: N
 Private report: N

 New Comment:

I could not find a way to upload anything to this report so I created a 
temporary repository over at github with the source. I hope this is OK, you can 
find it here: https://github.com/jgroth/php-crash

Something I found interesting while removing as much code as possible from my 
application was that I could not remove comments for some methods in some of 
the classes/interfaces. Doing so would not reproduce the bug. Also, when I 
turned off error reporting, I did not get the bug either.

Note that there is one "Notice" error reported by PHP in this test application. 
I do not have any such errors in the full application, but still got a php 
crash.


Previous Comments:

[2012-10-20 04:39:27] larue...@php.net

great, if it's okey, you can tar your application as a reproduce script for us


[2012-10-19 12:35:49] johan dot groth at sorona dot se

Ok, so I have somewhat been able to reproduce the problem. I can still not do 
it in a small script, but I have been able to remove enough code from my 
application so I can send it to anyone who might be looking into this issue. 
The application is based on CodeIgniter, so it's basicly the CI code + a few 
extra files from my application.


[2012-10-19 09:31:48] johan dot groth at sorona dot se

As I said I was not able to get a stacktrace on windows, so I decided to try it 
on ubuntu. After building the same php version I used on windows, I was able to 
get php to crash with my application. 
However, I was not able to get a stacktrace in this case either. It just says 
"No stack." at the end. I did get some other messages but I doubt it will be of 
any help.

I want to help as much as I can on this, but I'm not familiar with core dumps 
and stacktraces. If I could get some help generating these I would appreciate 
it.

jgroth@ubuntu:~$ gdb php
GNU gdb (GDB) 7.5-ubuntu
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/local/bin/php...done.
(gdb) run /home/jgroth/crash-test/sorona-tms/src/main/php/index.php test
Starting program: /usr/local/bin/php 
/home/jgroth/crash-test/sorona-tms/src/main/php/index.php test
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Fri Oct 19 02:21:01 2012]  Script:  
'/home/jgroth/crash-test/sorona-tms/src/main/php/index.php'
---
/tmp/php-5.4.8/Zend/zend_opcode.c(404) : Block 0x016854a8 status:
Invalid pointer: ((prev=0x0248) != (prev.size=0x0510))
---
[Fri Oct 19 02:21:01 2012]  Script:  
'/home/jgroth/crash-test/sorona-tms/src/main/php/index.php'
---
/tmp/php-5.4.8/Zend/zend_opcode.c(404) : Block 0x01682188 status:
Invalid pointer: ((size=0x0108) != (next.prev=0x01b0))
Invalid pointer: ((prev=0x00a9) != (prev.size=0x01b0))
---
[Fri Oct 19 02:21:01 2012]  Script:  
'/home/jgroth/crash-test/sorona-tms/src/main/php/index.php'
---
/tmp/php-5.4.8/Zend/zend_opcode.c(404) : Block 0x016857d0 status:
Beginning:  Freed
Start:  OK
  End:  OK
---
[Inferior 1 (process 6653) exited normally]
(gdb) bt
No stack.
(gdb)


[2012-10-18 14:24:40] larue...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better