php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #43525 [PATCH] zend_list functions should take ulong IDs
Submitted: 2007-12-07 05:13 UTC Modified: 2015-01-22 12:06 UTC
Votes:2
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:1 (50.0%)
From: mi+php at aldan dot algebra dot com Assigned: ab (profile)
Status: Closed Package: Scripting Engine problem
PHP Version: 5.2.5 OS: FreeBSD/amd64
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: mi+php at aldan dot algebra dot com
New email:
PHP Version: OS:

 

 [2007-12-07 05:13 UTC] mi+php at aldan dot algebra dot com 
Description:
------------
The "id" variable in the zend_list family of functions should be ulong (or uintptr_t, as pointers are often stored there). It already is ulong in the underlying "workhorse" function zend_hash_index_find.

At least one spot -- in in pgsql.c -- makes an id from a pointer, which leads to nasty occasional errors and httpd-/crashes/ on 64-bit platforms.

Please, find the patch on http://virtual-estates.com/~mi/port-stuff/patch-zend_list

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-01-29 10:13 UTC] dmitry@php.net 
The fact that ext/pgsql uses ZE API in wrong way, doesn't mean that we should fix the API. It is especially impossible in PHP_5_2 branch, because it'll break binary compatibility.

I would suggest fix the bug in ext/pgsql by using other data structures.
 [2008-01-29 15:00 UTC] mi+php at aldan dot algebra dot com 
The original problem may, indeed, be a problem with PostgreSQL back-end, but the dropping of bits by the list-API is gratuitous. There is no need for it to truncate to int, because internally it stores ulong values anyway...

It may make sense to keep the 5_2 branch binary-compatible (even though the compatibility would only be broken on 64-bit platforms), but going forward the API should change...

Come to think of it, I am not sure, the ABI would break even on 64-bit platforms, as you'd be widening (rather than narrowing) the acceptable values.
 [2011-01-01 23:23 UTC] jani@php.net
-Package: Feature/Change Request +Package: Scripting Engine problem
 [2014-12-16 23:34 UTC] kalle@php.net
-Status: Open +Status: Feedback
 [2014-12-16 23:34 UTC] kalle@php.net 
Please try using this snapshot:

  http://snaps.php.net/php-trunk-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

Please try a PHP7 snapshot (master)
 [2014-12-28 23:51 UTC] kalle@php.net
-Status: Feedback +Status: Assigned -Assigned To: +Assigned To: ab
 [2014-12-28 23:51 UTC] kalle@php.net 
Anatol, is this still an issue after the int64 branch merge?
 [2015-01-22 12:06 UTC] ab@php.net
-Status: Assigned +Status: Closed
 [2015-01-22 12:06 UTC] ab@php.net 
I was writing here https://www.mail-archive.com/internals@lists.php.net/msg72373.html with a suggestion for master. Since no one has reacted,seems that the idea wasn't interesting.

In general - an integer can still identify a resource, whereby it's now only makes sense at the places where an underlying library enforces it. Otherwise, the list api works with a pointer to the resource structure, that makes an overflow impossible.

Thanks.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Mon Dec 23 08:01:29 2024 UTC