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 back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
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 07:01:31 2024 UTC