[PHP-BUG] Bug #63447 [NEW]: max_input_vars doesn't filter variables when mbstring.encoding_translation = On
From: na24am at gmail dot com
Operating system: MacOS X Lion
PHP version: 5.4.8
Package: Variables related
Bug Type: Bug
Bug description:max_input_vars doesn't filter variables when
mbstring.encoding_translation = On
Description:
max_input_vars doesn't filter variables when mbstring.encoding_translation
= On
--
mbstring.encoding_translation = On
max_input_vars = 2
Test script:
---
Expected result:
Warning: Unknown: Input variables exceeded 2. To increase the limit change
max_input_vars in php.ini. in Unknown on line 0
array(2) { ["value01"]=> string(6) "test01" ["value02"]=> string(6)
"test02" }
Actual result:
--
array(4) { ["value01"]=> string(6) "test01" ["value02"]=> string(6)
"test02"
["value03"]=> string(6) "test03" ["value04"]=> string(6) "test04" }
--
Edit bug report at https://bugs.php.net/bug.php?id=63447&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63447&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63447&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63447&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63447&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63447&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63447&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63447&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63447&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63447&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63447&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63447&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63447&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63447&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63447&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63447&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63447&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63447&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63447&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63447&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63447&r=mysqlcfg
[PHP-BUG] Bug #63448 [NEW]: False values lead to empty tags
From: ctreptow at neutrasoft dot de
Operating system: Win7
PHP version: Irrelevant
Package: SOAP related
Bug Type: Bug
Bug description:False values lead to empty tags
Description:
Using the NTLM-Version of the soap client (can be found under
http://code.google.com/p/php-ews/source/browse/NTLMSoapClient.php)
i had problems filtering a WS-Page from Microsoft Navision on boolean
fields, but only if the filter-value is FALSE.
sample of wsdl is available on http://pastebin.com/R25p62sb
note: the problem does not occur in the NTLMSoapClient (just a
NTLM-wrapper), the generated message comes from the SoapClient.
tested on 5.3 and 5.4
Test script:
---
$params = array(
"soap_version" => SOAP_1_1,
"trace"=> true,
"cache_wsdl" => WSDL_CACHE_NONE,
"exceptions" => true
);
$url = "http://host:7047/DynamicsNAV/WS/Company/Page/Customers?wsdl";;
$client = @new NTLMSoapClient($url, $params);
$args = array(
'setSize' => 300,
'filter' => array(
array("Field"=>'BoolField',"Criteria"=>false)
)
);
$client->ReadMultiple($args);
Expected result:
intercepted SOAP-Message:
http://schemas.xmlsoap.org/soap/envelope/";
xmlns:ns1="urn:microsoft-dynamics-schemas/page/customers">
BoolField
0
300
Actual result:
--
intercepted SOAP-Message:
http://schemas.xmlsoap.org/soap/envelope/";
xmlns:ns1="urn:microsoft-dynamics-schemas/page/customers">
BoolField
300
--
Edit bug report at https://bugs.php.net/bug.php?id=63448&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63448&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63448&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63448&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63448&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63448&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63448&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63448&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63448&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63448&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63448&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63448&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63448&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63448&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63448&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63448&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63448&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63448&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63448&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63448&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63448&r=mysqlcfg
Bug #40664 [Com]: String conversion functions wrong for multibyte chars
Edit report at https://bugs.php.net/bug.php?id=40664&edit=1
ID: 40664
Comment by: ddowns at online-access dot com
Reported by:fjortiz at comunet dot es
Summary:String conversion functions wrong for multibyte
chars
Status: Assigned
Type: Bug
Package:COM related
Operating System: Win32
PHP Version:5.2.1
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
I went to apply the patch and its already there in 5.3.18. Not sure when this
was
actually solved but the bug status needs updating.
Previous Comments:
[2012-08-08 07:24:29] sager at agitos dot de
The patch is still missing in PHP 5.3.15 (I don't know why, the patch is
working: thanks to fjortiz!)
So I compiled php_com_dotnet.dll that is compatible to
http://windows.php.net/downloads/releases/php-5.3.15-nts-Win32-VC9-x86.msi
Download this compiled dll at
http://www.agitos.de/pub/php-5.3.15-com_dotnet-patch.zip
[2010-08-01 17:45:49] ivars_ju at inbox dot lv
Hi,
i still have this bug in PHP Version 5.3.3
Is it so hard to commit this?
[2009-10-20 10:50:13] paj...@php.net
taking the hand on this one.
[2009-10-20 10:36:01] fjortiz at comunet dot es
after 2,5 years, can someone just commit the patch I provided to cvs?. It's
annoying to recompile any PHP version that comes out just for the sake of this
nonsense. Take into account that any use of PHP+COM+multibyte stuff fails
without this silly fix.
Thank you.
[2009-03-22 10:12:22] j dot novak at netsystem dot cz
I see same problem with ADODB.Connection and it's parameters.
When I use:
// init connection to DB
$dbc = new COM('ADODB.Connection',null,CP_UTF8);
$dbc->Open("PROVIDER=MSDASQL;Driver={SQL
Server};Server=192.168.210.1;Database=test;UID=test;PWD=test");
// create command
$oCmd = new COM('ADODB.Command',null,CP_UTF8);
$oCmd->ActiveConnection = $dbc; //
// Table test1 has one row c1 of type nvarchar(200)
$oCmd->CommandText = "INSERT INTO test1(c1) VALUES (?)";
$oCmd->CommandType = 1;
// Some UTF-8 string (length in characters is 15, 24 in bytes)
$val='ABCÅÚúÄÄáéóXYZ';
$len=strlen($val);
$p=$oCmd->CreateParameter('name',202,1,$len,$val);
$oCmd->Parameters->Append($p);
$oCmd->Execute();
// ADODB sends to DB nvarchar(24) which is length of string
// in bytes not characters, but data has 15 characters
// in UCS-2. So in database there is correct string, but there is
// some garbage after end of string
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=40664
--
Edit this bug report at https://bugs.php.net/bug.php?id=40664&edit=1
Bug #60268 [Com]: Compiling PHP fails
Edit report at https://bugs.php.net/bug.php?id=60268&edit=1 ID: 60268 Comment by: estevao dot santos at ci2 dot pt Reported by:rich06 at gmail dot com Summary:Compiling PHP fails Status: Closed Type: Bug Package:Compile Failure Operating System: Mac OS X 10.7.2 (Lion) PHP Version:5.3.8 Assigned To:patrickallaert Block user comment: N Private report: N New Comment: This happens to me to compiling PHP 5.4.8 on MAC OSX 10.7 (Lion). Even with the Makefile edition fix proposed in the comments I still get the same error. I have Macports and installed libiconv through macports. Tried a custom compiled libiconv to no avail. Previous Comments: [2012-04-09 23:27:47] thehuey at gmail dot com Same problem. Makefile edit to point at /opt/local/lib worked for me as well. [2012-03-31 20:38:25] SaraviaJ at gmail dot com I had this same issue when compiling PHP5.4 on Mac OS X 10.6.8 ( Snow Leopard ) I tried both the local copy of the iconv library that and also tried to specify one that I got via fink. I had to perform the correction that rich mentioned and changed the path to a the version of iconv that I compiled. [2012-03-09 09:30:47] sander at myxt dot nl If you are on OSX and using Xcode 4.3, make sure you install the command line tools. That should solve a good deal of extension compiling errors. [2012-03-05 18:28:47] dedalo at doramail dot com This is a still an issue men and it's not related to --with-apxs2. This is my configure command line: sudo ./configure --prefix=/usr/local --with-apxs2=/usr/sbin/apxs --with-ldap=/usr --with-kerberos=/usr --enable-cli --with-zlib-dir=/usr --enable-exif --enable-ftp --enable-mbstring --enable-mbregex --enable-sockets --with-iodbc=/usr --with-curl=/usr --with-config-file-path=/etc --sysconfdir=/private/etc --with-mysql-sock=/var/mysql/mysql.sock --with-mysql=mysqlnd --with-mysqli=mysqlnd --with-openssl=/usr --with-xmlrpc --with-xsl=/usr --without-pear --with-libxml-dir=/usr --with-iconv-dir=/opt/local --with-gd --with-jpeg-dir=/opt/local --with-png-dir=/opt/local --with-freetype-dir=/opt/local --with-mcrypt=/opt/local As you can see, there is a file path for apsx2 option: --with-apxs2=/usr/sbin/apxs But the make still fails. To make it work, I changed the Makefile, in particular the MH_BUNDLE_FLAGS, like suggested by rich06, as follow: -L/opt/local/lib This is a bug, and it's still there. Reopen it, please. [2011-12-08 10:43:44] lolautruche at gmail dot com I don't agree here, as ./configure --help says: --with-apxs2=FILE Build shared Apache 2.0 Handler module. FILE is the optional pathname to the Apache apxs tool apxs So FILE is optional 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=60268 -- Edit this bug report at https://bugs.php.net/bug.php?id=60268&edit=1
[PHP-BUG] Bug #63449 [NEW]: SplObjectStorage should work more like a real array()
From: dave at smartboy dot com
Operating system: Linux
PHP version: 5.4.8
Package: SPL related
Bug Type: Bug
Bug description:SplObjectStorage should work more like a real array()
Description:
Attempting to use instances of class SplObjectStorage as an array results
in
exceptions and generally does not work as expected.
Test script:
---
$s = new SplObjectStorage;
$o = new stdClass;
$s[$o]["key"] = "value";
var_export($s[$o]);
// Fatal error: Uncaught exception 'UnexpectedValueException' with message
'Object not found'
Expected result:
The above sample code should create an array for the object key inside
SplObjectStorage, and display:
array (
'key' => 'value',
)
Compare the above code with:
$s = array();
$o = "someKey";
$s[$o]["key"] = "value";
var_export($s[$o]);
which works as expected and displays
array (
'key' => 'value',
)
Actual result:
--
Fatal error: Uncaught exception 'UnexpectedValueException' with message
'Object
not found' in Command line code:1
Stack trace:
#0 Command line code(1): SplObjectStorage->offsetGet(Object(stdClass))
#1 {main}
thrown in Command line code on line 1
--
Edit bug report at https://bugs.php.net/bug.php?id=63449&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63449&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63449&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63449&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63449&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63449&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63449&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63449&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63449&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63449&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63449&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63449&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63449&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63449&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63449&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63449&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63449&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63449&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63449&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63449&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63449&r=mysqlcfg
[PHP-BUG] Bug #63450 [NEW]: iconv returns false when illegal character encountered
From: trollofdarkness at gmail dot com Operating system: Debian 5 Lenny PHP version: 5.4.8 Package: ICONV related Bug Type: Bug Bug description:iconv returns false when illegal character encountered Description: Hi everyone, I have been, since I think the version 5.3.x is out (and still with 5.4.8), experiencing issues with iconv. Especially, when an illegal character is encountered and the //IGNORE flag is set on the target charset, the function returns FALSE instead of just skipping this character. This is problematic because if a single character in a 50 000 chars long string is "illegal" then the output is nothing, just for one char... It does not happen with the TRANSLIT flag. I experienced that with UTF8 (from) and ISO-8859-15 (to) charsets, I did not test with other ones. Below is an example to reproduce the bug. Note : I saw there are other bug reports about similar issues, but they're all saying the string is cut... In my case, it literally returns false. So, might be different? Test script: --- Expected result: foo foo Actual result: -- false -- Edit bug report at https://bugs.php.net/bug.php?id=63450&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63450&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63450&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63450&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63450&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63450&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63450&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63450&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63450&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63450&r=support Expected behavior: https://bugs.php.net/fix.php?id=63450&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63450&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63450&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63450&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63450&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63450&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63450&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63450&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63450&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63450&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63450&r=mysqlcfg
Bug #63450 [Opn->Nab]: iconv returns false when illegal character encountered
Edit report at https://bugs.php.net/bug.php?id=63450&edit=1 ID: 63450 Updated by: ras...@php.net Reported by:trollofdarkness at gmail dot com Summary:iconv returns false when illegal character encountered -Status: Open +Status: Not a bug Type: Bug Package:ICONV related Operating System: Debian 5 Lenny PHP Version:5.4.8 Block user comment: N Private report: N New Comment: This is not a PHP issue. This is a change in recent versions of libiconv. If you link PHP against an older version of libiconv it will work again or you can use mbstring_convert_encoding(). And we have a new uconverter extension feature coming that will do a better job than either of these. See https://wiki.php.net/rfc/uconverter Previous Comments: [2012-11-06 21:45:33] trollofdarkness at gmail dot com Description: Hi everyone, I have been, since I think the version 5.3.x is out (and still with 5.4.8), experiencing issues with iconv. Especially, when an illegal character is encountered and the //IGNORE flag is set on the target charset, the function returns FALSE instead of just skipping this character. This is problematic because if a single character in a 50 000 chars long string is "illegal" then the output is nothing, just for one char... It does not happen with the TRANSLIT flag. I experienced that with UTF8 (from) and ISO-8859-15 (to) charsets, I did not test with other ones. Below is an example to reproduce the bug. Note : I saw there are other bug reports about similar issues, but they're all saying the string is cut... In my case, it literally returns false. So, might be different? Test script: --- Expected result: foo foo Actual result: -- false -- Edit this bug report at https://bugs.php.net/bug.php?id=63450&edit=1
Bug #63450 [Com]: iconv returns false when illegal character encountered
Edit report at https://bugs.php.net/bug.php?id=63450&edit=1 ID: 63450 Comment by: trollofdarkness at gmail dot com Reported by:trollofdarkness at gmail dot com Summary:iconv returns false when illegal character encountered Status: Not a bug Type: Bug Package:ICONV related Operating System: Debian 5 Lenny PHP Version:5.4.8 Block user comment: N Private report: N New Comment: Hi Rasmus, Thanks for your help! I will have a look at that on the spot and will post an update to say if it works to downgrade the libiconv. Previous Comments: [2012-11-06 21:54:00] ras...@php.net This is not a PHP issue. This is a change in recent versions of libiconv. If you link PHP against an older version of libiconv it will work again or you can use mbstring_convert_encoding(). And we have a new uconverter extension feature coming that will do a better job than either of these. See https://wiki.php.net/rfc/uconverter [2012-11-06 21:45:33] trollofdarkness at gmail dot com Description: Hi everyone, I have been, since I think the version 5.3.x is out (and still with 5.4.8), experiencing issues with iconv. Especially, when an illegal character is encountered and the //IGNORE flag is set on the target charset, the function returns FALSE instead of just skipping this character. This is problematic because if a single character in a 50 000 chars long string is "illegal" then the output is nothing, just for one char... It does not happen with the TRANSLIT flag. I experienced that with UTF8 (from) and ISO-8859-15 (to) charsets, I did not test with other ones. Below is an example to reproduce the bug. Note : I saw there are other bug reports about similar issues, but they're all saying the string is cut... In my case, it literally returns false. So, might be different? Test script: --- Expected result: foo foo Actual result: -- false -- Edit this bug report at https://bugs.php.net/bug.php?id=63450&edit=1
Bug #47397 [Com]: php://stdout gives odd behavior under CGI/Apache
Edit report at https://bugs.php.net/bug.php?id=47397&edit=1
ID: 47397
Comment by: jasen at treshna dot com
Reported by:shaunspiller at gmail dot com
Summary:php://stdout gives odd behavior under CGI/Apache
Status: No Feedback
Type: Bug
Package:Output Control
Operating System: Any?
PHP Version:5.2.9RC2
Block user comment: N
Private report: N
New Comment:
Jani linked to the answer in comment 1
the CGI, CLI, and apache module environments
all have different standard definitions of STDOUT
These standards are outside of the control of PHP
If you want stdout use stdout, If you want fwrite to work like echo
use "php://output" instead.
If you found documentation unclear or incomplete you could rause a bug against
thwe documentatuion.
Previous Comments:
[2009-11-27 11:47:26] ruj dot sabya at gmail dot com
I am also facing this problem.
Version: 5.2.9-2
[2009-02-23 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2009-02-16 16:12:56] shaunspiller at gmail dot com
I'm using "php-5.2.9RC2-Win32-VC6-x86.zip" (last modified: 2009-Feb-12).
The STDOUT constant is only defined for CLI. The documentation isn't clear on
what the correct behavior of the stdout stream should be under other interfaces.
[2009-02-15 23:15:53] j...@php.net
1. Exactly what PHP version are you using here?
2. What if you don't open another stdout stream but use the STDOUT
constant, does it work better..?
For more info: http://www.php.net/wrappers.php
[2009-02-15 19:16:22] shaunspiller at gmail dot com
Description:
Hi!
I think this might be a bug. I was writing some code that used output
buffering, but which also bypassed it by writing directly to stdout. I've done
before it under CLI but the results I got under CGI and as an Apache module
were a bit strange:
Example 1:
--
\n";
ob_start();
echo "2. echo, during output buffering\n";
flush();
/* in theory, this line will be output immediately while 2 & 4 will be held
back until ob_end_flush() */
$stdout = fopen('php://stdout', 'w');
fwrite($stdout, "3. fwrite to stdout, during output buffering\n");
echo "4. echo, during output buffering\n";
ob_end_flush();
echo "5. echo, after output buffering\n";
?>
Result:
---
I'm not expert on how PHP communicates with its various output mechanisms.
These are just my observations from testing this code:
* Under CLI, this example works, and the displayed order is 1, 3, 2, 4, 5.
* As an Apache module, no. 3 is never output, no matter how much I try to flush
it through. (Maybe that is the intended behavior, since the STDOUT constant is
not defined.)
* Under CGI, no. 3 is never output **unless** at least 1 previous byte has
been flushed (provided by the echo()s and flush() call, above). In that case,
the displayed order is 1, 3, 2, 4, 5 again. I'm not sure if it's supposed to
work or not, but the inconsistency seems wrong.
* (In all cases, the fopen call returns a valid stream.)
Example 2:
--
http://www.php.net/\r\n";);
?>
Result:
---
This is even stranger. Under CGI, if at least one call to header() has been
made and no other data has yet been flushed, writing to stdout puts data
directly into the HTTP response. In this case I've used a complete valid header
so it can be tested from a browser.
It's also possible to write complete garbage into the headers, bypassing the
header() function's restrictions (this is best observed via telnet), and this
is what was unintentionally happening when I first encountered this.
Expected result:
It would be nice if stdout would always work, and always bypass output
buffering. Otherwise, it should at least be consistent within each interface.
--
Edit this bug report at https://bugs.php.net/bug.php?id=47397&edit=1
[PHP-BUG] Bug #63451 [NEW]: config.guess file does not have AIX 7 defined, shared objects are not created
From: kemcline at au1 dot ibm dot com Operating system: AIX 7.1 PHP version: 5.4.8 Package: Apache2 related Bug Type: Bug Bug description:config.guess file does not have AIX 7 defined, shared objects are not created Description: The config.guess is not written to have support for AIX 7. This causes the configure script to make shared libraries not available. The AIX456 line in the system type case statement is currently defined as: *:AIX:*:[456]) The line needs to be changed to include the 7 for AIX 7. In the aclocal.m4 file, the similar line for aix is aix[[4-9]]*), planning for future versions of AIX. The result you will see without the 7 in the config.guess file is: checking whether the cc -qlanglvl=extc89 linker (/usr/bin/ld) supports shared libraries... no As a workaround, this can be resolved by adding a 7 to the line: *:AIX:*:[4567]) Expected result: checking whether the cc -qlanglvl=extc89 linker (/usr/bin/ld) supports shared libraries... yes Actual result: -- checking whether the cc -qlanglvl=extc89 linker (/usr/bin/ld) supports shared libraries... no -- Edit bug report at https://bugs.php.net/bug.php?id=63451&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63451&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63451&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63451&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63451&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63451&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63451&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63451&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63451&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63451&r=support Expected behavior: https://bugs.php.net/fix.php?id=63451&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63451&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63451&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63451&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63451&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63451&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63451&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63451&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63451&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63451&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63451&r=mysqlcfg
