On Mon, Aug 25, 2014 at 2:59 PM, Pierre Joye <pierre....@gmail.com> wrote:
> > On Aug 25, 2014 12:56 PM, "Dmitry Stogov" <dmi...@zend.com> wrote: > > > > > > > > > > On Mon, Aug 25, 2014 at 2:45 PM, Pierre Joye <pierre....@gmail.com> > wrote: > >> > >> > >> On Aug 25, 2014 9:22 AM, "Dmitry Stogov" <dmi...@zend.com> wrote: > >> > > >> > Hi Pierre, > >> > > >> > I'm glad, you agree to rename IS_INT back to IS_LONG. > >> > > >> > zend_long and size_t usage looks fine. > >> > > >> > I see no problems changing zend_string related API and related macros > introduced in NG. They are new for everyone. > >> > I hope, the changes won't make API less clear or useful (so it would > be great to review them). > >> > > >> > I don't see a big reason to rename "zend_uint" into "uint32_t", but > it's just my own opinion. I would prefer keep it as is, or at worse case > rename into "zend_uint32" or "uint32". Anyway, I'll agree with majority. > >> > > >> > >> uint32_t :) > > > > 3 people are not the majority (or may be I missed discussion on IRC). > > It's better to think before changing something in many places without a > real reason. > > Why do we need it when the standard type exists and does exactly what we > want? Same for size_t. It is mostly contained in the engine, no other > impact and avoid yet another type definition for existing standard type (we > have php_stdint.h to make them always available). > We never had zend_size_t before and used size_t. but we had zend_uint for ages and changing it to new name in thousand places won't make a lot of sense. If you like to make it always be a 32-bit number, just change the definition. If you are going to rename zend_uint, should we expect renaming of all the similar zend_* types from zend_types.h? typedef unsigned char zend_bool; typedef unsigned char zend_uchar; typedef unsigned int zend_uint; typedef unsigned long zend_ulong; typedef unsigned short zend_ushort; Thanks. Dmitry. >> > How are we going to proceed? > >> > Do you like voting in > https://wiki.php.net/rfc/better_type_names_for_int64 or you may just > revert part of the int64 patch related to IS_LONG -> IS_INT renaming? > >> > >> We will just do the changes listed in the initial mail. The sooner the > better. Anatol or I will do it. It should be ready by Wednesday. If we can > avoid a 2-3 weeks delay let not do the rfc. As these changes match what was > discussed and fit with the majority (subjective part as only the vocal > ones), we should not see any objection. We will simply apply it on > Wednesday if nobody complained. > > > > Agree, we need it ASAP. > > I'll try not to commit anything big to not make you additional troubles. > > > > Thanks. Dmitry. > > Thanks > > Cheers, > Pierre >
