Re: 5.NEXT Integer and String type modifications
| From: | Ivan Enderlin @ Hoa | Date: | Tue, 04 Jun 2013 13:24:55 +0000 |
| Subject: | Re: 5.NEXT Integer and String type modifications | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-67628@lists.php.net to get a copy of this message | ||
On 04/06/13 12:08, Pierre Joye wrote:
On Tue, Jun 4, 2013 at 10:41 AM, Ivan Enderlin @ Hoa <ivan.enderlin@hoa-project.net> wrote:-- Ivan Enderlin Developer of Hoa http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/Hey :-), On 02/06/13 08:52, Johannes Schlüter wrote:We do it using Visual C++ static analyzer, which is an excellent tool for this kind of issue, almost on all commits. As soon as we have a fork for these changes I will add it so we can get regular updates. Excellent!Is it possible to use a static C analyzer here? It could help a lot. I think about Frama-C [1], Pork [2] (now included in Oink [3]) or Clang Static Analyser [4] to name a few. A more complete list can be found in [5].It would be a *gigantic* patch, but the userland effects should be minimal (the only changes would be supporting longer strings, and consistent 64 bit int support). The performance considerations should be minimal for non-legacy code (as both would still be using native data types)...History shows that such gigantic patches are often not finished and done as people underestimate the size of PHP and the fact that all etensions have to be checked which for this case means checking each external lib for their correct type for all their functions etc ... but I don't wan to stop you, I'm happy if you do this :-) (while I'm also happy about everybody spending time on fixing bugs instead of adding such high-risk changes ;-))