Bug #65016 [Asn]: configure can not find libxpm
Edit report at https://bugs.php.net/bug.php?id=65016&edit=1 ID: 65016 Updated by: google...@php.net Reported by:gunter at grodotzki dot co dot za Summary:configure can not find libxpm Status: Assigned Type: Bug Package:Compile Failure Operating System: Debian Wheezy PHP Version:5.4.16 Assigned To:ondrej Block user comment: N Private report: N New Comment: In my experience --with-libdir=/usr/lib/x86_64-linux-gnu has never solved this problem for me on Debian based systems like Ubuntu. I usually just end up creating a symlink to /usr/lib/libXpm.so from /usr/lib/x86_64-linux-gnu/libXpm.so where PHP was expecting to find it and normally it works out. Previous Comments: [2013-06-13 04:13:17] ras...@php.net Doesn't --with-libdir=/usr/lib/x86_64-linux-gnu fix this? [2013-06-12 06:43:35] ond...@php.net That's quite easy to answer. Debian wheezy switched to Multi-Arch which puts the libraries into /usr/lib// location. E.g. libXpm.so now resides in: $ ldconfig -p | grep Xpm libXpm.so.4 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libXpm.so.4 libXpm.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libXpm.so and ld.so is able to find it: $ cat /etc/ld.so.conf.d/x86_64-linux-gnu.conf # Multiarch support /lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu That's why we carry patches such as: http://anonscm.debian.org/gitweb/?p=pkg- php/php.git;a=blob;f=debian/patches/temporary-path-fixes-for- multiarch.patch;h=dcca64de3cb6cb3398fa70b5ed878685f66a7acf;hb=refs/heads/master- wheezy in our Debian package. The problem with PHP autoconf script is that it expects to find the library at specific place (f.e. /usr/lib) and it should just try linking the library instead (e.g. AC_SEARCH_LIBS). The "test -f" sort of mimick the ldconfig to "know" where the library should be. Unfortunatelly it cannot be solved by simple --with-library=/usr/lib/, because that would usually break the header files location. I think that correct way to fix this in vanilla PHP would be to switch to AC_SEARCH_LIBS when looking for the library. I might prepare the patch, but I am quite afraid that it's post-5.5 material, because that might break on oh-so-many places. O. [2013-06-12 05:58:55] paj...@php.net I don't have a weezy to test, Ondrej, can you take a look pls? [2013-06-12 05:57:11] gunter at grodotzki dot co dot za Description: What used to work perfectly in Debian Squeeze does not work anymore in Debian Wheezy. # dpkg -L libxpm-dev /. /usr /usr/share /usr/share/doc /usr/share/doc/libxpm-dev /usr/share/doc/libxpm-dev/copyright /usr/share/doc/libxpm-dev/xpm.PS.gz /usr/share/doc/libxpm-dev/changelog.Debian.gz /usr/share/doc/libxpm-dev/changelog.gz /usr/include /usr/include/X11 /usr/include/X11/xpm.h /usr/lib /usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/pkgconfig /usr/lib/x86_64-linux-gnu/pkgconfig/xpm.pc /usr/lib/x86_64-linux-gnu/libXpm.a /usr/lib/x86_64-linux-gnu/libXpm.so # ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --disable-cgi --with-config-file-path=/etc/php5/cli --with-libxml-dir --with-openssl --with- kerberos --with-pcre-regex --with-zlib --with-bz2 --enable-calendar --with-curl --enable-exif --enable-ftp --with-gd --with-vpx-dir --with-jpeg-dir --with-png- dir --with-xpm-dir --with-freetype-dir --enable-gd-native-ttf --enable-gd-jis- conv --with-gettext --with-imap --with-kerberos --with-imap-ssl --enable-intl -- enable-bcmath --with-icu-dir=/usr --enable-mbstring --with-mcrypt --with-mysql - -with-mysqli --with-pdo-mysql --enable-shmop --enable-soap --enable-sockets -- with-xmlrpc --with-xsl --enable-zip --with-iconv-dir --with-pear --with-tidy -- enable-pcntl Last lines of configure: checking for GD support... yes checking for the location of libvpx... yes checking for the location of libjpeg... yes checking for the location of libpng... yes checking for the location of libXpm... yes checking for FreeType 2... yes checking for T1lib support... no checking whether to enable truetype string function in GD... yes checking whether to enable JIS-mapped Japanese font support in GD... yes checking for fabsf... yes checking for floorf... yes checking for jpeg_read_header in -ljpeg... yes checking for vpx_codec_destroy in -lvpx... yes checking for png_write_image in -lpng... yes configure: error: libXpm.(a|so) not found. -- Edit this bug report at https://bugs.php.net/bug.php?id=65016&edit=1
Bug #64891 [Nab]: POST values in Google Chrome XHR.
Edit report at https://bugs.php.net/bug.php?id=64891&edit=1
ID: 64891
Updated by: google...@php.net
Reported by:marc at kryn dot org
Summary:POST values in Google Chrome XHR.
Status: Not a bug
Type: Bug
Package:Built-in web server
Operating System: OS X 10.8.2
PHP Version:5.4.15
Block user comment: N
Private report: N
New Comment:
Well, first of all you're linking to the wrong part of the RFC when you're
referring
to the character encoding of the HTTP request header. There is undefined
behavior
according to the spec and you can see that here
http://tools.ietf.org/html/rfc2616#section-3.4.1
where it clearly says:
Some HTTP/1.0 software has interpreted a Content-Type header without
charset parameter incorrectly to mean "recipient should guess."
Senders wishing to defeat this behavior MAY include a charset
parameter even when the charset is ISO-8859-1 and SHOULD do so when
it is known that it will not confuse the recipient.
Unfortunately, some older HTTP/1.0 clients did not deal properly with
an explicit charset parameter. HTTP/1.1 recipients MUST respect the
charset label provided by the sender; and those user agents that have
a provision to "guess" a charset MUST use the charset from the
Content coding values indicate an encoding transformation that has
been or can be applied to an entity. Content codings are primarily
used to allow a document to be compressed or otherwise usefully
transformed without losing the identity of its underlying media type
and without loss of information. Frequently, the entity is stored in
coded form, transmitted directly, and only decoded by the recipient.
So with that said if I go ahead and add the charset to the request header in
your
script I get the expected result.
';
var_dump($_POST);
exit;
}
?>
var xhr = new XMLHttpRequest();
xhr.open('POST', '?test=1', true);
xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded;
charset=UTF-
8");
xhr.onload = function(){ document.getElementById('response').innerHTML =
this.responseText; };
xhr.send("foo=bar");
You can see that by reviewing the Request Headers from both FireFox and Chrome
with
your developer tools that FireFox appends the charset=UTF-8 to the Content-type
header for you, whereas Chrome does not (you can see that from your supplied
request
header).
Previous Comments:
[2013-05-21 22:35:13] marc at kryn dot org
Sorry, but you shouldn't modify the test script and then say 'it works with
this
modification'. I don't know what's the different in the header are to your
example, but it's however not important, because mine produces a correct HTTP
Request header.
Google Chrome sends with my script following header:
POST /test3.php?test=1 HTTP/1.1
Host: 127.0.0.1:8000
Connection: keep-alive
Content-Length: 7
Cache-Control: max-age=0
Origin: http://127.0.0.1:8000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.36
(KHTML, like Gecko)
Chrome/27.0.1453.93 Safari/537.36
Content-type: application/x-www-form-urlencoded
Accept: */*
Referer: http://127.0.0.1:8000/test3.php
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
So it's a valid request header and should thus be handled correctly in PHP.
You've mentioned a missing Content-Length: it's not missing.
You've mentioned a missing charset in the Content-Type: This is not
mandatory as you can read in http://tools.ietf.org/html/rfc2616#section-3.7.
Please re-open this ticket, since it's still a bug on php's side and not a
support question.
[2013-05-21 22:15:42] google...@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.
This doesn't appear to be a bug in PHP. It looks to me like FireFox and some
other UAs will modify the request headers resulting from that javascript code
to
comply with the spec.
Chrome seems to be sending a request, as a result of that javascript XHR, that
is missing both the charset in the Content-type header as well as a Content-
length header. If I just let the UA do the encoding and formulate the request
properly through javascript I get the expected result:
';
var_dump(file_get_contents("php://input"),$_POST,$_GET);
exit;
}
?>
var xhr = new XMLHttpRequest();
xhr.open('POST', '
Bug #63740 [Opn]: strtotime seems to use both sunday and monday as start of week
Edit report at https://bugs.php.net/bug.php?id=63740&edit=1
ID: 63740
Updated by: google...@php.net
Reported by:salmanarshad2000 at yahoo dot com
Summary:strtotime seems to use both sunday and monday as
start of week
Status: Open
Type: Bug
Package:Date/time related
PHP Version:5.4.9
Block user comment: N
Private report: N
New Comment:
I've actually recently updated the documentation about strtotime in regard to
this very
behavior. See Bug #52143.
The problem is that prior to PHP 5.3.0 the relative time formats "this week",
"next week",
"previous week" were taken to mean a 7 day period relative to the current time.
However,
the behavior was changed in PHP 5.3.0 to be interpreted as "a week period of
Monday
through Sunday". This is noted in the documentation for strtotime in the
changelog section
since last week.
http://php.net/manual/en/function.strtotime.php#refsect1-function.strtotime-changelog
We can see this behavior more clearly from the following code...
var_dump(date("D Y-m-d", strtotime("this week", strtotime("2012-12-08";
string(14) "Mon 2012-12-03"
var_dump(date("D Y-m-d", strtotime("this week", strtotime("2012-12-09";
string(14) "Mon 2012-12-10"
Here what you'll notice is that "this week" always starts on a Monday. Now,
when you want
make that format relative to a particular day of the week, let's say Sunday...
var_dump(date("D Y-m-d", strtotime("Sunday this week",
strtotime("2012-12-08";
string(14) "Sun 2012-12-09"
var_dump(date("D Y-m-d", strtotime("Sunday this week",
strtotime("2012-12-09";
string(14) "Sun 2012-12-16"
What you should notice is that "this week" is first normalized to "Mon
2012-12-03" and
"Mon 2012-12-10", respectively. Then the day is moved up to the first "Sunday"
of that
week (i.e. +6 days on each week).
This might sounds a little confusing because if you are expecting the week to
begin on a
Sunday and end on a Saturday then you would assume that "Sunday this week"
would mean
"2012-12-09" where the date is "2012-12-09" and the day is a Sunday. But that's
not the
case. "this week" means Monday of the current week and then move up until the
very next
Sunday. So if today is Sunday, we don't get today's date when we try "Sunday
this week".
Previous Comments:
[2012-12-11 15:18:40] salmanarshad2000 at yahoo dot com
Description:
Weeks start on Sunday or Monday. However, in this regard:
1) strtotime behavior is not documented.
2) strtotime produces inconsistent results when "this week" is used.
Sample dates from month of December 2012 used the the test script:
Mon 2012-12-03
Tue 2012-12-04
Wed 2012-12-05
Thu 2012-12-06
Fri 2012-12-07
Sat 2012-12-08
Sun 2012-12-09
Mon 2012-12-10
Tue 2012-12-11
Wed 2012-12-12
Thu 2012-12-13
Fri 2012-12-14
Sat 2012-12-15
Sun 2012-12-16
Test script:
---
// function strtotime called on Sun 2012-12-09
echo date("D Y-m-d", strtotime("monday this week", strtotime("2012-12-09")));
// Mon 2012-12-10
echo date("D Y-m-d", strtotime("sunday this week", strtotime("2012-12-09")));
// Sun 2012-12-16
// function strtotime called on Mon 2012-12-10
echo date("D Y-m-d", strtotime("monday this week", strtotime("2012-12-10")));
// Mon 2012-12-10
echo date("D Y-m-d", strtotime("sunday this week", strtotime("2012-12-10")));
// Sun 2012-12-16
Expected result:
If Sunday is start of the week then "sunday this week" be less than "monday
this week":
// function strtotime called on Sun 2012-12-09
echo date("D Y-m-d", strtotime("monday this week", strtotime("2012-12-09")));
// Mon 2012-12-10
echo date("D Y-m-d", strtotime("sunday this week", strtotime("2012-12-09")));
// Sun 2012-12-09
// function strtotime called on Mon 2012-12-10
echo date("D Y-m-d", strtotime("monday this week", strtotime("2012-12-10")));
// Mon 2012-12-10
echo date("D Y-m-d", strtotime("sunday this week", strtotime("2012-12-10")));
// Sun 2012-12-09
If Monday is start of the week then "monday this week" should return different
values on sunday and monday:
// function strtotime called on Sun 2012-12-09
echo date("D Y-m-d", strtotime("monday this week", strtotime("2012-12-09")));
// Mon 2012-12-03
echo date("D Y-m-d", strtotime("sunday this week", strtotime("2012-12-09")));
// Sun 2012-12-09
// function strtotime called on Mon 2012-12-10
echo date("D Y-m-d", strtotime("monday this week", strtotime("2012-12-10")));
// Mon 2012-12-10
echo date("D Y-m-d", strtotime("sunday this week", strtotime("2012-12-10")));
// Sun 2012-12-16
Actual result:
--
See test script, actual result is present alongside each line.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63740&edit=1
Bug #64005 [Opn->Nab]: array_merge memorry issues.
Edit report at https://bugs.php.net/bug.php?id=64005&edit=1
ID: 64005
Updated by: google...@php.net
Reported by:youri dot essa at gmail dot com
Summary:array_merge memorry issues.
-Status: Open
+Status: Not a bug
Type: Bug
Package:Arrays related
Operating System: Linux
PHP Version:5.4.10
Block user comment: N
Private report: N
New Comment:
This is not a bug, but a simple mistake of using references in foreach. Pelase
see http://php.net/references and http://php.net/foreach for more details.
Particularly the red warning box at the bottom of the page at php.net/foreach
where it states "Reference of a $value and the last array element remain even
after the foreach loop. It is recommended to destroy it by unset()."
Previous Comments:
[2013-01-16 10:10:56] youri dot essa at gmail dot com
Description:
---
>From manual page:
>http://www.php.net/function.array-merge#refsect1-function.array-
merge-description
---
Test script:
---
foreach($cols as $key => &$value) {
if(array_key_exists($key, $fields)) {
$value = array_merge($fields[$key], $value);
}
}
foreach($fields as $key => $value) {
if(!array_key_exists($key, $cols)) {
$cols[$key] = $value;
}
}
Expected result:
Expected result is that col becomes is an array with all the values that where
already defined added with the values from fields.
Actual result:
--
The sub-array in cols wich was merged with the same sub-array in fields becomes
overwritten everytime the next foreach statement accesses the value $value,
witch
result. the fix for this is to have a diffrent name for the array merging, this
leads me to belive that array_merge keeps re-evaluating the values.
--
Edit this bug report at https://bugs.php.net/bug.php?id=64005&edit=1
Bug #63073 [Asn]: master "make install" fails to install PEAR
Edit report at https://bugs.php.net/bug.php?id=63073&edit=1 ID: 63073 Updated by: google...@php.net Reported by:php at bof dot de Summary:master "make install" fails to install PEAR Status: Assigned Type: Bug Package:Compile Failure Operating System: openSUSE 11.4 64bit PHP Version:5.5 Assigned To: googleguy Block user comment: N Private report: N New Comment: It was discussed on IRC that this change was applied in order to bring PHP's implementation of pack() to be more inline with Perl's implementation (see https://bugs.php.net/61038 for details) and thus why the change was introduced in PHP 5.5 instead of 5.4, which was already final at the time. The BC was taken into consideration, but the manual never specified that this was the defined behavior. So we had made the decision at the time that this BC would be worth taking in 5.5 for bringing the implementations inline. The BC concerns seem to be fiarly limited in in immediate scope to Archive_Tar, which seems to be a trivial patch (see http://pear.php.net/bugs/bug.php? id=19746&edit=12&patch=archive_tar_php55.patch&revision=1355241213 also) and Igor Wiedler seems willing to apply it. Obviously there can more BC out there with people that rely on this behavior in their existing code, but I can not gauge this if I just base it on the number of open bugs in the bug tracker that have to do with pack and PHP 5.5. So in light of these events the plan is to ask that Archive_Tar be patched to resolve the make install issue and remain consistent with the Perl implementation, which also seems consistent with Ruby's implementation of pack. The spec itself seems a bit ambiguous as noted earlier in this thread, but I think PHP will benefit more from being consistent with the other implementations. Please let me know if there are other BC concerns that have not yet come up. Previous Comments: [2013-01-14 04:21:22] s...@php.net This is still an issue in PHP 5.5. and master: 1. Download a snap 2. $ ./configure 3. $ make 4. $ make install [2012-12-20 14:38:20] korvin1986 at gmail dot com I've tried PHP-5.5.0alpha2 and go-pear.phar script (http://pear.php.net/go-pear.phar) : Log: /usr/bin/php go-pear.phar Below is a suggested file layout for your new PEAR installation. To change individual locations, type the number in front of the directory. Type 'all' to change all of them or simply press Enter to accept these locations. 1. Installation base ($prefix) : /usr 2. Temporary directory for processing: /tmp/pear/install 3. Temporary directory for downloads : /tmp/pear/install 4. Binaries directory: /usr/bin 5. PHP code directory ($php_dir) : /usr/share/pear 6. Documentation directory : /usr/docs 7. Data directory: /usr/data 8. User-modifiable configuration files directory : /usr/cfg 9. Public Web Files directory: /usr/www 10. Tests directory : /usr/tests 11. Name of configuration file: /etc/pear.conf 1-11, 'all' or Enter to continue: Beginning install... Configuration written to /etc/pear.conf... Initialized registry... Preparing to install... installing phar://go-pear.phar/PEAR/go-pear-tarballs/Archive_Tar-1.3.7.tar... installing phar://go-pear.phar/PEAR/go-pear-tarballs/Console_Getopt-1.3.0.tar... installing phar://go-pear.phar/PEAR/go-pear-tarballs/PEAR-1.9.4.tar... installing phar://go-pear.phar/PEAR/go-pear-tarballs/Structures_Graph-1.0.4.tar... installing phar://go-pear.phar/PEAR/go-pear-tarballs/XML_Util-1.2.1.tar... could not extract the package.xml file from "phar://go-pear.phar/PEAR/go-pear-tarballs/Archive_Tar-1.3.7.tar" could not extract the package.xml file from "phar://go-pear.phar/PEAR/go-pear-tarballs/Console_Getopt-1.3.0.tar" could not extract the package.xml file from "phar://go-pear.phar/PEAR/go-pear-tarballs/PEAR-1.9.4.tar" could not extract the package.xml file from "phar://go-pear.phar/PEAR/go-pear-tarballs/Structures_Graph-1.0.4.tar" could not extract the package.xml file from "phar://go-pear.phar/PEAR/go-pear-tarballs/XML_Util-1.2.1.tar" install failed [2012-12-06 08:08:54] paj...@php.net It will be much easier to debug if you could provide a small script, even using a pear package as input. [2012-12-06 04:55:49] dani...@p
Bug #63916 [Opn]: PDO::PARAM_INT casts to 32bit int internally even on 64bit builds in pdo_sqlite
Edit report at https://bugs.php.net/bug.php?id=63916&edit=1
ID: 63916
Updated by: google...@php.net
Reported by:google...@php.net
Summary:PDO::PARAM_INT casts to 32bit int internally even on
64bit builds in pdo_sqlite
Status: Open
Type: Bug
Package:PDO related
PHP Version:5.4.10
Block user comment: N
Private report: N
New Comment:
This seems to be a regression from the PHP-5.2 branch as well. After testing on
PHP-
5.2,5.3,5.4,5.5,and master branches I found that the issue did not exist back
in ext/sqlite2
as string casting was done instead of using integer types. The issue probably
was over looked
when the sqlite3 driver was ported in to replace the old ext/sqlite2.
Regression results:
http://playground.sheriframadan.com/testphphL1I9j
Previous Comments:
[2013-01-06 18:49:11] google...@php.net
Related To: Bug #63921
[2013-01-06 12:57:28] google...@php.net
Because we're currently running 3 branches I've sent the PR for this to master
and I'm asking for it to be merged into 5.3.NEXT, 5.4.NEXT, and 5.5.NEXT
respectively to maintain consistency.
https://github.com/php/php-src/pull/253/
[2013-01-06 05:20:07] google...@php.net
Description:
Binding a PDO parameter with pdo_sqlite on 64bit builds with PDO::PARAM_INT
forces the param to be cast internally to an int. This means 64bit ints will be
cast down to 32bit ints internally even if PHP was compiled against a 64bit
arch.
Test script:
---
$num = 14313234244; // notice this exceeds 32 bits
$conn = new PDO('sqlite::memory:');
$conn->query('CREATE TABLE users (id INTEGER NOT NULL, num INTEGER NOT NULL,
PRIMARY KEY(id))');
$stmt = $conn->prepare('insert into users (id, num) values (:id, :num)');
$stmt->bindValue(':id', 1, PDO::PARAM_INT);
$stmt->bindValue(':num', $num, PDO::PARAM_INT);
$stmt->execute();
$stmt = $conn->query('SELECT num FROM users');
$result = $stmt->fetchAll(PDO::FETCH_COLUMN);
printf("Expected: %d Received: %d\n", $num, $result[0]);
Expected result:
// expected to output
Expected: 14313234244 Received: 14313234244
Actual result:
--
// instead we get output of
Expected: 14313234244 Received: 294714180
--
Edit this bug report at https://bugs.php.net/bug.php?id=63916&edit=1
Bug #63921 [Opn]: sqlite3::bindvalue and relative PHP functions aren't using sqlite3_*_int64 API
Edit report at https://bugs.php.net/bug.php?id=63921&edit=1
ID: 63921
Updated by: google...@php.net
Reported by:google...@php.net
Summary:sqlite3::bindvalue and relative PHP functions aren't
using sqlite3_*_int64 API
Status: Open
Type: Bug
Package:SQLite related
PHP Version:5.4.10
Block user comment: N
Private report: N
New Comment:
I've sent a PR for this as well on master. I hope to get it merged into
5.3.NEXT,
5.4.NEXT, and 5.5.NEXT for consistency with the fix for bug #63916 as they are
both related to sqlite3 driver.
https://github.com/php/php-src/pull/254
Previous Comments:
[2013-01-06 17:24:52] google...@php.net
Description:
The sqlite3::bindvalue and relative PHP functions aren't using sqlite3_*_int64
API functions internally or checking for a 64 bit build to do so. As a result
using SQLITE3_INTEGER constants in calls to bindValue cause internal cast to 32
bit int. This is unexpected behavior and the API calls exist internally
sqlite3.
This is also related to bug #63916 which I also patched. I'm providing an
additional patch for ext/sqlite3 in relation for the same bug.
Test script:
---
$num = 14313234244; // notice this exceeds 32 bits
$conn = new sqlite3(':memory:');
$conn->query('CREATE TABLE users (id INTEGER NOT NULL, num INTEGER NOT NULL,
PRIMARY KEY(id))');
$stmt = $conn->prepare('insert into users (id, num) values (:id, :num)');
$stmt->bindValue(':id', 1, SQLITE3_INTEGER);
$stmt->bindValue(':num', $num, SQLITE3_INTEGER);
$stmt->execute();
$stmt = $conn->query('SELECT num FROM users');
$result = $stmt->fetchArray();
printf("Expected: %d Received: %d\n", $num, $result[0]);
Expected result:
Expected: 14313234244 Received: 14313234244
Actual result:
--
Expected: 14313234244 Received: 294714180
--
Edit this bug report at https://bugs.php.net/bug.php?id=63921&edit=1
Bug #63916 [Opn]: PDO::PARAM_INT casts to 32bit int internally even on 64bit builds in pdo_sqlite
Edit report at https://bugs.php.net/bug.php?id=63916&edit=1
ID: 63916
Updated by: google...@php.net
Reported by:google...@php.net
Summary:PDO::PARAM_INT casts to 32bit int internally even on
64bit builds in pdo_sqlite
Status: Open
Type: Bug
Package:PDO related
PHP Version:5.4.10
Block user comment: N
Private report: N
New Comment:
Because we're currently running 3 branches I've sent the PR for this to master
and I'm asking for it to be merged into 5.3.NEXT, 5.4.NEXT, and 5.5.NEXT
respectively to maintain consistency.
https://github.com/php/php-src/pull/253/
Previous Comments:
[2013-01-06 05:20:07] google...@php.net
Description:
Binding a PDO parameter with pdo_sqlite on 64bit builds with PDO::PARAM_INT
forces the param to be cast internally to an int. This means 64bit ints will be
cast down to 32bit ints internally even if PHP was compiled against a 64bit
arch.
Test script:
---
$num = 14313234244; // notice this exceeds 32 bits
$conn = new PDO('sqlite::memory:');
$conn->query('CREATE TABLE users (id INTEGER NOT NULL, num INTEGER NOT NULL,
PRIMARY KEY(id))');
$stmt = $conn->prepare('insert into users (id, num) values (:id, :num)');
$stmt->bindValue(':id', 1, PDO::PARAM_INT);
$stmt->bindValue(':num', $num, PDO::PARAM_INT);
$stmt->execute();
$stmt = $conn->query('SELECT num FROM users');
$result = $stmt->fetchAll(PDO::FETCH_COLUMN);
printf("Expected: %d Received: %d\n", $num, $result[0]);
Expected result:
// expected to output
Expected: 14313234244 Received: 14313234244
Actual result:
--
// instead we get output of
Expected: 14313234244 Received: 294714180
--
Edit this bug report at https://bugs.php.net/bug.php?id=63916&edit=1
Bug #63737 [ReO]: json_decode does not properly decode with options parameter
Edit report at https://bugs.php.net/bug.php?id=63737&edit=1
ID: 63737
Updated by: google...@php.net
Reported by:google...@php.net
Summary:json_decode does not properly decode with options
parameter
Status: Re-Opened
Type: Bug
Package:JSON related
PHP Version:5.4.9
Assigned To:aharvey
Block user comment: N
Private report: N
New Comment:
This commit has been removed from the release branch for some reason.
Previous Comments:
[2013-01-02 11:46:49] franssen dot roland at gmail dot com
This is still an issue in 5.4.10 (Linux)
[2012-12-11 12:04:17] ahar...@php.net
The fix for this bug has been committed.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Fixed on 5.4, 5.5 and master.
[2012-12-11 11:04:55] ahar...@php.net
Our code path for bare integer literals is different to the one we use for
literals within objects and arrays. Should be an easy fix.
[2012-12-11 11:03:24] google...@php.net
Description:
json_decode does not properly decode JSON strings using options parameter.
Test script:
---
json_decode('12345678901234567890', false, 512, JSON_BIGINT_AS_STRING); // this
won't work
However this will
json_decode('[12345678901234567890]', false, 512, JSON_BIGINT_AS_STRING);
Expected result:
string(20) "12345678901234567890"
Actual result:
--
float(1.2345678901235E+19)
--
Edit this bug report at https://bugs.php.net/bug.php?id=63737&edit=1
Bug #63737 [Csd->ReO]: json_decode does not properly decode with options parameter
Edit report at https://bugs.php.net/bug.php?id=63737&edit=1
ID: 63737
Updated by: google...@php.net
Reported by:google...@php.net
Summary:json_decode does not properly decode with options
parameter
-Status: Closed
+Status: Re-Opened
Type: Bug
Package:JSON related
PHP Version:5.4.9
Assigned To:aharvey
Block user comment: N
Private report: N
Previous Comments:
[2013-01-02 11:46:49] franssen dot roland at gmail dot com
This is still an issue in 5.4.10 (Linux)
[2012-12-11 12:04:17] ahar...@php.net
The fix for this bug has been committed.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Fixed on 5.4, 5.5 and master.
[2012-12-11 11:04:55] ahar...@php.net
Our code path for bare integer literals is different to the one we use for
literals within objects and arrays. Should be an easy fix.
[2012-12-11 11:03:24] google...@php.net
Description:
json_decode does not properly decode JSON strings using options parameter.
Test script:
---
json_decode('12345678901234567890', false, 512, JSON_BIGINT_AS_STRING); // this
won't work
However this will
json_decode('[12345678901234567890]', false, 512, JSON_BIGINT_AS_STRING);
Expected result:
string(20) "12345678901234567890"
Actual result:
--
float(1.2345678901235E+19)
--
Edit this bug report at https://bugs.php.net/bug.php?id=63737&edit=1
Req #42691 [Opn->Csd]: array_reduce: initial parameter should allow non-numeric values
Edit report at https://bugs.php.net/bug.php?id=42691&edit=1 ID: 42691 Updated by: google...@php.net Reported by:tjerk dot meesters at muvee dot com Summary:array_reduce: initial parameter should allow non-numeric values -Status: Open +Status: Closed Type: Feature/Change Request Package:Arrays related Operating System: Linux 2.6 PHP Version:5.2.4 -Assigned To: +Assigned To:googleguy Block user comment: N Private report: N New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Previous Comments: [2012-08-05 22:33:41] lonnyk at gmail dot com This has been added in 5.3. I just tested it with PHP 5.4.5-dev and it works. [2007-09-18 02:27:59] tjerk dot meesters at muvee dot com Description: array_reduce() accepts an initial value to be passed as the first argument in the callback function instead of NULL. However, this initial value - if passed - is converted to an int. This is probably because the more common use of this idiom is for mathematical reduction. It would be helpful to allow other types to be passed such as strings or objects. Note: this ticket is a duplicate for #42566, but the reporter never bothered to follow up. Reproduce code: --- Expected result: hello world Actual result: -- 0 world -- Edit this bug report at https://bugs.php.net/bug.php?id=42691&edit=1
