[PHP-BUG] Bug #61855 [NEW]: Wrong division of float numbers
From: Operating system: Linux PHP version: 5.3.10 Package: Math related Bug Type: Bug Bug description:Wrong division of float numbers Description: --- >From manual page: http://www.php.net/function.floor#refsect1-function.floor-description --- I encountered problem when dividing float numbers. It's simple formula which can be solved by 10 year old child. But not by PHP! See example. The problem is that displayed value (3) doesn't correspond with internal value 2.999 and floor() then returns 2 which is obviously incorrect result! And that's serious problem. The same code in C returns correct numbers. Test script: --- Expected result: v(15) = 3.000 v(16) = 3. v = 3 floor(v) = 3 Actual result: -- v(15) = 3.000 v(16) = 2.9996 v = 3 floor(v) = 2 -- Edit bug report at https://bugs.php.net/bug.php?id=61855&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61855&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61855&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61855&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61855&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61855&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61855&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61855&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61855&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61855&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61855&r=support Expected behavior: https://bugs.php.net/fix.php?id=61855&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61855&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61855&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61855&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61855&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61855&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61855&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61855&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61855&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61855&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61855&r=mysqlcfg
Bug #61259 [Asn->Csd]: "Segment Fault" executing a prepared statement with PDO-Mysql
Edit report at https://bugs.php.net/bug.php?id=61259&edit=1
ID: 61259
User updated by:uabitesoj at gmail dot com
Reported by:uabitesoj at gmail dot com
Summary:"Segment Fault" executing a prepared statement with
PDO-Mysql
-Status: Assigned
+Status: Closed
Type: Bug
Package:PDO related
Operating System: Linux 2.6.18 Centos 5.7
PHP Version:5.3.10
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
Nobody answer! php-5.4.0 has the same problem.
Previous Comments:
[2012-03-27 00:41:30] uabitesoj at gmail dot com
The schema of the table "user" is
CREATE TABLE IF NOT EXISTS `user` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`nombre` varchar(254) NOT NULL,
`login` varchar(254) NOT NULL,
`passwd` varchar(254) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1;
But the problem is in "mysqlnd_cset_escape_slashes" function.
I don't have much experience with C language but it is extrange that "cset" has
a 0 value and afterwards is used as an struct pointer: "cset->char_maxlen" and
"cset->mb_valid(escapestr, end)".
[2012-03-20 11:56:39] m...@php.net
Can you please provide us with the exact schema definition of the MySQL table
"user" that you referring to?
[2012-03-07 00:38:51] uabitesoj at gmail dot com
Thank you for your reply.
I recompiled my php with the suggested options for --with_mysqli and
--with_pdo_mysql, and also I tried using the last snapshot. In all cases again
I get a "Segment Fault" error.
The backtrace points to some problem in "mysqlnd_cset_escape_slashes" function.
[2012-03-05 00:29:24] johan...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Your configure line is confusing.
--with-mysqli=mysqlnd \
--with-pdo-mysql \
--with-mysql-sock=/var/lib/mysql/mysqld.sock \
myslqi is using myslqnd whereas pdo_mysql is using libmysql from it's default
location. Is that really your configuration? It is suggested to use mysqlnd for
both.
--with-mysqli=mysqlnd \
--with-pdo-mysql=myslqnd
your backtrace indicates a conflict there (as it is referring to mysqlnd which
shouldn't be used by PDO with the given configuration)
I couldn't reproduce with a pure myslqnd build. Please verify your
configuration.
[2012-03-03 03:58:24] uabitesoj at gmail dot com
Description:
Now I'm using php-5.3.10.
Executing a prepared sql statemente with pdo-mysql produces a "Segmento Fault"
error.
The configure line used to compile php is:
./configure \
--prefix=/usr/lib/php-5.3.10 \
--exec-prefix=/usr/lib/php-5.3.10 \
--with-apxs2=/usr/local/apache2/bin/apxs \
--with-config-file-path=/etc \
--enable-zip \
--enable-debug \
--with-curl=/usr/local \
--with-readline \
--enable-mbstring \
--with-mysqli=mysqlnd \
--with-pdo-mysql \
--with-mysql-sock=/var/lib/mysql/mysqld.sock \
--with-openssl \
--with-zlib \
--with-gd
Test script:
---
prepare($sql);
$stm->bindValue(1, 0);
$stm->bindValue(2, 'Name, Last Name, etc. etc.');
$stm->bindValue(3, 'log_name');
$stm->bindValue(4, SHA1('log_name', FALSE));
$stm->execute();
echo 'New user record saved in DB';
?>
Expected result:
Echoed 'New user record saved in DB' and a new record in "user" table.
Actual result:
--
GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-37.el5_7.1)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu".
For bug reporting instructions, please see:
Bug #60696 [Com]: Large Integers problem
Edit report at https://bugs.php.net/bug.php?id=60696&edit=1 ID: 60696 Comment by: danhen at web dot de Reported by:danhen at web dot de Summary:Large Integers problem Status: Open Type: Bug Package:Scripting Engine problem Operating System: Windows PHP Version:5.4.0RC5 Block user comment: N Private report: N New Comment: Have tried other PDO-Drivers. It only happens on pdo_sqlsrv. So what was changed in 5.4 integer Handling? The broken Code in 5.4 works fine in 5.3 and earlier Versions. Previous Comments: [2012-04-03 01:39:51] yohg...@php.net Could you or anyone try see if this happens with other PDO drivers? $iTest is overflowed (i.e. larger than 31^2), but this should not matter. [2012-01-10 05:20:22] danhen at web dot de Description: If large integer values ââare defined in the source code, connecting to MSSQL-Server fails. Setup: Windows Vista PHP5.4 RC5 php_pdo_sqlsrv as additional extension The code which defines the value doesn't need to be executed. It's enough defining such values before connecting to mssql (inside a previous loadad class in my case). When 90 is changed to 9 everything is fine. Test script: --- https://bugs.php.net/bug.php?id=60696&edit=1
Req #26411 [Com]: while {} else {}
Edit report at https://bugs.php.net/bug.php?id=26411&edit=1
ID: 26411
Comment by: ma-martin at hotmail dot de
Reported by:php at bellytime dot com
Summary:while {} else {}
Status: Open
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: *
PHP Version:*
Block user comment: N
Private report: N
New Comment:
Hey, i was also looking for some while {} else {} feature...
but i think it could be difficult to implement such a function in php.
Because the else{} event would start after the while{}-loop ends -> everytime
after the last result!
think about it!
Previous Comments:
[2012-01-25 12:16:57] hawkyhawk14 at gmail dot com
This is a great idea. I am currently needing something like this, but however
got
around it using flags and making the flag true in the while. It would be alot
more
convenient if there was an else!
Please add this feature!!!
[2011-12-06 16:31:22] absimu at hotmail dot com
I agree. I think a while () else () will make things easier. I was researching
and
found out that it doesnt exist yet.
while($row = mysqli_fetch_assoc($result)) { }
with al else I would fix it.. I am new in PHP,. I will try to find something to
fix it. but if the while else is release in a new version that would be nice.
[2011-02-18 01:14:34] ijrbiz at gmail dot com
Highly agreed, this request would be very practical for improved coding
structure and
follows logical language syntax nicely.
function remove_items (&$arr, $needle) {
while ($key = array_search($needle, $arr)) {
unset( $arr[$key] );
} else return false; // No items present
return true; // Item(s) removed
}
[2010-12-19 13:08:30] trefighter2334 at aol dot com
I'd love to see something like Python's while/else logic implemented in PHP.
This logical construct would allow developers to define blocks of code in else
{} that'd run upon a natural exit from the while(){} loop caused by said loop's
condition becoming FALSE; however, the else {} would be skipped over if the
loop
exits unnaturally -- a la through a break statement or because of an exception.
It is to die for on a semi-daily basis for me (in python)... but I'm not sure
this is what the developers above (and their examples) have in mind or not.
Either implementation would prove useful to me.
[2008-04-09 07:51:11] ois at oisnot dot com
try {
foreach ($nullValue as $nothing) {
echo 'valid input';
} else {
//suppress notice
echo 'null value';
}
//or/and
} catch (ExceptionObjectNotIterator $e) {
//object doesnt implement Iterator
echo $e->getMessage();
}
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=26411
--
Edit this bug report at https://bugs.php.net/bug.php?id=26411&edit=1
Bug #61345 [Com]: CGI mode - make install don't work
Edit report at https://bugs.php.net/bug.php?id=61345&edit=1 ID: 61345 Comment by: kuteninja at gmail dot com Reported by:sites at evoluons dot net Summary:CGI mode - make install don't work Status: Assigned Type: Bug Package:Compile Failure Operating System: Fedora 16 x86_64 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: I have this same issue, creating php/bin directory make install works, without it it doesn't work. I'm running CentOS 6 x86_64 (so it should be equal in RHEL6 too) This is my configure: ./configure --prefix=/usr/local/php --with-layout=GNU --with-config-file- path=/usr/local/php --disable-all --enable-libxml --with-libxml-dir=/usr/local - -with-regex=php --enable-cgi --disable-cli --enable-inline-optimization --with- pcre-regex --enable-json Only by making the /usr/local/php/bin directory manually I'm able to "make install" it. Previous Comments: [2012-03-23 06:32:08] sites at evoluons dot net I apologize : it's with another computer it was OK. I updated mine too, and it keep same error. I tried today with a new ./configure command : ./configure --with-apxs2=/usr/local/apache/bin/apxs --with-config-file-path=/usr/local/apache/conf --with-gd --with-zlib --with-bz2 --enable-ftp --enable-sockets --with-curl --with-mysql=/usr/local/mysql --with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd --with-imap --enable-mbstring --enable-exif --without-pear --enable-zip --prefix=/usr/local/php --with-mcrypt --with-jpeg-dir --with-png-dir --with-freetype-dir --enable-gd-native-ttf --with-kerberos --with-imap-ssl Same problem : make install Installing PHP CGI binary:/usr/local/phpcgi/bin/ cp: cannot create regular file `/usr/local/phpcgi/bin/#INST@1706#': No such file or directory And if I create folders myself : mkdir /usr/local/phpcgi mkdir /usr/local/phpcgi/bin It's ok : make install Installing PHP CGI binary:/usr/local/phpcgi/bin/ Installing build environment: /usr/local/phpcgi/lib/php/build/ Installing header files: /usr/local/phpcgi/include/php/ Installing helper programs: /usr/local/phpcgi/bin/ program: phpize program: php-config Installing man pages: /usr/local/phpcgi/php/man/man1/ page: phpize.1 page: php-config.1 Installing PDO headers: /usr/local/phpcgi/include/php/ext/pdo/ [2012-03-22 08:30:35] sites at evoluons dot net I updated my Fedora 16 x86_64 and now it works directly, without any workaround. So, I close the bug. [2012-03-10 20:40:18] sites at evoluons dot net Description: Hi, With a Fedora 16 x86_64 I compiled PHP in Apache module mode, no problem. But, to use also CGI mode, compilation is OK, but "make install" not. My ./configure : ./configure --with-gd --with-zlib --enable-ftp --enable-sockets --with-curl --enable-mbstring --enable-exif --enable-zip --prefix=/usr/local/phpcgi --disable-cli --with-mysql=/usr/local/mysql --with-jpeg-dir --with-png-dir --with-freetype-dir --enable-gd-native-ttf --with-mcrypt make install Installing PHP CGI binary:/usr/local/phpcgi/bin/ cp: cannot create regular file `/usr/local/phpcgi/bin/#INST@1199#': No such file or directory Expected result: Installing PHP CGI binary:/usr/local/phpcgi/bin/ Installing build environment: /usr/local/phpcgi/lib/php/build/ Installing header files: /usr/local/phpcgi/include/php/ Installing helper programs: /usr/local/phpcgi/bin/ program: phpize program: php-config Installing man pages: /usr/local/phpcgi/php/man/man1/ page: phpize.1 page: php-config.1 Installing PDO headers: /usr/local/phpcgi/include/php/ext/pdo/ Actual result: -- If I manually create /usr/local/phpcgi and /usr/local/phpcgi/bin folders, "make install" work : mkdir /usr/local/phpcgi mkdir /usr/local/phpcgi/bin Thank you for your help ;) -- Edit this bug report at https://bugs.php.net/bug.php?id=61345&edit=1
[PHP-BUG] Req #61853 [NEW]: Use of non-deprecated functions
From: Operating system: Debian testing PHP version: master-Git-2012-04-25 (Git) Package: LDAP related Bug Type: Feature/Change Request Bug description:Use of non-deprecated functions Description: This patch aims to remove usage of deprecated ldap function. I did change the php_ldap_do_search to use ldap_search_ext and ldap_search_ext_s. -- Edit bug report at https://bugs.php.net/bug.php?id=61853&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61853&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61853&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61853&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61853&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61853&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61853&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61853&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61853&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61853&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61853&r=support Expected behavior: https://bugs.php.net/fix.php?id=61853&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61853&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61853&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61853&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61853&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61853&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61853&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61853&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61853&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61853&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61853&r=mysqlcfg
Req #32100 [Com]: Request 'finally' support for exceptions
Edit report at https://bugs.php.net/bug.php?id=32100&edit=1
ID: 32100
Comment by: toplegocreator at hotmail dot com
Reported by:ceefour at gauldong dot net
Summary:Request 'finally' support for exceptions
Status: Closed
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: *
PHP Version:5.*
Block user comment: N
Private report: N
New Comment:
"Though this is still possible (however much more to type) it is wrong design.
Since obviously you are using the exceptions as control flow."
If exceptions should never be propagated up the stack to a block of code that
knows how to deal with them, why are exceptions there in the first place?
Exceptions ARE flow control. That's their reason for existing. If they
shouldn't be used that way, they shouldn't be included in the language.
Let me elaborate. An exception should occur any time when the current block
cannot successfully continue execution in the current state and has no direct
means (or shouldn't have any direct means because of good separation of
concerns) of informing the client of the problem. A finally clause, while not
strictly needed if code repetition is acceptable (and it isn't in my book), is
appropriate for ensuring that resources (like database connections, open files,
a printer, whatever) are released when fatal errors occur. Trying to deal with
the error as some kind of returned result all the way up the stack will just
make your code more difficult to read and maintain; an error should go all the
way up the stack until a piece of code that's responsible for output can
determine how to inform the client. That's how exceptions are supposed to be
used, and a finally clause makes it possible to properly and (fairly) reliably
release resources, which is also a best practice.
Previous Comments:
[2012-04-19 20:00:39] simon at stienen dot name
RAII is an elegant solution for tidying up scopes reliably.
It is also possible in PHP to do RAII without writing one class per resource
type:
callback = $callback;
}
function __destruct() {
if (is_callable($this->callback)) {
call_user_func($this->callback);
}
}
}
function do_something() {
mysql_query("LOCK TABLES mytable WRITE");
$guard = new ScopeGuard(function() {
mysql_query("UNLOCK TABLES");
});
try {
// ... do lots of queries here
}
}
?>
$guard will be destructed when leaving the do_something - either by throwing an
exception or by exiting the function normally.
HOWEVER: RAII in C++ (which neither employs nor needs a finally keyword) is
more subtle - or rather: Scopes are. In PHP you can define a variable within a
loop or a conditional block - and use it afterwards. In C++ you can't. A
variable defined inside a certain block will be destroyed once the block is
left. Consider the following example:
In C++, this would work as expected of a "finally" replacement and unlock the
tables at *1*, when the if scope closes. In PHP however, $guard will only be
destroyed when leaving the function at *2*. This can be fixed by manually
adding an unset($guard) at *1*, but this is inelegant and error prone.
So, while I have never needed finally, I think the way PHP works and is used
absolutely validates its introduction as a useful addition to the language. The
alternative would be to introduce C/++ style closed scopes, but those would
most likely not only break a lot of existing code, but the coders as well, as
they do not even remotely fit into the way PHP is written.
[2012-04-12 15:42:21] matthias at die-legendaeren dot de
"Just going to say 'Me too!'? Don't clutter the database with that please !"
But this is the right place for a "me too": to prove that a statement from 12
years ago was shortsighted and in a "works for me" way, developers (as
customers)
who disagree have to group behind their request.
[2012-04-11 21:21:33] gudjonj at gmail dot com
+1 for finally in PHP
[2012-04-11 08:34:13] ravilov at gmail dot com
My two cents...
Here's an example of emulating "finally" in PHP without needing to duplicate
code.
$_ex = null;
AllocateSomeResource();
try {
DoSomeProcessing();
} catch (Exception $ex) {
$_ex = $ex;
}
DeallocateSomeResource();
if ($_ex != null) {
throw $_ex;
}
That said, I completely agree any current workaround/emulation/"solution" is
nothing but cumbersome and bug-prone, and that we shouldn't have to come up
with such creative ways to overcome what seems like a language design flaw. PHP
is a tool, it is supposed to work *with* us, not *ag
[PHP-BUG] Bug #61852 [NEW]: crypt() function incorrectly falls back to CRYPT_STD_DES
From: Operating system: CentOS 5 PHP version: 5.3.10 Package: *Encryption and hash functions Bug Type: Bug Bug description:crypt() function incorrectly falls back to CRYPT_STD_DES Description: The crypt() method fails bcrypt test vectors given by Openwall's crypt v1.2. Specifically, when given an invalid identifier, crypt() falls back to CRYPT_STD_DES, even though the first two bytes of the salt do not match the documented "./0-9A-Za-z" range for CRYPT_STD_DES. The expected behavior would be to return *0. I've tested this under PHP 5.3.10 on Zend Server on CentOS 5 and Windows 7. Test script: --- https://bugs.php.net/bug.php?id=61852&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61852&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61852&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61852&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61852&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61852&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61852&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61852&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61852&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61852&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61852&r=support Expected behavior: https://bugs.php.net/fix.php?id=61852&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61852&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61852&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61852&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61852&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61852&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61852&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61852&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61852&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61852&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61852&r=mysqlcfg
Bug #44049 [Com]: Stored proc query fails on NULL input
Edit report at https://bugs.php.net/bug.php?id=44049&edit=1
ID: 44049
Comment by: acb0038 at auburn dot edu
Reported by:morne dot olderwagen at lexisnexis dot co dot za
Summary:Stored proc query fails on NULL input
Status: Open
Type: Bug
Package:MSSQL related
Operating System: windows 2003 server
PHP Version:5.2.5
Block user comment: N
Private report: N
New Comment:
I tried a lot of stuff with SET ANSI_NULLS and even explicitly defining every
column to allow nulls, but to no avail. Really strange that I exactly say to
allow nulls for the column, and it tells me exactly that the column does not
allow nulls. I'm using PHP 5.3.2 on Ubuntu 4.14, Apache 2.2.14, FreeTDS for
mssql
library, connecting to SQL Server 2008 R2. The procedure works perfectly
through
command-line FreeTDS on my Mac, Visual Studio, and ASP.NET on a FrontPage
server.
It's inexplicably buggy with SquirrelSQL, which uses a JDBC driver from
Microsoft.
Previous Comments:
[2008-02-05 12:57:21] morne dot olderwagen at lexisnexis dot co dot za
Description:
I have a Stored Procedure that returns 4 result sets. The proc selects data and
inserts into a temp table and then reads back, etc. The temp table is set up to
allow null values, but I get this:
PHP Warning: mssql_query() [function.mssql-query]: message: Cannot insert the
value NULL into column 'PhysAddressLine2', table
'tempdb.dbo.#TempRandom_0003'; column does not
allow nulls. INSERT fails. (severity 16) in ...
I have tested the proc in MSSQL Query Analyser and also tested the script in
ASP.NET, both worked fine.
Reproduce code:
---
$sql = "exec sp_dosearch 0,2,7,2,5";
if($qsql = mssql_query($sql, $link)) {
echo "OK";
/*do {
while($row = mssql_fetch_row($qsql)) {
}
} while (mssql_next_result($qsql)); */
} else {
echo"OWNED";
}
/* also tried */
$query = mssql_init("sp_dosearch", $link);
$SortOrder = 0;
$PASelectType = 2;
$PASelectID = 7;
$GeoSelectType = 2;
$GeoSelectID= 5;
mssql_bind($query, "@SortOrder", $SortOrder, SQLINT2);
mssql_bind($query, "@PASelectType", $PASelectType, SQLINT2);
mssql_bind($query, "@PASelectID", $PASelectID, SQLINT2);
mssql_bind($query, "@GeoSelectType", $GeoSelectType, SQLINT2);
mssql_bind($query, "@GeoSelectID", $GeoSelectID, SQLINT2);
if($res = mssql_execute($query)) {
echo "OK";
} else {
echo "OWNED";
}
Expected result:
OK
Actual result:
--
OWNED
--
Edit this bug report at https://bugs.php.net/bug.php?id=44049&edit=1
Bug #53188 [Com]: php_date.c fails to compile (code line 499)
Edit report at https://bugs.php.net/bug.php?id=53188&edit=1 ID: 53188 Comment by: pancake at nopcode dot org Reported by:jeremy dot iglehart at gmail dot com Summary:php_date.c fails to compile (code line 499) Status: Feedback Type: Bug Package:Compile Failure Operating System: Darwin (iPod OS4) PHP Version:5.3.3 Block user comment: N Private report: N New Comment: There's also a problem linking against libiconv. because the symbol name is libiconv() and not iconv(). Doing a #define on iconv.c is enought to bypass this issue. Anyway. none of the hacks I did shuold be in mainstream, they are just hacks :) I don't have time to write proper patch, but with those hints any php dev can write the proper patch and commit it. If you have any question or you need to test just ping me. Previous Comments: [2012-04-25 12:38:46] paj...@php.net hi! I would suggest to provide a patch against master, with the correct #ifdef to modify the sources only if iOS is used. [2012-04-25 12:15:08] pancake at nopcode dot org After fixing this issue, everything compiles fine, but the linking fails. To fix the libresolv issue, exit ext/standard/dns.c and write this at line 78 #define res_9_init res_init #define res_9_search res_search #define res_9_expand res_expand #define res_9_dn_skipname __dn_skipname #define res_9_dn_expand dn_expand [2012-04-25 11:20:11] pancake at nopcode dot org I have been checking this bug as I'm the maintainer of cydia.radare.org.. and someone on twitter asked me to build an updated package of php... After an hour messing around the different nested macros I end up finding the problem. As i'm quite lazy, i'm not going to send a patch, but rather explain how to fix it. The problem is in the Zend/zend_ini.h:32 , in this line there's the definition of XtOffsetOf macro.. which is wrong and this causes gcc to fail in that way. My fix was removing all definitions of XtOffsetOf and replace it with a single and portable one: #define XtOffsetOf(type, member) ((unsigned long) &((type*)0)->member) feel free to submit patch on the main repo. I'm using this XtOffsetOf macro in some projects of mine in multiple compilers/archs/OS without any issue. So maybe you can simplify the code instead of just handling that case. Anyway... the build i'm doing (php-5.4.0) will be available in binary form in the cydia.radare.org repo. [2012-01-25 15:26:16] bobwei9 at hotmail dot com Now the error is on line 500⦠with php 5.4 on ios5.0.1 Could you pelase fix this? [2010-10-29 12:17:23] ahar...@php.net Where did you source your toolchain from? PHP does run on jailbroken iOS devices (the Telesphoreo repository has 5.2.8 available), but I'd be surprised if that wasn't being cross-compiled off OS X via XCode. 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=53188 -- Edit this bug report at https://bugs.php.net/bug.php?id=53188&edit=1
Bug #53188 [Fbk]: php_date.c fails to compile (code line 499)
Edit report at https://bugs.php.net/bug.php?id=53188&edit=1 ID: 53188 Updated by: paj...@php.net Reported by:jeremy dot iglehart at gmail dot com Summary:php_date.c fails to compile (code line 499) Status: Feedback Type: Bug Package:Compile Failure Operating System: Darwin (iPod OS4) PHP Version:5.3.3 Block user comment: N Private report: N New Comment: hi! I would suggest to provide a patch against master, with the correct #ifdef to modify the sources only if iOS is used. Previous Comments: [2012-04-25 12:15:08] pancake at nopcode dot org After fixing this issue, everything compiles fine, but the linking fails. To fix the libresolv issue, exit ext/standard/dns.c and write this at line 78 #define res_9_init res_init #define res_9_search res_search #define res_9_expand res_expand #define res_9_dn_skipname __dn_skipname #define res_9_dn_expand dn_expand [2012-04-25 11:20:11] pancake at nopcode dot org I have been checking this bug as I'm the maintainer of cydia.radare.org.. and someone on twitter asked me to build an updated package of php... After an hour messing around the different nested macros I end up finding the problem. As i'm quite lazy, i'm not going to send a patch, but rather explain how to fix it. The problem is in the Zend/zend_ini.h:32 , in this line there's the definition of XtOffsetOf macro.. which is wrong and this causes gcc to fail in that way. My fix was removing all definitions of XtOffsetOf and replace it with a single and portable one: #define XtOffsetOf(type, member) ((unsigned long) &((type*)0)->member) feel free to submit patch on the main repo. I'm using this XtOffsetOf macro in some projects of mine in multiple compilers/archs/OS without any issue. So maybe you can simplify the code instead of just handling that case. Anyway... the build i'm doing (php-5.4.0) will be available in binary form in the cydia.radare.org repo. [2012-01-25 15:26:16] bobwei9 at hotmail dot com Now the error is on line 500⦠with php 5.4 on ios5.0.1 Could you pelase fix this? [2010-10-29 12:17:23] ahar...@php.net Where did you source your toolchain from? PHP does run on jailbroken iOS devices (the Telesphoreo repository has 5.2.8 available), but I'd be surprised if that wasn't being cross-compiled off OS X via XCode. [2010-10-28 03:14:58] jeremy dot iglehart at gmail dot com Description: I'm not sure why this is happening - and I can't find help from google or the IRC chatroom #php so I figured I would post it here. For some reason I can't compile - when I try to run the compile I get this: to get a full paste of it you can go here: http://pastebin.com/zTtsQiMX Any idea? Test script: --- Here is a paste URL of the entire problem. http://pastebin.com/zTtsQiMX ./configure code... ++ | License: | | This software is subject to the PHP License, available in this | | distribution in the file LICENSE. By continuing this installation | | process, you are bound by the terms of this license agreement. | | If you do not agree with the terms of this license, you must abort | | the installation process at this point.| ++ Thank you for using PHP. iPod-Touch:~/php-5.3.3 root# make /bin/sh /var/root/php-5.3.3/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/date/lib -Iext/date/ -I/var/root/php-5.3.3/ext/date/ -DPHP_ATOM_INC -I/var/root/php-5.3.3/include -I/var/root/php-5.3.3/main -I/var/root/php-5.3.3 -I/var/root/php-5.3.3/ext/date/lib -I/var/root/php-5.3.3/ext/ereg/regex -I/usr/include/libxml2 -I/usr/local/include -I/var/root/php-5.3.3/ext/sqlite3/libsqlite -I/var/root/php-5.3.3/TSRM -I/var/root/php-5.3.3/Zend -no-cpp-precomp -I/usr/include -g -O2 -c /var/root/php-5.3.3/ext/date/php_date.c -o ext/date/php_date.lo /var/root/php-5.3.3/ext/date/php_date.c:499: error: expected expression before 'zend_date_globals' /var/root/php-5.3.3/ext/date/php_date.c:499: error: initializer element is not constant /var/root/php-5.3.3/ext/date/php_date.c:499: error: (near initialization for 'ini_entries[0].mh_arg1') make: *** [ext/date/php_date.lo] Error 1 iPod-Touch:~/php-5.3.3 root# Expected result: to compile normal :) Actual result: -- fails to compile :( --
Bug #53188 [Com]: php_date.c fails to compile (code line 499)
Edit report at https://bugs.php.net/bug.php?id=53188&edit=1 ID: 53188 Comment by: pancake at nopcode dot org Reported by:jeremy dot iglehart at gmail dot com Summary:php_date.c fails to compile (code line 499) Status: Feedback Type: Bug Package:Compile Failure Operating System: Darwin (iPod OS4) PHP Version:5.3.3 Block user comment: N Private report: N New Comment: After fixing this issue, everything compiles fine, but the linking fails. To fix the libresolv issue, exit ext/standard/dns.c and write this at line 78 #define res_9_init res_init #define res_9_search res_search #define res_9_expand res_expand #define res_9_dn_skipname __dn_skipname #define res_9_dn_expand dn_expand Previous Comments: [2012-04-25 11:20:11] pancake at nopcode dot org I have been checking this bug as I'm the maintainer of cydia.radare.org.. and someone on twitter asked me to build an updated package of php... After an hour messing around the different nested macros I end up finding the problem. As i'm quite lazy, i'm not going to send a patch, but rather explain how to fix it. The problem is in the Zend/zend_ini.h:32 , in this line there's the definition of XtOffsetOf macro.. which is wrong and this causes gcc to fail in that way. My fix was removing all definitions of XtOffsetOf and replace it with a single and portable one: #define XtOffsetOf(type, member) ((unsigned long) &((type*)0)->member) feel free to submit patch on the main repo. I'm using this XtOffsetOf macro in some projects of mine in multiple compilers/archs/OS without any issue. So maybe you can simplify the code instead of just handling that case. Anyway... the build i'm doing (php-5.4.0) will be available in binary form in the cydia.radare.org repo. [2012-01-25 15:26:16] bobwei9 at hotmail dot com Now the error is on line 500⦠with php 5.4 on ios5.0.1 Could you pelase fix this? [2010-10-29 12:17:23] ahar...@php.net Where did you source your toolchain from? PHP does run on jailbroken iOS devices (the Telesphoreo repository has 5.2.8 available), but I'd be surprised if that wasn't being cross-compiled off OS X via XCode. [2010-10-28 03:14:58] jeremy dot iglehart at gmail dot com Description: I'm not sure why this is happening - and I can't find help from google or the IRC chatroom #php so I figured I would post it here. For some reason I can't compile - when I try to run the compile I get this: to get a full paste of it you can go here: http://pastebin.com/zTtsQiMX Any idea? Test script: --- Here is a paste URL of the entire problem. http://pastebin.com/zTtsQiMX ./configure code... ++ | License: | | This software is subject to the PHP License, available in this | | distribution in the file LICENSE. By continuing this installation | | process, you are bound by the terms of this license agreement. | | If you do not agree with the terms of this license, you must abort | | the installation process at this point.| ++ Thank you for using PHP. iPod-Touch:~/php-5.3.3 root# make /bin/sh /var/root/php-5.3.3/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/date/lib -Iext/date/ -I/var/root/php-5.3.3/ext/date/ -DPHP_ATOM_INC -I/var/root/php-5.3.3/include -I/var/root/php-5.3.3/main -I/var/root/php-5.3.3 -I/var/root/php-5.3.3/ext/date/lib -I/var/root/php-5.3.3/ext/ereg/regex -I/usr/include/libxml2 -I/usr/local/include -I/var/root/php-5.3.3/ext/sqlite3/libsqlite -I/var/root/php-5.3.3/TSRM -I/var/root/php-5.3.3/Zend -no-cpp-precomp -I/usr/include -g -O2 -c /var/root/php-5.3.3/ext/date/php_date.c -o ext/date/php_date.lo /var/root/php-5.3.3/ext/date/php_date.c:499: error: expected expression before 'zend_date_globals' /var/root/php-5.3.3/ext/date/php_date.c:499: error: initializer element is not constant /var/root/php-5.3.3/ext/date/php_date.c:499: error: (near initialization for 'ini_entries[0].mh_arg1') make: *** [ext/date/php_date.lo] Error 1 iPod-Touch:~/php-5.3.3 root# Expected result: to compile normal :) Actual result: -- fails to compile :( -- Edit this bug report at https://bugs.php.net/bug.php?id=53188&edit=1
Bug #53188 [Com]: php_date.c fails to compile (code line 499)
Edit report at https://bugs.php.net/bug.php?id=53188&edit=1 ID: 53188 Comment by: pancake at nopcode dot org Reported by:jeremy dot iglehart at gmail dot com Summary:php_date.c fails to compile (code line 499) Status: Feedback Type: Bug Package:Compile Failure Operating System: Darwin (iPod OS4) PHP Version:5.3.3 Block user comment: N Private report: N New Comment: I have been checking this bug as I'm the maintainer of cydia.radare.org.. and someone on twitter asked me to build an updated package of php... After an hour messing around the different nested macros I end up finding the problem. As i'm quite lazy, i'm not going to send a patch, but rather explain how to fix it. The problem is in the Zend/zend_ini.h:32 , in this line there's the definition of XtOffsetOf macro.. which is wrong and this causes gcc to fail in that way. My fix was removing all definitions of XtOffsetOf and replace it with a single and portable one: #define XtOffsetOf(type, member) ((unsigned long) &((type*)0)->member) feel free to submit patch on the main repo. I'm using this XtOffsetOf macro in some projects of mine in multiple compilers/archs/OS without any issue. So maybe you can simplify the code instead of just handling that case. Anyway... the build i'm doing (php-5.4.0) will be available in binary form in the cydia.radare.org repo. Previous Comments: [2012-01-25 15:26:16] bobwei9 at hotmail dot com Now the error is on line 500⦠with php 5.4 on ios5.0.1 Could you pelase fix this? [2010-10-29 12:17:23] ahar...@php.net Where did you source your toolchain from? PHP does run on jailbroken iOS devices (the Telesphoreo repository has 5.2.8 available), but I'd be surprised if that wasn't being cross-compiled off OS X via XCode. [2010-10-28 03:14:58] jeremy dot iglehart at gmail dot com Description: I'm not sure why this is happening - and I can't find help from google or the IRC chatroom #php so I figured I would post it here. For some reason I can't compile - when I try to run the compile I get this: to get a full paste of it you can go here: http://pastebin.com/zTtsQiMX Any idea? Test script: --- Here is a paste URL of the entire problem. http://pastebin.com/zTtsQiMX ./configure code... ++ | License: | | This software is subject to the PHP License, available in this | | distribution in the file LICENSE. By continuing this installation | | process, you are bound by the terms of this license agreement. | | If you do not agree with the terms of this license, you must abort | | the installation process at this point.| ++ Thank you for using PHP. iPod-Touch:~/php-5.3.3 root# make /bin/sh /var/root/php-5.3.3/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/date/lib -Iext/date/ -I/var/root/php-5.3.3/ext/date/ -DPHP_ATOM_INC -I/var/root/php-5.3.3/include -I/var/root/php-5.3.3/main -I/var/root/php-5.3.3 -I/var/root/php-5.3.3/ext/date/lib -I/var/root/php-5.3.3/ext/ereg/regex -I/usr/include/libxml2 -I/usr/local/include -I/var/root/php-5.3.3/ext/sqlite3/libsqlite -I/var/root/php-5.3.3/TSRM -I/var/root/php-5.3.3/Zend -no-cpp-precomp -I/usr/include -g -O2 -c /var/root/php-5.3.3/ext/date/php_date.c -o ext/date/php_date.lo /var/root/php-5.3.3/ext/date/php_date.c:499: error: expected expression before 'zend_date_globals' /var/root/php-5.3.3/ext/date/php_date.c:499: error: initializer element is not constant /var/root/php-5.3.3/ext/date/php_date.c:499: error: (near initialization for 'ini_entries[0].mh_arg1') make: *** [ext/date/php_date.lo] Error 1 iPod-Touch:~/php-5.3.3 root# Expected result: to compile normal :) Actual result: -- fails to compile :( -- Edit this bug report at https://bugs.php.net/bug.php?id=53188&edit=1
[PHP-BUG] Req #61849 [NEW]: PDO Firebird does not support getColumnMeta function
From: Operating system: any PHP version: 5.3.10 Package: PDO related Bug Type: Feature/Change Request Bug description:PDO Firebird does not support getColumnMeta function Description: PDO Firebird does not support $statement->getColumnMeta() function. Can we get this support? -- Edit bug report at https://bugs.php.net/bug.php?id=61849&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61849&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61849&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61849&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61849&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61849&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61849&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61849&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61849&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61849&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61849&r=support Expected behavior: https://bugs.php.net/fix.php?id=61849&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61849&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61849&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61849&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61849&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61849&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61849&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61849&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61849&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61849&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61849&r=mysqlcfg
[PHP-BUG] Bug #61848 [NEW]: last
From: Operating system: centos 6.0 PHP version: 5.3.10 Package: MySQL related Bug Type: Bug Bug description:last Description: pdo:getColumnMeta /* add stock items */ col = &stmt->columns[colno]; add_assoc_string(return_value, "name", col->name, 1); add_assoc_long(return_value, "len", col->maxlen); /* FIXME: unsigned ? */ add_assoc_long(return_value, "precision", col->precision); add_assoc_long(return_value, "pdo_type", col->param_type); } there is no table and other item Test script: --- with cakephp,it can't working Expected result: with cakephp,it can't working Actual result: -- with cakephp,it can't working -- Edit bug report at https://bugs.php.net/bug.php?id=61848&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61848&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61848&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61848&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61848&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61848&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61848&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61848&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61848&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61848&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61848&r=support Expected behavior: https://bugs.php.net/fix.php?id=61848&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61848&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61848&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61848&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61848&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61848&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61848&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61848&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61848&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61848&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61848&r=mysqlcfg
