hi Anthony! On Wed, Jul 3, 2013 at 4:12 PM, Anthony Ferrara <ircmax...@gmail.com> wrote: > Hey all, > > So I've started the refactor to change the stored string size from int to > size_t.
Great work so far! Thanks! :) > I've got it compiling and the tests mostly passing (not all), when run with > --disable-all and --disable-cgi. > > There are definitely still issues with the patch (there are some weird > segfaults in certain times, which are caught by the tests), but it's > progressing really nicely. > > Here's what I did: > > I created a new build option: --enable-zstrlen. This turns off the new > match, and type-defs and defines everything back to how it was before. This > is really useful for testing changes to ensure that they still work. > > Then, I defined a series of new types: > > #ifdef ZEND_USE_LEGACY_STRING_TYPES > > #define zend_str_size_int int > #define zend_str_size_uint unsigned int > #define zend_str_size_size_t size_t > #define zend_str_size_long long > typedef int zend_str_size; > > #else > > #define zend_str_size_int zend_str_size > #define zend_str_size_uint zend_str_size > #define zend_str_size_size_t zend_str_size > #define zend_str_size_long zend_str_size > typedef size_t zend_str_size; > > #endif > > Any API that accepted a string size parameter, I replace with one of the > zend_str_size_* definitions. I chose to do this instead of just changing it > directly to zend_str_size, as it should make extension developer's lives > easier by supporting the intermediate types (with their own define lines > for older versions of the API). > > These are intended to be removed after 1 or 2 releases, replacing > everything with just zend_str_size. > > Due to a problem with zend_parse_parameters, I added two new identifiers: S > and P. They act just like s and p, except that they return zend_str_size > instead of int. > > When `--enable-zstrlen` is not enabled, I disable s and p, and changed ZPP > to rase an E_ERROR on unknown parameter types. The E_ERROR change is not > intended to go into production, but instead just makes life A LOT easier > refactoring modules one at a time. Like it, easy way to switch back and forth in case something is not running smoothly or not as it should. > Here's what's left to do: > > I've only really got the basic system working (for limited definitions of > working). There's a ton of extensions that need migrating, and tons of > parts of the core that i haven't fully migrated yet. > > I've migrated php_pcre.c over, but pcrelib still uses int for string sizes. > This is going to be a much larger refactor, and I wanted to see people's > thoughts prior to digging into it. This is something we have to care about for all other external libs, as we discussed earlier on IRC, this task will be as huge as the one in PHP, if not more time consuming (convincing upstream projects to change some APIs, f.e.). > Substr needs to be refactored to use size_t. Right now, I just raise an > error if Z_STRSIZE > INT_MAX (or an overflow would happen). I'd love to see > that cleaned up more. We should consider moving to int64_t too as well while being at it. For many reasons or platforms it makes sense to drop (unsigned) long/int usage as well (and all derived types) and uses (u)int*_t instead. I'd to see this task as strongly related to the size_t move. It will also solve many other related issues (LFS support, 64bit integer portability issues, etc.). What do you think? > Here's the branch: > https://github.com/ircmaxell/php-src/tree/string_size_refactor_take_2 > And the diff: > https://github.com/ircmaxell/php-src/compare/string_size_refactor_take_2 > > If you want to help out, please let me know and let's try to coordinate so > we don't step on each other's toes... It would be awesome to add this fork to lxr, it can be amazingly helpful. From our side, we are testing and fixing (Weltling) it already, we will try to do it on regular basis to do not stay behind or do to do not have to debug a huge amount of changes to fix one bug or another (can be painful with this kind of changes). Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
