Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65195
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.220.177 cause and error)
Message-ID: <51030272.5040804@lerdorf.com>
Date: Fri, 25 Jan 2013 14:08:50 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Marco Schuster <marco@m-s-d.eu>
CC: internals <internals@lists.php.net>
References: <CAMauByUZaDMqWo3+zoR6f-jrFnAB7cL3e8uxMW7GhJgeEPsSHw@mail.gmail.com>
In-Reply-To: <CAMauByUZaDMqWo3+zoR6f-jrFnAB7cL3e8uxMW7GhJgeEPsSHw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] New uint native data type?
From: rasmus@lerdorf.com (Rasmus Lerdorf)

On 01/25/2013 01:39 PM, Marco Schuster wrote:
> Hi all,
> 
> I'm currently writing a php-program to process certain special binary
> files, which include 32-bit offsets which I need to read and
> manipulate. The problem is that PHPs int type is only 31-bit because
> they have sign information. Sure, I could use the GMP/bcmath stuff,
> but that isn't really an option because of performance and the fact
> that I'd have to use bc* functions everywhere, and the code is already
> complex enough. Because I need to do maths and, later on, file
> accesses at positions > 2GB, with them and not just print,
> sprintf("%u",$val) is not sufficient, too.
> 
> Switching to 64-bit doesn't help in my case, as the program interfaces
> with external windows-only dependencies and the PHP x64 build doesn't
> do 64-bit ints at the moment.
> 
> Would it be possible to extend the PHP engine and add a "uint" native
> type which allows handling of full 32-bit values and if yes, is there
> any documentation about the parts of the engine I need to modify? The
> PHP internals manual doesn't have much content and the Zend / main
> directories in the source code lack useful information, too.

No, this isn't something a quick patch will solve for you. It would
require changes throughout all of PHP and all the extensions.

For display purposes you can easily print these unsigned using
s/printf('%u',$val) and manipulation is possible too depending on what
sort of things you are trying to do to them.

If that isn't enough, writing a little custom extension to handle your
special case for these offsets is way way easier than modifying PHP to
add a new type.

-Rasmus