Bug #63073 [Opn->Fbk]: master "make install" fails to install PEAR
Edit report at https://bugs.php.net/bug.php?id=63073&edit=1 ID: 63073 Updated by: paj...@php.net Reported by:php at bof dot de Summary:master "make install" fails to install PEAR -Status: Open +Status: Feedback Type: Bug Package:Compile Failure Operating System: openSUSE 11.4 64bit PHP Version:5.5 Block user comment: N Private report: N New Comment: It will be much easier to debug if you could provide a small script, even using a pear package as input. Previous Comments: [2012-12-06 04:55:49] dani...@php.net This needs to be fixed so PHP 5.5 can be properly tested. Things work as expected when building PHP <= 5.4. [2012-10-14 11:06:27] bobvin at pillars dot net Branch master does not compile and also is missing file sapi/fpm/php- fpm.service.in Running git-bisect to find the break point, This is the commit that broke compilation: commit 4968fa644b0849321e1761e52b8db15dd46f9b75 Author: theanomaly...@gmail.com Date: Tue Apr 17 07:31:36 2012 -0400 Fixed bug #61038; "Z" and better behavior for unpack() Added new "Z" argument to pack/unpack, now allowing "a" to return data without stripping, and "A" strips all trailing white space, while "Z" will strip everything after the first null. [2012-09-12 15:30:17] php at bof dot de Description: I'm building PHP master from current git (at 5246d6f02e52798e343bd5208692f1a5ed89b9d9) Compile works fine, but on "make install", PEAR does not install. See "Actual result" regarding the error output I get. I can successfully compile AND install, with identical configure, the PHP-5.4.6 release, so I don't think that there is anything wrong with my build environment. I tried to copy over pecl, pear, and the pear environment, from the 5.4 build/install. pecl and pear search works. download or install fetches the file, but then fails with a similar "could not extract" error. Test script: --- make install Expected result: Installing PEAR environment: /opt/php/php/ [PEAR] Archive_Tar- already installed: 1.3.7 [PEAR] Console_Getopt - already installed: 1.3.0 [PEAR] Structures_Graph- already installed: 1.0.4 [PEAR] XML_Util - already installed: 1.2.1 [PEAR] PEAR - already installed: 1.9.4 Actual result: -- Installing PEAR environment: /opt/php/php/ [PEAR] Archive_Tar: could not extract the package.xml file from "phar://install- pear-nozlib.phar/Archive_Tar-1.3.7.tar" [PEAR] Console_Getopt: could not extract the package.xml file from "phar://install-pear-nozlib.phar/Console_Getopt-1.3.0.tar" [PEAR] Structures_Graph: could not extract the package.xml file from "phar://install-pear-nozlib.phar/Structures_Graph-1.0.4.tar" [PEAR] XML_Util: could not extract the package.xml file from "phar://install- pear-nozlib.phar/XML_Util-1.2.1.tar" [PEAR] PEAR: could not extract the package.xml file from "phar://install-pear- nozlib.phar/PEAR-1.9.4.tar" -- Edit this bug report at https://bugs.php.net/bug.php?id=63073&edit=1
Bug #60018 [Opn]: no more received signal after pcntl_exec
Edit report at https://bugs.php.net/bug.php?id=60018&edit=1 ID: 60018 User updated by:n dot escuder at atlantis-software dot net Reported by:n dot escuder at atlantis-software dot net Summary:no more received signal after pcntl_exec Status: Open Type: Bug Package:PCNTL related -Operating System: Linux 3.0 +Operating System: Linux 3.6 -PHP Version:5.3.8 +PHP Version:5.4.9 Block user comment: N Private report: N New Comment: Always have this bug... i need a patch for my cli scripts Previous Comments: [2011-10-08 22:36:58] n dot escuder at atlantis-software dot net Description: No more received the signal HUP after using pcntl_exec Test script: --- #!/bin/php Expected result: first kill -HUP PID show : sig_handler() called do a second kill -HUP PID and show : sig_handler() called Actual result: -- first kill -HUP PID show : sig_handler() called do a second kill -HUP PID and nothing append and no more possible to do a CTRL+C on the program -- Edit this bug report at https://bugs.php.net/bug.php?id=60018&edit=1
[PHP-BUG] Bug #63708 [NEW]: 5.16.1
From: rameezsoomro dot pk at live dot com
Operating system: Win 7
PHP version: 5.4.9
Package: GD related
Bug Type: Bug
Bug description:5.16.1
Description:
Note: I i've choose wrong version on PHP Version list because my php
version not
available on list option...
I am using xampp on localhost/computer with Apache/2.4.3 (Win32)
OpenSSL/1.0.1c
PHP/5.4.7
imagefttext or imagettftext both function are return a blank image (null)
and my
gd library was also enable ...tell me what should i do...
Test script:
---
// Set the content-type
header('Content-Type: image/png');
// Create the image
$im = imagecreatetruecolor(400, 30);
// Create some colors
$white = imagecolorallocate($im, 255, 255, 255);
$grey = imagecolorallocate($im, 128, 128, 128);
$black = imagecolorallocate($im, 0, 0, 0);
imagefilledrectangle($im, 0, 0, 399, 29, $white);
// The text to draw
$text = 'Testing...';
// Replace path by your own font path
$font = 'arial.ttf';
// Add some shadow to the text
imagefttext($im, 20, 0, 11, 21, $grey, $font, $text);
// Add the text
imagefttext($im, 20, 0, 10, 20, $black, $font, $text);
// Using imagepng() results in clearer text compared with imagejpeg()
imagepng($im);
imagedestroy($im);
--
Edit bug report at https://bugs.php.net/bug.php?id=63708&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63708&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63708&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63708&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63708&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63708&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63708&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63708&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63708&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63708&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63708&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63708&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63708&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63708&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63708&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63708&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63708&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63708&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63708&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63708&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63708&r=mysqlcfg
Bug #60586 [Com]: ignore_user_abort=true has no effect on IIS with FastCGI
Edit report at https://bugs.php.net/bug.php?id=60586&edit=1
ID: 60586
Comment by: rainer at dueckerhoff dot de
Reported by:sauvant at aspera dot com
Summary:ignore_user_abort=true has no effect on IIS with
FastCGI
Status: Feedback
Type: Bug
Package:IIS related
Operating System: Windows Server 2008 R2
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
This bug still persists in the latest 5.3 version after about a year of this
bug
report.
Any chance that it could be fixed or any explanation on why it doesn't work
with
IIS but with Apache (and thus cannot be fixed)? Or at least a workaround?
Cheers,
Rainer
Previous Comments:
[2012-07-10 12:32:43] sauvant at aspera dot com
There is a thread at the IIS forum, too: http://forums.iis.net/t/1190270.aspx
No feedback at all :-(
Is the issue described PHP or IIS related?
Any opinions?
Anybody able to reproduce?
Best regards
Keith
[2012-06-25 15:00:50] lars_teuber at gmx dot de
Microsoft-IIS/7.5. Best regards, Lars.
[2012-06-25 14:54:00] larue...@php.net
you mean IIS or nginx? thanks :)
[2012-06-25 14:45:35] lars_teuber at gmx dot de
Please find reproduce script below. The script stops whenever there is output
send to a browser that is no longer listening. It will continue to run until
you send anything. Best regards, Lars.
https://bugs.php.net/bug.php?id=60586
ignore_user_abort(true);
$path = sys_get_temp_dir() . '\\ignore_user_abort_' . date('Ymd_His', time());
echo $path;
flush();
$seconds = 30;
$time = time();
$i = 0;
while (time() - $time < $seconds) {
echo '. ';
flush();
$i++;
}
write_file($path, 'finished (' . $i . ' iterations)');
function write_file($path, $message)
{
$handle = fopen($path, 'wb');
if (!$handle) {
throw new Exception('fopen() failed');
}
if (fwrite($handle, $message) === false) {
fclose($handle);
throw new Exception('fwrite() failed');
}
if (!fclose($handle)) {
throw new Exception('fclose() failed');
}
}
?>
[2012-06-25 05:29:50] larue...@php.net
btw: I can not reproduce this with nginx
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=60586
--
Edit this bug report at https://bugs.php.net/bug.php?id=60586&edit=1
Bug #44942 [Dup]: exec() hangs apache
Edit report at https://bugs.php.net/bug.php?id=44942&edit=1 ID: 44942 Updated by: paj...@php.net Reported by:inqualab1985 at gmail dot com Summary:exec() hangs apache Status: Duplicate Type: Bug Package:Program Execution Operating System: Windows 2000 SP4 PHP Version:5.2.5 Block user comment: N Private report: N New Comment: See also #44994 Previous Comments: [2012-12-05 12:04:02] claudix dot kernel at gmail dot com Seen the same behavior, not only in exec(), but also in similar functions as proc_open/proc_close. When there are concurrent scripts during a same PHP session, the script spawning the process randomly hangs. System: - Windows 2003 server SP2 - Apache 2.2.22/ PHP 5.4.3 I can confirm that calling session_write_close() and then session_start() does the trick. I've observed, though, that the code below doesn't work: $proc = proc_open($cmd,$pipedesc,$pipes); //do stuff with pipes... //... and close pipes session_write_close(); //Close session before hanging function $retval = proc_close($proc); session_start(); //restore session But the code below *does* work: session_write_close(); //Close the session before proc_open() $proc = proc_open($cmd,$pipedesc,$pipes); //do stuff with pipes... //... and close pipes $retval = proc_close($proc); session_start(); //restore session This made me go into the PHP source code (actually the source file "proc_open.c"). I've noticed that the command passed to proc_open() is spawned by calling the WINAPI function CreateProcess(...) with the parameter "bInheritHandles" set to TRUE. As of MSDN documentation, if this parameter is TRUE then all handles are inherited by the child process. It seems that the handle of the session is being inherited by the child process but for some reason the OS doesn't release it when the process ends, eventually yielding a deadlock. The code snippets above show this: the session has to be closed before calling proc_open() to prevent the spawned command from inheriting the session handle. People using exec() cannot see this effect because exec() virtually embeds proc_open/proc_close. May this give a clue to PHP developers? Claudi [2012-10-15 15:00:52] mail at GerhardBechtold dot com Pajoye, I didn't find any documentation on the service sensitivity of the new PHP. You might be right, that the eof of the console stream is not taken care properly, but in my case the system is now working (again). [2012-10-15 09:12:30] paj...@php.net @mail at GerhardBechtold dot com this is documented, the shell/exec permissions have to be given. However I do not think it is related to the original issue which is caused by a real bug in the php stream, where the eof of the console stream is not correctly detected and ends in an endless loop. [2012-10-14 15:28:38] mail at GerhardBechtold dot com After many hours of testing, I managed to solve my problem of exec() calls in PHP. This might be useful also for other developers, as I have seen many struggling with te same problem. 1. xampp must be installed in real (!) administrator mode (in Windows 7 / 32 & 64 bit). 2. In many environments, Apache and MySQL should not run as services, but be manually started (even not with interaction with desktop). I have put a step-by-step procedure to troubleshoot at: http://www.gerhardbechtold.com/LUPMIS/Manual/a15_xamppmap_maker_installation.html (Ignore the references to our system LUPMIS). Good luck to everybody Gerhard [2012-09-27 21:02:13] mail at GerhardBechtold dot com Thanks for looking into my problems with exec() at the latest PHP. Example for actual code, as in application (was running nicely in earlier PHP installations, but not under PHP 2.4 anymore): $str1Name = "C:\Map Maker\MMmacro.exe"; $str2Name = "command=remove layer"; exec(chr(34).$str1Name.chr(34).chr(32).chr(34).$str2Name.chr(34)); I am using a GIS called Map Maker, with powerful MMmacro functions (www.mapmaker.com). 'remove layer' is one of the most basic parameters of MMmacro. A more simple test version also failed: $str1Name = "C:\Windows\Notepad.exe"; exec($str1Name); I also tested, all without success: - with bat file, which then calls notepad.exe - with exe/bat in different folders: document root (C:\xampp\htdocs) or from calling directory (C:\xampp\htdocs\lupmis_s) - with 'start .' - with popen - with exec( < file.in > file.out 2> nul", $output); - with exec(,$
Bug #44942 [Dup->Asn]: exec() hangs apache
Edit report at https://bugs.php.net/bug.php?id=44942&edit=1 ID: 44942 Updated by: paj...@php.net Reported by:inqualab1985 at gmail dot com Summary:exec() hangs apache -Status: Duplicate +Status: Assigned Type: Bug Package:Program Execution Operating System: Windows 2000 SP4 PHP Version:5.2.5 -Assigned To: +Assigned To:pajoye Block user comment: N Private report: N Previous Comments: [2012-12-06 12:54:57] paj...@php.net See also #44994 [2012-12-05 12:04:02] claudix dot kernel at gmail dot com Seen the same behavior, not only in exec(), but also in similar functions as proc_open/proc_close. When there are concurrent scripts during a same PHP session, the script spawning the process randomly hangs. System: - Windows 2003 server SP2 - Apache 2.2.22/ PHP 5.4.3 I can confirm that calling session_write_close() and then session_start() does the trick. I've observed, though, that the code below doesn't work: $proc = proc_open($cmd,$pipedesc,$pipes); //do stuff with pipes... //... and close pipes session_write_close(); //Close session before hanging function $retval = proc_close($proc); session_start(); //restore session But the code below *does* work: session_write_close(); //Close the session before proc_open() $proc = proc_open($cmd,$pipedesc,$pipes); //do stuff with pipes... //... and close pipes $retval = proc_close($proc); session_start(); //restore session This made me go into the PHP source code (actually the source file "proc_open.c"). I've noticed that the command passed to proc_open() is spawned by calling the WINAPI function CreateProcess(...) with the parameter "bInheritHandles" set to TRUE. As of MSDN documentation, if this parameter is TRUE then all handles are inherited by the child process. It seems that the handle of the session is being inherited by the child process but for some reason the OS doesn't release it when the process ends, eventually yielding a deadlock. The code snippets above show this: the session has to be closed before calling proc_open() to prevent the spawned command from inheriting the session handle. People using exec() cannot see this effect because exec() virtually embeds proc_open/proc_close. May this give a clue to PHP developers? Claudi [2012-10-15 15:00:52] mail at GerhardBechtold dot com Pajoye, I didn't find any documentation on the service sensitivity of the new PHP. You might be right, that the eof of the console stream is not taken care properly, but in my case the system is now working (again). [2012-10-15 09:12:30] paj...@php.net @mail at GerhardBechtold dot com this is documented, the shell/exec permissions have to be given. However I do not think it is related to the original issue which is caused by a real bug in the php stream, where the eof of the console stream is not correctly detected and ends in an endless loop. [2012-10-14 15:28:38] mail at GerhardBechtold dot com After many hours of testing, I managed to solve my problem of exec() calls in PHP. This might be useful also for other developers, as I have seen many struggling with te same problem. 1. xampp must be installed in real (!) administrator mode (in Windows 7 / 32 & 64 bit). 2. In many environments, Apache and MySQL should not run as services, but be manually started (even not with interaction with desktop). I have put a step-by-step procedure to troubleshoot at: http://www.gerhardbechtold.com/LUPMIS/Manual/a15_xamppmap_maker_installation.html (Ignore the references to our system LUPMIS). Good luck to everybody Gerhard 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=44942 -- Edit this bug report at https://bugs.php.net/bug.php?id=44942&edit=1
[PHP-BUG] Bug #63709 [NEW]: flock() doesn't trigger mandatory locks on linux
From: eric dot saintetienne at gmail dot com
Operating system: Linux
PHP version: 5.3.19
Package: Filesystem function related
Bug Type: Bug
Bug description:flock() doesn't trigger mandatory locks on linux
Description:
Locking exclusively via flock a file opened for writing doesn't trigger a
mandatory lock.
The python script below could trigger the mandatory lock.
Maybe it's because PHP flock() is built on the C function call flock():
"When a program attempts to lock a file with lockf or fcntl that has
mandatory
locking set, the kernel will prevent all other programs from accessing the
file.
Processes which use flock will not trigger a mandatory lock."
source: http://www.hackinglinuxexposed.com/articles/20030623.html
Python script:
#!/usr/bin/python
import os, fcntl
fd = os.open('mandlock-file', os.O_RDWR, 0755)
print 'fd=', fd
fcntl.lockf(fd, fcntl.LOCK_EX)
a = raw_input() # during that time, any attempt to open the file will hang
os.write(fd, a+'\n')
fcntl.lockf(fd, fcntl.LOCK_UN)
# now any attempt to open the file will succeed
os.close(fd)
# eof
Test script:
---
Expected result:
once the file is created and the mandatory lock setup for it:
during the 10 sec timer, opening the file (with or without explicit
locking)
should hand until the php script terminates.
Actual result:
--
it's possible to opening the locked file during the 10s timer for reading
and
writing.
--
Edit bug report at https://bugs.php.net/bug.php?id=63709&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63709&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63709&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63709&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63709&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63709&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63709&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63709&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63709&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63709&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63709&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63709&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63709&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63709&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63709&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63709&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63709&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63709&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63709&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63709&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63709&r=mysqlcfg
Bug #63709 [Opn]: flock() doesn't trigger mandatory locks on linux
Edit report at https://bugs.php.net/bug.php?id=63709&edit=1
ID: 63709
User updated by:eric dot saintetienne at gmail dot com
Reported by:eric dot saintetienne at gmail dot com
Summary:flock() doesn't trigger mandatory locks on linux
Status: Open
Type: Bug
Package:Filesystem function related
Operating System: Linux
PHP Version:5.3.19
Block user comment: N
Private report: N
New Comment:
Note that dio_fcntl() of the "Direct IO" extension can successfully exclusively
lock the file, but this shouldn't be considered as a workaround as it's not
always
possible to install extensions.
If flock() couldn't be modified for backward compatibility reasons, options
could
be added to alter its behaviour, or a new call lockf() would be welcome too.
Previous Comments:
[2012-12-06 13:12:43] eric dot saintetienne at gmail dot com
Description:
Locking exclusively via flock a file opened for writing doesn't trigger a
mandatory lock.
The python script below could trigger the mandatory lock.
Maybe it's because PHP flock() is built on the C function call flock():
"When a program attempts to lock a file with lockf or fcntl that has mandatory
locking set, the kernel will prevent all other programs from accessing the
file.
Processes which use flock will not trigger a mandatory lock."
source: http://www.hackinglinuxexposed.com/articles/20030623.html
Python script:
#!/usr/bin/python
import os, fcntl
fd = os.open('mandlock-file', os.O_RDWR, 0755)
print 'fd=', fd
fcntl.lockf(fd, fcntl.LOCK_EX)
a = raw_input() # during that time, any attempt to open the file will hang
os.write(fd, a+'\n')
fcntl.lockf(fd, fcntl.LOCK_UN)
# now any attempt to open the file will succeed
os.close(fd)
# eof
Test script:
---
Expected result:
once the file is created and the mandatory lock setup for it:
during the 10 sec timer, opening the file (with or without explicit locking)
should hand until the php script terminates.
Actual result:
--
it's possible to opening the locked file during the 10s timer for reading and
writing.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63709&edit=1
[PHP-BUG] Req #63712 [NEW]: function returning array and directly calling array element parse error
From: tretoria at data dot bg Operating system: win32 PHP version: 5.3.19 Package: Compile Failure Bug Type: Feature/Change Request Bug description:function returning array and directly calling array element parse error Description: When calling function which returns array and try to get element of the returned array directly, without copying the result into variable like "foo()[x]" where x is integer, it returns parse syntax error. However this is working in 5.4.* versions. Test script: --- Expected result: second Actual result: -- Parse error: syntax error, unexpected '[', expecting ',' or ';' -- Edit bug report at https://bugs.php.net/bug.php?id=63712&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63712&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63712&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63712&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63712&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63712&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63712&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63712&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63712&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63712&r=support Expected behavior: https://bugs.php.net/fix.php?id=63712&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63712&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63712&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63712&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63712&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63712&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63712&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63712&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63712&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63712&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63712&r=mysqlcfg
[PHP-BUG] Req #63713 [NEW]: Need an "UNDEFINED" type
From: liquid_nitrogen_4ever at yahoo dot com Operating system: PHP version: Irrelevant Package: Variables related Bug Type: Feature/Change Request Bug description:Need an "UNDEFINED" type Description: Consider the following scenario currently in PHP: var_dump($notExistentVariable); -> NOTICE: Undefined variable notHere on line 1 NULL isset($notExistentVariable); -> FALSE $foo = null; var_dump($foo); -> NULL isset($foo); -> FALSE If there were an UNDEFINED "type" (in the same sense that there is a NULL), the above scenarios would change to: var_dump($notExistentVariable); -> UNDEFINED isset($notExistentVariable); -> FALSE $foo = null; var_dump($foo); -> NULL isset($foo); -> TRUE However, unlike NULL, you would NOT be allowed to explicitly initialize something to UNDEFINED. $x=UNDEFINED;//error: if you want it to be undefined, don't declare it. However, having just: $x; makes sense (to me at least) as shortcut to: $x=NULL; In other words, if a variable is declared but not explicitly initialized, it will implicitly be set to NULL (which is essentially what you are already doing, but one can't really differentiate between declared and undeclared variables). -- Edit bug report at https://bugs.php.net/bug.php?id=63713&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63713&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63713&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63713&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63713&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63713&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63713&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63713&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63713&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63713&r=support Expected behavior: https://bugs.php.net/fix.php?id=63713&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63713&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63713&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63713&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63713&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63713&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63713&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63713&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63713&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63713&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63713&r=mysqlcfg
Req #63712 [Opn->Csd]: function returning array and directly calling array element parse error
Edit report at https://bugs.php.net/bug.php?id=63712&edit=1 ID: 63712 Updated by: ni...@php.net Reported by:tretoria at data dot bg Summary:function returning array and directly calling array element parse error -Status: Open +Status: Closed Type: Feature/Change Request Package:Compile Failure Operating System: win32 PHP Version:5.3.19 -Assigned To: +Assigned To:nikic Block user comment: N Private report: N New Comment: This feature was added in PHP 5.4. Previous Comments: [2012-12-06 15:13:52] tretoria at data dot bg Description: When calling function which returns array and try to get element of the returned array directly, without copying the result into variable like "foo()[x]" where x is integer, it returns parse syntax error. However this is working in 5.4.* versions. Test script: --- Expected result: second Actual result: -- Parse error: syntax error, unexpected '[', expecting ',' or ';' -- Edit this bug report at https://bugs.php.net/bug.php?id=63712&edit=1
Bug #63704 [Asn->Opn]: Can't 'make' a second time with --enable-dtrace
Edit report at https://bugs.php.net/bug.php?id=63704&edit=1 ID: 63704 Updated by: d...@php.net Reported by:s...@php.net Summary:Can't 'make' a second time with --enable-dtrace -Status: Assigned +Status: Open Type: Bug Package:*General Issues Operating System: Oracle Linux 6.3 PHP Version:5.5 Git Assigned To:dsp Block user comment: N Private report: N New Comment: Changed it to "General issue" as this is a bug of the DTRaces probes in core not the DTrace package. Previous Comments: [2012-12-06 21:39:16] d...@php.net Changed it to "General issue" as this is a bug of the DTRaces probes in core not the DTrace package. [2012-12-06 03:41:19] s...@php.net After getting the error, the workaround is to do: git checkout Zend/zend_dtrace.d and then repeat the 'make'. [2012-12-06 03:20:13] s...@php.net Description: For any build with --enable-dtrace, running 'make' a second time after a successful build gives a compile failure. Test script: --- ./configure --disable-all --enable-dtrace make make Expected result: Both 'make' commands succeed. Actual result: -- The actual result is the second 'make' fails like: $ make cc /home/cjones/php-src/Zend/zend_dtrace.d.o -o /home/cjones/php- src/Zend/zend_dtrace.d /usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: ld returned 1 exit status make: *** [/home/cjones/php-src/Zend/zend_dtrace.d] Error 1 -- Edit this bug report at https://bugs.php.net/bug.php?id=63704&edit=1
Bug #63704 [Opn]: Can't 'make' a second time with --enable-dtrace
Edit report at https://bugs.php.net/bug.php?id=63704&edit=1 ID: 63704 Updated by: d...@php.net Reported by:s...@php.net Summary:Can't 'make' a second time with --enable-dtrace Status: Open Type: Bug Package:*General Issues Operating System: Oracle Linux 6.3 PHP Version:5.5 Git -Assigned To: +Assigned To:dsp Block user comment: N Private report: N New Comment: Changed it to "General issue" as this is a bug of the DTRaces probes in core not the DTrace package. Previous Comments: [2012-12-06 03:41:19] s...@php.net After getting the error, the workaround is to do: git checkout Zend/zend_dtrace.d and then repeat the 'make'. [2012-12-06 03:20:13] s...@php.net Description: For any build with --enable-dtrace, running 'make' a second time after a successful build gives a compile failure. Test script: --- ./configure --disable-all --enable-dtrace make make Expected result: Both 'make' commands succeed. Actual result: -- The actual result is the second 'make' fails like: $ make cc /home/cjones/php-src/Zend/zend_dtrace.d.o -o /home/cjones/php- src/Zend/zend_dtrace.d /usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: ld returned 1 exit status make: *** [/home/cjones/php-src/Zend/zend_dtrace.d] Error 1 -- Edit this bug report at https://bugs.php.net/bug.php?id=63704&edit=1
Bug #62692 [Opn]: PHP fails to build with dtrace
Edit report at https://bugs.php.net/bug.php?id=62692&edit=1 ID: 62692 Updated by: d...@php.net Reported by:eugene at zhegan dot in Summary:PHP fails to build with dtrace Status: Open Type: Bug -Package:DTrace +Package:*General Issues Operating System: Solaris 10 x86 PHP Version:5.4.5 -Assigned To: +Assigned To:dsp Block user comment: N Private report: N New Comment: This bug is about the dtrace probes in core not the PECL package. Previous Comments: [2012-09-14 15:46:48] eugene at zhegan dot in Okay. Here are a bit more detailed instruction about how to actually and successfully build php with dtrace on Solaris. On Solaris Solaris, not on a dead body of Opensolaris or on shiny and rare Openindiana. - Run configure with --enable-dtrace. - You will probably need to use bundled gd, not system or installed from source, so use --with-gd, whithout a directory. - It should work fine (actually, there are plenty of ways for it to fail depending on the various options, but let's assume you know how to build php on Solaris from sources and you're trying to build it with dtrace for now). - Now you need to patch the Makefile the configure just created for you. Why ? Because Solaris sed doesn't have an -i switch. You can patch the Makefile as described here: https://bugs.php.net/bug.php?id=62691 or you can just install the GNU sed and make it appear in the PATH before the system sed. - Now you can actually start building php, but read first this: https://bugs.php.net/bug.php?id=61268 . I'll make it easier: due to the fact that building will crash (see below) twice (see below :) ) you will need to prevent the zend_dtrace.d probe file from clobbering, due to the nature of gmake and some issues in the Makefile. :) This is done by using the '-r' switch, which prevents the make builtin rules from firing. - Use gmake, it will make your life even more easier. - Thus, you can run 'gmake -r' now and wait for it to crash. - It will crash somewhere around making pfp-fpm (if you ordered this sapi) and the crash lines won't be similar the initial error in this report. The crash lines from the start of this report are caused by some clobbering and not using 'gmake -r'. You should see a crash like this: Undefined first referenced symbol in file __dtraceenabled_php___execute__entry Zend/.libs/zend_dtrace.o __dtraceenabled_php___execute__return Zend/.libs/zend_dtrace.o __dtrace_php___compile__file__return Zend/.libs/zend_dtrace.o __dtrace_php___exception__thrownZend/.libs/zend_exceptions.o __dtrace_php___errorZend/.libs/zend.o __dtrace_php___function__entry Zend/.libs/zend_dtrace.o __dtrace_php___function__return Zend/.libs/zend_dtrace.o __dtrace_php___request__shutdownmain/.libs/main.o __dtrace_php___exception__caughtZend/.libs/zend_execute.o __dtrace_php___execute__return Zend/.libs/zend_dtrace.o __dtrace_php___request__startup main/.libs/main.o __dtraceenabled_php___exception__caught Zend/.libs/zend_execute.o __dtrace_php___compile__file__entry Zend/.libs/zend_dtrace.o __dtraceenabled_php___function__entry Zend/.libs/zend_dtrace.o __dtrace_php___execute__entry Zend/.libs/zend_dtrace.o __dtraceenabled_php___error Zend/.libs/zend.o __dtraceenabled_php___function__return Zend/.libs/zend_dtrace.o $dtrace18058.ZEND_CATCH_SPEC_CONST_CV_HANDLER Zend/zend_dtrace.d.o __dtraceenabled_php___exception__thrown Zend/.libs/zend_exceptions.o ld: fatal: Symbol referencing errors. No output written to sapi/cli/php collect2: ld returned 1 exit status gmake: *** [sapi/cli/php] Error 1 - lets discuss what is it and how to fix it. Somewhere over 9000 lines above the building process made this: dtrace -G -o Zend/zend_dtrace.d.o -s /home/emz/src/php-5.4.5/Zend/zend_dtrace.d main/main.o Zend/zend_API.o Zend/zend_execute.o Zend/zend_exceptions.o Zend/zend_dtrace.o Zend/zend.o What is this ? This is the creation of the ELF binary with dtrace probes AND updating of the source object files. This is important. But these source object files at this point are already copied in the .libs directory, which linker is using at the final stage and where it does crash. They should be updated after running dtrace -G but they are not. In order to fix the building you should do it by hand: - copy the files: Zend/zend_API.o Zend/zend_execute.o Zend/zend_exceptions.o Zend/zend_dtrace.o Zend/zend.o to the Zend/.libs - copy the file main/main.o to the main/.libs. They should differ by the way fromthe targets you have in .libs. - issue a 'gmake -r' in the top php source directory so the building will continue. Important: issuing just 'gmake' will clobber the Zend_dtrace.d file and you will lose it. - it will crash
Bug #62692 [Com]: PHP fails to build with dtrace
Edit report at https://bugs.php.net/bug.php?id=62692&edit=1 ID: 62692 Comment by: d...@php.net Reported by:eugene at zhegan dot in Summary:PHP fails to build with dtrace Status: Assigned Type: Bug Package:*General Issues Operating System: Solaris 10 x86 PHP Version:5.4.5 Assigned To:dsp Block user comment: N Private report: N New Comment: Did you build any module as shared? Previous Comments: [2012-12-06 21:41:17] d...@php.net This bug is about the dtrace probes in core not the PECL package. [2012-09-14 15:46:48] eugene at zhegan dot in Okay. Here are a bit more detailed instruction about how to actually and successfully build php with dtrace on Solaris. On Solaris Solaris, not on a dead body of Opensolaris or on shiny and rare Openindiana. - Run configure with --enable-dtrace. - You will probably need to use bundled gd, not system or installed from source, so use --with-gd, whithout a directory. - It should work fine (actually, there are plenty of ways for it to fail depending on the various options, but let's assume you know how to build php on Solaris from sources and you're trying to build it with dtrace for now). - Now you need to patch the Makefile the configure just created for you. Why ? Because Solaris sed doesn't have an -i switch. You can patch the Makefile as described here: https://bugs.php.net/bug.php?id=62691 or you can just install the GNU sed and make it appear in the PATH before the system sed. - Now you can actually start building php, but read first this: https://bugs.php.net/bug.php?id=61268 . I'll make it easier: due to the fact that building will crash (see below) twice (see below :) ) you will need to prevent the zend_dtrace.d probe file from clobbering, due to the nature of gmake and some issues in the Makefile. :) This is done by using the '-r' switch, which prevents the make builtin rules from firing. - Use gmake, it will make your life even more easier. - Thus, you can run 'gmake -r' now and wait for it to crash. - It will crash somewhere around making pfp-fpm (if you ordered this sapi) and the crash lines won't be similar the initial error in this report. The crash lines from the start of this report are caused by some clobbering and not using 'gmake -r'. You should see a crash like this: Undefined first referenced symbol in file __dtraceenabled_php___execute__entry Zend/.libs/zend_dtrace.o __dtraceenabled_php___execute__return Zend/.libs/zend_dtrace.o __dtrace_php___compile__file__return Zend/.libs/zend_dtrace.o __dtrace_php___exception__thrownZend/.libs/zend_exceptions.o __dtrace_php___errorZend/.libs/zend.o __dtrace_php___function__entry Zend/.libs/zend_dtrace.o __dtrace_php___function__return Zend/.libs/zend_dtrace.o __dtrace_php___request__shutdownmain/.libs/main.o __dtrace_php___exception__caughtZend/.libs/zend_execute.o __dtrace_php___execute__return Zend/.libs/zend_dtrace.o __dtrace_php___request__startup main/.libs/main.o __dtraceenabled_php___exception__caught Zend/.libs/zend_execute.o __dtrace_php___compile__file__entry Zend/.libs/zend_dtrace.o __dtraceenabled_php___function__entry Zend/.libs/zend_dtrace.o __dtrace_php___execute__entry Zend/.libs/zend_dtrace.o __dtraceenabled_php___error Zend/.libs/zend.o __dtraceenabled_php___function__return Zend/.libs/zend_dtrace.o $dtrace18058.ZEND_CATCH_SPEC_CONST_CV_HANDLER Zend/zend_dtrace.d.o __dtraceenabled_php___exception__thrown Zend/.libs/zend_exceptions.o ld: fatal: Symbol referencing errors. No output written to sapi/cli/php collect2: ld returned 1 exit status gmake: *** [sapi/cli/php] Error 1 - lets discuss what is it and how to fix it. Somewhere over 9000 lines above the building process made this: dtrace -G -o Zend/zend_dtrace.d.o -s /home/emz/src/php-5.4.5/Zend/zend_dtrace.d main/main.o Zend/zend_API.o Zend/zend_execute.o Zend/zend_exceptions.o Zend/zend_dtrace.o Zend/zend.o What is this ? This is the creation of the ELF binary with dtrace probes AND updating of the source object files. This is important. But these source object files at this point are already copied in the .libs directory, which linker is using at the final stage and where it does crash. They should be updated after running dtrace -G but they are not. In order to fix the building you should do it by hand: - copy the files: Zend/zend_API.o Zend/zend_execute.o Zend/zend_exceptions.o Zend/zend_dtrace.o Zend/zend.o to the Zend/.libs - copy the file main/main.o to the main/.libs. They should differ by the way fromthe targets you have in .libs. - issue a 'gmake -r' in the top php source directory so the building will continue. Importa
Bug #63705 [Com]: lack of error message
Edit report at https://bugs.php.net/bug.php?id=63705&edit=1 ID: 63705 Comment by: iam4webwork at hotmail dot com Reported by:iam4webwork at hotmail dot com Summary:lack of error message Status: Not a bug Type: Bug Package:*General Issues PHP Version:Irrelevant Block user comment: N Private report: N New Comment: I respectfully disagree with the Father of PHP about octals only being octals if they have precisely one and only one leading zero. Here is my proof: $a = 012; $b = 0012; $c = 00012; var_dump($a,$b,$c); // all are int 10 in PHP5.4 If $b and $c were not octals then one might expect them to evaluate as 12 or be rejected as invalid data. The failure to provide error messages with respect to poorly formed octals is indeed a bug and can lead to weird comparisons like this: 0777 == 0777812 // true Previous Comments: [2012-12-06 07:53:44] ni...@php.net @rasmus: I still think that we should throw a notice/warning (in the lexer?) when an invalid octal is provided. Or do we have odd BC reasons preventing us from doing so? [2012-12-06 06:12:31] ras...@php.net Octals are by definition identified by a single leading 0, not 2. [2012-12-06 06:08:09] iam4webwork at hotmail dot com Description: PHP fails to display error messages consistently when user provides invalid octals. Test script: --- $octal = 00812; $another= 00934; var_dump( $octal, $another); $will_error = 01c; var_dump( $will_error ); The first two octals PHP accepts as valid input, and silently truncates each. It only displays an error message for 01c and mentions the 'c' being a problem. Why doesn't PHP consistently reject invalid octal values and display error messages? Expected result: I expected error messages to result for each of the first two invalid octals. Instead PHP blindly accepted them while having each evaluate as zero. It only caught on to 01c being a bad octal value. Actual result: -- int 0 int 0 Parse error: syntax error, unexpected 'c' (T_STRING) in ... -- Edit this bug report at https://bugs.php.net/bug.php?id=63705&edit=1
Bug #60586 [Fbk->Opn]: ignore_user_abort=true has no effect on IIS with FastCGI
Edit report at https://bugs.php.net/bug.php?id=60586&edit=1
ID: 60586
Updated by: ahar...@php.net
Reported by:sauvant at aspera dot com
Summary:ignore_user_abort=true has no effect on IIS with
FastCGI
-Status: Feedback
+Status: Open
Type: Bug
Package:IIS related
Operating System: Windows Server 2008 R2
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
A pull request or patch would be much appreciated, I'm sure. :)
Previous Comments:
[2012-12-06 12:43:25] rainer at dueckerhoff dot de
This bug still persists in the latest 5.3 version after about a year of this
bug
report.
Any chance that it could be fixed or any explanation on why it doesn't work
with
IIS but with Apache (and thus cannot be fixed)? Or at least a workaround?
Cheers,
Rainer
[2012-07-10 12:32:43] sauvant at aspera dot com
There is a thread at the IIS forum, too: http://forums.iis.net/t/1190270.aspx
No feedback at all :-(
Is the issue described PHP or IIS related?
Any opinions?
Anybody able to reproduce?
Best regards
Keith
[2012-06-25 15:00:50] lars_teuber at gmx dot de
Microsoft-IIS/7.5. Best regards, Lars.
[2012-06-25 14:54:00] larue...@php.net
you mean IIS or nginx? thanks :)
[2012-06-25 14:45:35] lars_teuber at gmx dot de
Please find reproduce script below. The script stops whenever there is output
send to a browser that is no longer listening. It will continue to run until
you send anything. Best regards, Lars.
https://bugs.php.net/bug.php?id=60586
ignore_user_abort(true);
$path = sys_get_temp_dir() . '\\ignore_user_abort_' . date('Ymd_His', time());
echo $path;
flush();
$seconds = 30;
$time = time();
$i = 0;
while (time() - $time < $seconds) {
echo '. ';
flush();
$i++;
}
write_file($path, 'finished (' . $i . ' iterations)');
function write_file($path, $message)
{
$handle = fopen($path, 'wb');
if (!$handle) {
throw new Exception('fopen() failed');
}
if (fwrite($handle, $message) === false) {
fclose($handle);
throw new Exception('fwrite() failed');
}
if (!fclose($handle)) {
throw new Exception('fclose() failed');
}
}
?>
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=60586
--
Edit this bug report at https://bugs.php.net/bug.php?id=60586&edit=1
Bug #63709 [Opn->Ana]: flock() doesn't trigger mandatory locks on linux
Edit report at https://bugs.php.net/bug.php?id=63709&edit=1
ID: 63709
Updated by: ahar...@php.net
Reported by:eric dot saintetienne at gmail dot com
Summary:flock() doesn't trigger mandatory locks on linux
-Status: Open
+Status: Analyzed
Type: Bug
Package:Filesystem function related
Operating System: Linux
PHP Version:5.3.19
Block user comment: N
Private report: N
New Comment:
The key difference between Python and PHP here is that Python always uses
fcntl() internally, whereas PHP will use flock() if it's available (which it
obviously is on Linux) and will only fall back to fcntl() if it's not. flock()
will never create a mandatory lock, so the manual page is wrong, which I'm
pretty sure is my fault. Mea culpa.
We can probably fix this by switching to preferring fcntl() within our flock()
function as Python does, since that's actually the more useful behaviour, but
that would be a (mild) BC break in how flock() behaves in practice â although
it would actually bring it into line with what's documented.
The options I see are:
1. Change the behaviour of flock() as described above to prefer fcntl().
2. Add a new lockf() function, as suggested.
3. Just bite the bullet and expose fcntl() as a PHP function on POSIX platforms.
4. Do nothing and update the manual. :)
Does anyone have any thoughts? I'm happy to do the donkey work, but am not
really sure on the best way to proceed.
Previous Comments:
[2012-12-06 14:19:38] eric dot saintetienne at gmail dot com
Note that dio_fcntl() of the "Direct IO" extension can successfully exclusively
lock the file, but this shouldn't be considered as a workaround as it's not
always
possible to install extensions.
If flock() couldn't be modified for backward compatibility reasons, options
could
be added to alter its behaviour, or a new call lockf() would be welcome too.
[2012-12-06 13:12:43] eric dot saintetienne at gmail dot com
Description:
Locking exclusively via flock a file opened for writing doesn't trigger a
mandatory lock.
The python script below could trigger the mandatory lock.
Maybe it's because PHP flock() is built on the C function call flock():
"When a program attempts to lock a file with lockf or fcntl that has mandatory
locking set, the kernel will prevent all other programs from accessing the
file.
Processes which use flock will not trigger a mandatory lock."
source: http://www.hackinglinuxexposed.com/articles/20030623.html
Python script:
#!/usr/bin/python
import os, fcntl
fd = os.open('mandlock-file', os.O_RDWR, 0755)
print 'fd=', fd
fcntl.lockf(fd, fcntl.LOCK_EX)
a = raw_input() # during that time, any attempt to open the file will hang
os.write(fd, a+'\n')
fcntl.lockf(fd, fcntl.LOCK_UN)
# now any attempt to open the file will succeed
os.close(fd)
# eof
Test script:
---
Expected result:
once the file is created and the mandatory lock setup for it:
during the 10 sec timer, opening the file (with or without explicit locking)
should hand until the php script terminates.
Actual result:
--
it's possible to opening the locked file during the 10s timer for reading and
writing.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63709&edit=1
Req #63713 [Opn->Wfx]: Need an "UNDEFINED" type
Edit report at https://bugs.php.net/bug.php?id=63713&edit=1
ID: 63713
Updated by: ahar...@php.net
Reported by:liquid_nitrogen_4ever at yahoo dot com
Summary:Need an "UNDEFINED" type
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
Package:Variables related
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I don't see much value in this: it's an unusual use case, would require engine
changes, and you can already check if a variable is defined with
array_key_exists('notExistentVariable', get_defined_vars()).
Previous Comments:
[2012-12-06 17:42:43] liquid_nitrogen_4ever at yahoo dot com
Description:
Consider the following scenario currently in PHP:
var_dump($notExistentVariable);
-> NOTICE: Undefined variable notHere on line 1
NULL
isset($notExistentVariable);
-> FALSE
$foo = null;
var_dump($foo);
-> NULL
isset($foo);
-> FALSE
If there were an UNDEFINED "type" (in the same sense that there is a NULL), the
above scenarios would change to:
var_dump($notExistentVariable);
-> UNDEFINED
isset($notExistentVariable);
-> FALSE
$foo = null;
var_dump($foo);
-> NULL
isset($foo);
-> TRUE
However, unlike NULL, you would NOT be allowed to explicitly initialize
something to UNDEFINED.
$x=UNDEFINED;//error: if you want it to be undefined, don't declare it.
However, having just:
$x;
makes sense (to me at least) as shortcut to:
$x=NULL;
In other words, if a variable is declared but not explicitly initialized, it
will implicitly be set to NULL (which is
essentially what you are already doing, but one can't really differentiate
between declared and undeclared variables).
--
Edit this bug report at https://bugs.php.net/bug.php?id=63713&edit=1
[PHP-BUG] Bug #63714 [NEW]: incorrect global statement
From: axdr at bk dot ru
Operating system: Windows
PHP version: 5.4.9
Package: Scripting Engine problem
Bug Type: Bug
Bug description:incorrect global statement
Description:
'global'-declaration inside a function dosn't affect referencies.
Test script:
---
function func() {
global $a, $b;
$a = 'aaa';
$b = &$a;
$GLOBALS['c'] = &$a;
}
func();
echo "$a, $b, $c";
Expected result:
aaa, aaa, aaa
Actual result:
--
aaa, , aaa
--
Edit bug report at https://bugs.php.net/bug.php?id=63714&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63714&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63714&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63714&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63714&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63714&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63714&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63714&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63714&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63714&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63714&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63714&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63714&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63714&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63714&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63714&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63714&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63714&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63714&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63714&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63714&r=mysqlcfg
Bug #63714 [Opn]: incorrect global statement
Edit report at https://bugs.php.net/bug.php?id=63714&edit=1
ID: 63714
User updated by:axdr at bk dot ru
Reported by:axdr at bk dot ru
Summary:incorrect global statement
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Windows
PHP Version:5.4.9
Block user comment: N
Private report: N
New Comment:
'global'-declaration kills referencies
function func() {
global $a, $b;
$a = 'aaa';
$b = &$a;
echo "$a, $b", '';
global $a, $b;
echo "$a, $b";
}
func();
output:
aaa, aaa
aaa,
Previous Comments:
[2012-12-07 02:37:38] axdr at bk dot ru
Description:
'global'-declaration inside a function dosn't affect referencies.
Test script:
---
function func() {
global $a, $b;
$a = 'aaa';
$b = &$a;
$GLOBALS['c'] = &$a;
}
func();
echo "$a, $b, $c";
Expected result:
aaa, aaa, aaa
Actual result:
--
aaa, , aaa
--
Edit this bug report at https://bugs.php.net/bug.php?id=63714&edit=1
Bug #63714 [Opn->Nab]: incorrect global statement
Edit report at https://bugs.php.net/bug.php?id=63714&edit=1
ID: 63714
Updated by: larue...@php.net
Reported by:axdr at bk dot ru
Summary:incorrect global statement
-Status: Open
+Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Windows
PHP Version:5.4.9
Block user comment: N
Private report: N
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
global $a;
make a local variable 'a' reference to $GLOBALS['a'];
also thinking of:
$b = &$a; // b reference to a
$b = &$c; // change reference to c
then:
global $a, $b; //b reference to $GLOBALS['b']
$a = 'aaa';
$b = &$a;//b now reference to local $a with GLOBALS['b'] unchanged
Previous Comments:
[2012-12-07 02:44:58] axdr at bk dot ru
'global'-declaration kills referencies
function func() {
global $a, $b;
$a = 'aaa';
$b = &$a;
echo "$a, $b", '';
global $a, $b;
echo "$a, $b";
}
func();
output:
aaa, aaa
aaa,
[2012-12-07 02:37:38] axdr at bk dot ru
Description:
'global'-declaration inside a function dosn't affect referencies.
Test script:
---
function func() {
global $a, $b;
$a = 'aaa';
$b = &$a;
$GLOBALS['c'] = &$a;
}
func();
echo "$a, $b, $c";
Expected result:
aaa, aaa, aaa
Actual result:
--
aaa, , aaa
--
Edit this bug report at https://bugs.php.net/bug.php?id=63714&edit=1
Bug #63714 [Nab]: incorrect global statement
Edit report at https://bugs.php.net/bug.php?id=63714&edit=1
ID: 63714
Updated by: larue...@php.net
Reported by:axdr at bk dot ru
Summary:incorrect global statement
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Windows
PHP Version:5.4.9
Block user comment: N
Private report: N
New Comment:
also see:
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
global $a;
make a local variable 'a' reference to $GLOBALS['a'];
also thinking of:
$b = &$a; // b reference to a
$b = &$c; // change reference to c
then:
global $a, $b; //b reference to $GLOBALS['b']
$a = 'aaa';
$b = &$a;//b now reference to local $a with GLOBALS['b'] unchanged
[2012-12-07 02:44:58] axdr at bk dot ru
'global'-declaration kills referencies
function func() {
global $a, $b;
$a = 'aaa';
$b = &$a;
echo "$a, $b", '';
global $a, $b;
echo "$a, $b";
}
func();
output:
aaa, aaa
aaa,
[2012-12-07 02:37:38] axdr at bk dot ru
Description:
'global'-declaration inside a function dosn't affect referencies.
Test script:
---
function func() {
global $a, $b;
$a = 'aaa';
$b = &$a;
$GLOBALS['c'] = &$a;
}
func();
echo "$a, $b, $c";
Expected result:
aaa, aaa, aaa
Actual result:
--
aaa, , aaa
--
Edit this bug report at https://bugs.php.net/bug.php?id=63714&edit=1
Bug #63709 [Ana]: flock() doesn't trigger mandatory locks on linux
Edit report at https://bugs.php.net/bug.php?id=63709&edit=1
ID: 63709
Updated by: larue...@php.net
Reported by:eric dot saintetienne at gmail dot com
Summary:flock() doesn't trigger mandatory locks on linux
Status: Analyzed
Type: Bug
Package:Filesystem function related
Operating System: Linux
PHP Version:5.3.19
Block user comment: N
Private report: N
New Comment:
I like 3 :)
change the behavior of flock will intruduce a visible bc break
Previous Comments:
[2012-12-07 01:48:08] ahar...@php.net
The key difference between Python and PHP here is that Python always uses
fcntl() internally, whereas PHP will use flock() if it's available (which it
obviously is on Linux) and will only fall back to fcntl() if it's not. flock()
will never create a mandatory lock, so the manual page is wrong, which I'm
pretty sure is my fault. Mea culpa.
We can probably fix this by switching to preferring fcntl() within our flock()
function as Python does, since that's actually the more useful behaviour, but
that would be a (mild) BC break in how flock() behaves in practice â although
it would actually bring it into line with what's documented.
The options I see are:
1. Change the behaviour of flock() as described above to prefer fcntl().
2. Add a new lockf() function, as suggested.
3. Just bite the bullet and expose fcntl() as a PHP function on POSIX platforms.
4. Do nothing and update the manual. :)
Does anyone have any thoughts? I'm happy to do the donkey work, but am not
really sure on the best way to proceed.
[2012-12-06 14:19:38] eric dot saintetienne at gmail dot com
Note that dio_fcntl() of the "Direct IO" extension can successfully exclusively
lock the file, but this shouldn't be considered as a workaround as it's not
always
possible to install extensions.
If flock() couldn't be modified for backward compatibility reasons, options
could
be added to alter its behaviour, or a new call lockf() would be welcome too.
[2012-12-06 13:12:43] eric dot saintetienne at gmail dot com
Description:
Locking exclusively via flock a file opened for writing doesn't trigger a
mandatory lock.
The python script below could trigger the mandatory lock.
Maybe it's because PHP flock() is built on the C function call flock():
"When a program attempts to lock a file with lockf or fcntl that has mandatory
locking set, the kernel will prevent all other programs from accessing the
file.
Processes which use flock will not trigger a mandatory lock."
source: http://www.hackinglinuxexposed.com/articles/20030623.html
Python script:
#!/usr/bin/python
import os, fcntl
fd = os.open('mandlock-file', os.O_RDWR, 0755)
print 'fd=', fd
fcntl.lockf(fd, fcntl.LOCK_EX)
a = raw_input() # during that time, any attempt to open the file will hang
os.write(fd, a+'\n')
fcntl.lockf(fd, fcntl.LOCK_UN)
# now any attempt to open the file will succeed
os.close(fd)
# eof
Test script:
---
Expected result:
once the file is created and the mandatory lock setup for it:
during the 10 sec timer, opening the file (with or without explicit locking)
should hand until the php script terminates.
Actual result:
--
it's possible to opening the locked file during the 10s timer for reading and
writing.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63709&edit=1
[PHP-BUG] Bug #63715 [NEW]: usort not sorting correctly
From: shabbir dot bhojani at objectsynergy dot com
Operating system: Windows 7 x64
PHP version: 5.3.19
Package: Unknown/Other Function
Bug Type: Bug
Bug description:usort not sorting correctly
Description:
Doesn't sort correctly. I'm attempting to sort so that the values 'c' and
'd' show
up on the top in that order followed by the other values sorted using
strcasecmp.
'c' and 'd' do show up on the top of the sorted array but not in that
order.
Test script:
---
$x = array('a','b','c','d','e','f');
usort($x, function ($a, $b) {
// must return an integer less than, equal to, or greater than zero
if the first argument is considered to be respectively less than, equal to,
or greater than the second
static $custom_sort_data = array(
'c' => 256,
'd' => 255,
);
if (isset($custom_sort_data[$a]))
return -$custom_sort_data[$a];
if (isset($custom_sort_data[$b]))
return $custom_sort_data[$b];
return strcasecmp($a, $b);
});
var_dump($x);
Expected result:
array(6) { [0] => string(1) "c" [1] => string(1) "d" [2] => string(1) "a"
[3] =>
string(1) "b" [4] => string(1) "e" [5] => string(1) "f" }
Actual result:
--
array(6) { [0] => string(1) "d" [1] => string(1) "c" [2] => string(1) "a"
[3] =>
string(1) "b" [4] => string(1) "e" [5] => string(1) "f" }
--
Edit bug report at https://bugs.php.net/bug.php?id=63715&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63715&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63715&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63715&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63715&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63715&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63715&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63715&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63715&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63715&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63715&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63715&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63715&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63715&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63715&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63715&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63715&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63715&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63715&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63715&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63715&r=mysqlcfg
Bug #63715 [Opn->Nab]: usort not sorting correctly
Edit report at https://bugs.php.net/bug.php?id=63715&edit=1
ID: 63715
Updated by: ahar...@php.net
Reported by:shabbir dot bhojani at objectsynergy dot com
Summary:usort not sorting correctly
-Status: Open
+Status: Not a bug
Type: Bug
Package:Unknown/Other Function
Operating System: Windows 7 x64
PHP Version:5.3.19
Block user comment: N
Private report: N
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
usort() doesn't pay attention to the magnitude of the return value.
Previous Comments:
[2012-12-07 03:38:08] shabbir dot bhojani at objectsynergy dot com
Description:
Doesn't sort correctly. I'm attempting to sort so that the values 'c' and 'd'
show
up on the top in that order followed by the other values sorted using
strcasecmp.
'c' and 'd' do show up on the top of the sorted array but not in that order.
Test script:
---
$x = array('a','b','c','d','e','f');
usort($x, function ($a, $b) {
// must return an integer less than, equal to, or greater than zero if
the first argument is considered to be respectively less than, equal to, or
greater than the second
static $custom_sort_data = array(
'c' => 256,
'd' => 255,
);
if (isset($custom_sort_data[$a]))
return -$custom_sort_data[$a];
if (isset($custom_sort_data[$b]))
return $custom_sort_data[$b];
return strcasecmp($a, $b);
});
var_dump($x);
Expected result:
array(6) { [0] => string(1) "c" [1] => string(1) "d" [2] => string(1) "a" [3]
=>
string(1) "b" [4] => string(1) "e" [5] => string(1) "f" }
Actual result:
--
array(6) { [0] => string(1) "d" [1] => string(1) "c" [2] => string(1) "a" [3]
=>
string(1) "b" [4] => string(1) "e" [5] => string(1) "f" }
--
Edit this bug report at https://bugs.php.net/bug.php?id=63715&edit=1
Bug #63714 [Nab]: incorrect global statement
Edit report at https://bugs.php.net/bug.php?id=63714&edit=1
ID: 63714
User updated by:axdr at bk dot ru
Reported by:axdr at bk dot ru
Summary:incorrect global statement
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Windows
PHP Version:5.4.9
Block user comment: N
Private report: N
New Comment:
Sorry. You are right.
But I think this is irrational.
It's impossible to read all documentation and to remember word for word.
This is a kind of underwater mine.
Previous Comments:
[2012-12-07 02:54:35] larue...@php.net
also see:
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
global $a;
make a local variable 'a' reference to $GLOBALS['a'];
also thinking of:
$b = &$a; // b reference to a
$b = &$c; // change reference to c
then:
global $a, $b; //b reference to $GLOBALS['b']
$a = 'aaa';
$b = &$a;//b now reference to local $a with GLOBALS['b'] unchanged
[2012-12-07 02:44:58] axdr at bk dot ru
'global'-declaration kills referencies
function func() {
global $a, $b;
$a = 'aaa';
$b = &$a;
echo "$a, $b", '';
global $a, $b;
echo "$a, $b";
}
func();
output:
aaa, aaa
aaa,
[2012-12-07 02:37:38] axdr at bk dot ru
Description:
'global'-declaration inside a function dosn't affect referencies.
Test script:
---
function func() {
global $a, $b;
$a = 'aaa';
$b = &$a;
$GLOBALS['c'] = &$a;
}
func();
echo "$a, $b, $c";
Expected result:
aaa, aaa, aaa
Actual result:
--
aaa, , aaa
--
Edit this bug report at https://bugs.php.net/bug.php?id=63714&edit=1
Bug #63715 [Nab]: usort not sorting correctly
Edit report at https://bugs.php.net/bug.php?id=63715&edit=1
ID: 63715
User updated by:shabbir dot bhojani at objectsynergy dot com
Reported by:shabbir dot bhojani at objectsynergy dot com
Summary:usort not sorting correctly
Status: Not a bug
Type: Bug
Package:Unknown/Other Function
Operating System: Windows 7 x64
PHP Version:5.3.19
Block user comment: N
Private report: N
New Comment:
My mistake: "usort() doesn't pay attention to the magnitude of the return
value.".
For the record, this solved it for me:
$x = array('a', 'b', 'c', 'd', 'e', 'f');
usort($x, $y = function ($a, $b) {
// must return an integer less than, equal to, or greater than zero if
the
first argument is considered to be respectively less than, equal to, or greater
than the second
static $custom_sort_data = array(
'c' => 256,
'd' => 255,
);
if (isset($custom_sort_data[$a]) && isset($custom_sort_data[$b])) {
return $custom_sort_data[$b] - $custom_sort_data[$a];
}
if (isset($custom_sort_data[$b]))
return 1;
if (isset($custom_sort_data[$a]))
return -1;
return strcasecmp($a, $b);
});
var_dump($x);
Previous Comments:
[2012-12-07 03:44:57] ahar...@php.net
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
usort() doesn't pay attention to the magnitude of the return value.
[2012-12-07 03:38:08] shabbir dot bhojani at objectsynergy dot com
Description:
Doesn't sort correctly. I'm attempting to sort so that the values 'c' and 'd'
show
up on the top in that order followed by the other values sorted using
strcasecmp.
'c' and 'd' do show up on the top of the sorted array but not in that order.
Test script:
---
$x = array('a','b','c','d','e','f');
usort($x, function ($a, $b) {
// must return an integer less than, equal to, or greater than zero if
the first argument is considered to be respectively less than, equal to, or
greater than the second
static $custom_sort_data = array(
'c' => 256,
'd' => 255,
);
if (isset($custom_sort_data[$a]))
return -$custom_sort_data[$a];
if (isset($custom_sort_data[$b]))
return $custom_sort_data[$b];
return strcasecmp($a, $b);
});
var_dump($x);
Expected result:
array(6) { [0] => string(1) "c" [1] => string(1) "d" [2] => string(1) "a" [3]
=>
string(1) "b" [4] => string(1) "e" [5] => string(1) "f" }
Actual result:
--
array(6) { [0] => string(1) "d" [1] => string(1) "c" [2] => string(1) "a" [3]
=>
string(1) "b" [4] => string(1) "e" [5] => string(1) "f" }
--
Edit this bug report at https://bugs.php.net/bug.php?id=63715&edit=1
