Re: int64/size_t options votes clarification

From: Date: Fri, 31 Jan 2014 09:08:42 +0000
Subject: Re: int64/size_t options votes clarification
References: 1 2  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
On 01/31/2014 08:41 AM, Stas Malyshev wrote:
Hi!
The option #1 (Keep the old macro names for LONG vs. INT, STRLEN vs. STRSIZE, etc.) and #2 (Keep zpp specs l, L, s, p as aliases to i, I, S, P), which both drastically reduce code changes or #fidef usage, are valid for 5.6 integration.
The first one seems to me relatively tame, at least unless I'm missing something. I'm not one to give too much importance to precision of naming of macros, but why not make it easy on people? The second one, however, seems dangerous - that means if I forget to convert some function that uses zpp, I get no indication at all, except for random hard-to-debug crashes when it's used with wrong int type. The alternative for this is (PHP_NEED_STRSIZE_COMPAT ? "Os|al" : "OS|ai"), which feels my heart with dread and one of the reasons why I lean to voting "no", even though I like the idea of the cleanup. But compared to the alternative, this is a *better* option. Because at least this would fail fast in the case of trouble and will be discovered if you have any half-decent tests on your extension. The other way means if you forget to convert the zpp call and do convert the values involved, you'd have very interesting debugging session waiting for you.
For those having voted no for 5.6 and the options, would you mind explaining what are your wishes? It will help to move forward, no matter the outcome of the votes.
My personal preference for now is to make this change base for PHP 6 branch. We've started talking on 6 anyway, and I don't see it out of the possible to kick off real feature mapping and even start working on it this year, and have at least early alphas sometime next year. This would be our opportunity to break APIs to make them better. If that is not what happening, what I am afraid of is that people - at least ones that use custom extensions and work on sizeable products with non-trivial QA cycles - would treat 5.6 as somewhat a theoretical exercise and would wait it out for 6 (unless we starve them out by never delivering on it in next 3-4 years). And that's not a good place for a release to be in. I like the things done in 5.6, and I like the work Anatol and others have done on 64-bit cleanup. But I'm afraid that by combining them we'd harm them both.
My personal preference for now is to make this change base for PHP 6 branch.
+1000 ... this is the only option that really makes sense ... Cheers Joe

Thread (5 messages)

« previous php.internals (#71833) next »