Re: 5.NEXT Integer and String type modifications
| From: | Andrey Hristov | Date: | Sat, 01 Jun 2013 09:53:42 +0000 |
| Subject: | Re: 5.NEXT Integer and String type modifications | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-67601@lists.php.net to get a copy of this message | ||
Hi,
On 05/31/2013 10:03 PM, Anthony Ferrara wrote:
Derick, In principle I think this is great thing to do. Not having a 64 bit type isBest, Andreyannoying. I'm a bit curious on how this is going to work with all sorts of object wrappers that are now in place as workaround. And casting int64 to int32 needs to very well looked at as well.As far as the casting, my first reaction would be to raise an E_ENGINE_NOTICE on data loss (casting from int64 to int32 with ints > 32 bit) and then adjusting the value to the nearest representable value (LONG_MAX or LONG_MIN). In other words, it may need to be more than a simple cast (an inline function perhaps)... As far as object wrappers, any particular examples that you're thinking of? Thanks for the thoughts Anthony what about new type IS_LONG64, new field in union and new set of macros for this type. New extensions or rewritten extensions will use the new macros. In 2-3 major versions, 5.8 for example, old macros will be dropped. Enough time extensions to be ported to the new macros.