[PHP-DEV] Change IntlChar::getNumericValue() to return something less horrible when the char is not numeric?

[Net Mo]

ICU documentation:
http://icu-project.org/apiref/icu4c/uchar_8h.html#a36982efc84143b9bb5a11bf54b86af48

Currently the PHP function returns the U_NO_NUMERIC_VALUE constant, which
is set to the very weird "float(-123456789)"; basically it's a value that
it's certain it doesn't have an Unicode numeric character equivalent
counterpart.

I would change the function to return NULL instead; what do you think?

[PHP-DEV] random_compat

[Scott Arciszewski]

Hi everyone,

I'm working on a library to backport random_bytes() and random_int()
into PHP 5. The effort is located on Github if anyone is interested:
https://github.com/paragonie/random_compat

My reason for this email is that I'm running into one compatibility
issue that I don't think I can safely work around: If we let
random_int() default to -PHP_INT_MAX and PHP_INT_MAX, then the
difference between the two (used to calculate the range) will overflow
into a float, which will lead to a loss of precision.

My current compromise is to use -(PHP_INT_MAX/2) and PHP_INT_MAX/2,
but I'm not sure if there's a better solution.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] random_compat

[Nikita Popov]

On Wed, Jul 8, 2015 at 11:59 AM, Scott Arciszewski 
wrote:

> Hi everyone,
>
> I'm working on a library to backport random_bytes() and random_int()
> into PHP 5. The effort is located on Github if anyone is interested:
> https://github.com/paragonie/random_compat
>
> My reason for this email is that I'm running into one compatibility
> issue that I don't think I can safely work around: If we let
> random_int() default to -PHP_INT_MAX and PHP_INT_MAX, then the
> difference between the two (used to calculate the range) will overflow
> into a float, which will lead to a loss of precision.
>
> My current compromise is to use -(PHP_INT_MAX/2) and PHP_INT_MAX/2,
> but I'm not sure if there's a better solution.
>

random_int() arguments don't have default values, you have to explicitly
pass both. (Of course you still have a problem if someone does pass them :)

Nikita

Re: [PHP-DEV] random_compat

[Scott Arciszewski]

You're right, I misread that part of the documentation.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises


On Wed, Jul 8, 2015 at 6:03 AM, Nikita Popov  wrote:
> On Wed, Jul 8, 2015 at 11:59 AM, Scott Arciszewski 
> wrote:
>>
>> Hi everyone,
>>
>> I'm working on a library to backport random_bytes() and random_int()
>> into PHP 5. The effort is located on Github if anyone is interested:
>> https://github.com/paragonie/random_compat
>>
>> My reason for this email is that I'm running into one compatibility
>> issue that I don't think I can safely work around: If we let
>> random_int() default to -PHP_INT_MAX and PHP_INT_MAX, then the
>> difference between the two (used to calculate the range) will overflow
>> into a float, which will lead to a loss of precision.
>>
>> My current compromise is to use -(PHP_INT_MAX/2) and PHP_INT_MAX/2,
>> but I'm not sure if there's a better solution.
>
>
> random_int() arguments don't have default values, you have to explicitly
> pass both. (Of course you still have a problem if someone does pass them :)
>
> Nikita

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: VCS Account Request: edgarsandi

[Christoph Becker]

Edgar R. Sandi wrote:

> Developing the PHP runtime
> Maintaining an official, bundled PHP extension
> Maintaining the documentation
> Translating the documentation
> Maintaining php.net

For reference (and as a gentle reminder):
.

-- 
Christoph M. Becker



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Thoughts on C version supported for PHP-Next

[Matt Wilmas]

Hi all,

- Original Message -
From: "Levi Morrison"
Sent: Sunday, May 10, 2015


Again, this is a C11 feature. It is supported by clang, gcc and MSVC.


To clarify this a bit: they permit anonymous unions in C89 and C99
code (meaning you do not need to pass flags like -std=c11 to enable
it).


What's the status on compiler requirements?  Are they, or will they be, 
higher?


I'm going to take advantage of variadic macros (__VA_ARGS__) for better code 
generation with the parameter parsing implementation I'm finishing up, and 
it would be nice to not have to make two versions with a compiler check. 
e.g. for MSVC or GCC >= 3, but I don't know what else...


Thanks,
Matt 



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Thoughts on C version supported for PHP-Next

[Kalle Sommer Nielsen]

Hi Matt

2015-07-08 17:00 GMT+02:00 Matt Wilmas :
> Hi all,
>
> - Original Message -
> From: "Levi Morrison"
> Sent: Sunday, May 10, 2015
>
>>> Again, this is a C11 feature. It is supported by clang, gcc and MSVC.
>>
>>
>> To clarify this a bit: they permit anonymous unions in C89 and C99
>> code (meaning you do not need to pass flags like -std=c11 to enable
>> it).
>
>
> What's the status on compiler requirements?  Are they, or will they be,
> higher?
>
> I'm going to take advantage of variadic macros (__VA_ARGS__) for better code
> generation with the parameter parsing implementation I'm finishing up, and
> it would be nice to not have to make two versions with a compiler check.
> e.g. for MSVC or GCC >= 3, but I don't know what else...

For 7.0, we are gonna focus on MSVC 2015 (VC14), although VC11 is also
known to work, we will do the 7.0+ releases with VC14 (that is
releasing later this month)



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Thoughts on C version supported for PHP-Next

[Matt Wilmas]

Hi Kalle,

- Original Message -
From: "Kalle Sommer Nielsen"
Sent: Wednesday, July 08, 2015


Hi Matt

2015-07-08 17:00 GMT+02:00 Matt Wilmas :

Hi all,

- Original Message -
From: "Levi Morrison"
Sent: Sunday, May 10, 2015


Again, this is a C11 feature. It is supported by clang, gcc and MSVC.



To clarify this a bit: they permit anonymous unions in C89 and C99
code (meaning you do not need to pass flags like -std=c11 to enable
it).



What's the status on compiler requirements?  Are they, or will they be,
higher?

I'm going to take advantage of variadic macros (__VA_ARGS__) for better 
code
generation with the parameter parsing implementation I'm finishing up, 
and

it would be nice to not have to make two versions with a compiler check.
e.g. for MSVC or GCC >= 3, but I don't know what else...


For 7.0, we are gonna focus on MSVC 2015 (VC14), although VC11 is also
known to work, we will do the 7.0+ releases with VC14 (that is
releasing later this month)


Right, but MSVC isn't a concern for the variadic macros thing I'm talking 
about (supported since 2005). [1]


I'm just wondering about the subject of this old thread: have we bumped, or 
will we, the minimum requirements for *ALL the other compilers* PHP 
"supports?" e.g. requiring some or all of C99 support?  That would hopefully 
say whether we can rely on variadic macros. :-)


Thanks,
Matt

[1] https://en.wikipedia.org/wiki/Variadic_macro 



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Thoughts on C version supported for PHP-Next

[Anatol Belski]

Hi Matt,

> -Original Message-
> From: Matt Wilmas [mailto:php_li...@realplain.com]
> Sent: Wednesday, July 8, 2015 5:17 PM
> To: Kalle Sommer Nielsen
> Cc: PHP internals; Levi Morrison; Pierre Joye; Nikita Popov; Christoph
Becker;
> Dmitry Stogov; Anatol Belski; Julien Pauli; Derick Rethans
> Subject: Re: [PHP-DEV] Thoughts on C version supported for PHP-Next
> 
> Hi Kalle,
> 
> - Original Message -
> From: "Kalle Sommer Nielsen"
> Sent: Wednesday, July 08, 2015
> 
> > Hi Matt
> >
> > 2015-07-08 17:00 GMT+02:00 Matt Wilmas :
> >> Hi all,
> >>
> >> - Original Message -
> >> From: "Levi Morrison"
> >> Sent: Sunday, May 10, 2015
> >>
>  Again, this is a C11 feature. It is supported by clang, gcc and MSVC.
> >>>
> >>>
> >>> To clarify this a bit: they permit anonymous unions in C89 and C99
> >>> code (meaning you do not need to pass flags like -std=c11 to enable
> >>> it).
> >>
> >>
> >> What's the status on compiler requirements?  Are they, or will they
> >> be, higher?
> >>
> >> I'm going to take advantage of variadic macros (__VA_ARGS__) for
> >> better code generation with the parameter parsing implementation I'm
> >> finishing up, and it would be nice to not have to make two versions
> >> with a compiler check.
> >> e.g. for MSVC or GCC >= 3, but I don't know what else...
> >
> > For 7.0, we are gonna focus on MSVC 2015 (VC14), although VC11 is also
> > known to work, we will do the 7.0+ releases with VC14 (that is
> > releasing later this month)
> 
> Right, but MSVC isn't a concern for the variadic macros thing I'm talking
about
> (supported since 2005). [1]
> 
> I'm just wondering about the subject of this old thread: have we bumped,
or will
> we, the minimum requirements for *ALL the other compilers* PHP "supports?"
> e.g. requiring some or all of C99 support?  That would hopefully say
whether we
> can rely on variadic macros. :-)
> 
There was an idea to gather as much info as we can, a repo was created
https://github.com/FriendsOfPHP/phpnextctest . If you have some more
snippets, please supply a PR. Also if you think about a particular compiler,
you might add a makefile for it.

Regards

Anatol 



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Thoughts on C version supported for PHP-Next

[Levi Morrison]

On Wed, Jul 8, 2015 at 9:16 AM, Matt Wilmas  wrote:
> Hi Kalle,
>
>
> - Original Message -
> From: "Kalle Sommer Nielsen"
> Sent: Wednesday, July 08, 2015
>
>> Hi Matt
>>
>> 2015-07-08 17:00 GMT+02:00 Matt Wilmas :
>>>
>>> Hi all,
>>>
>>> - Original Message -
>>> From: "Levi Morrison"
>>> Sent: Sunday, May 10, 2015
>>>
> Again, this is a C11 feature. It is supported by clang, gcc and MSVC.



 To clarify this a bit: they permit anonymous unions in C89 and C99
 code (meaning you do not need to pass flags like -std=c11 to enable
 it).
>>>
>>>
>>>
>>> What's the status on compiler requirements?  Are they, or will they be,
>>> higher?
>>>
>>> I'm going to take advantage of variadic macros (__VA_ARGS__) for better
>>> code
>>> generation with the parameter parsing implementation I'm finishing up,
>>> and
>>> it would be nice to not have to make two versions with a compiler check.
>>> e.g. for MSVC or GCC >= 3, but I don't know what else...
>>
>>
>> For 7.0, we are gonna focus on MSVC 2015 (VC14), although VC11 is also
>> known to work, we will do the 7.0+ releases with VC14 (that is
>> releasing later this month)
>
>
> Right, but MSVC isn't a concern for the variadic macros thing I'm talking
> about (supported since 2005). [1]
>
> I'm just wondering about the subject of this old thread: have we bumped, or
> will we, the minimum requirements for *ALL the other compilers* PHP
> "supports?" e.g. requiring some or all of C99 support?  That would hopefully
> say whether we can rely on variadic macros. :-)
>
> Thanks,
> Matt
>
> [1] https://en.wikipedia.org/wiki/Variadic_macro


Right now we definitely require some of C99. The topic was directed
more at whether we can adopt it as a whole.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Change IntlChar::getNumericValue() to return something less horrible when the char is not numeric?

[Levi Morrison]

On Wed, Jul 8, 2015 at 1:50 AM, Net Mo  wrote:
> ICU documentation:
> http://icu-project.org/apiref/icu4c/uchar_8h.html#a36982efc84143b9bb5a11bf54b86af48
>
> Currently the PHP function returns the U_NO_NUMERIC_VALUE constant, which
> is set to the very weird "float(-123456789)"; basically it's a value that
> it's certain it doesn't have an Unicode numeric character equivalent
> counterpart.
>
> I would change the function to return NULL instead; what do you think?

Why is comparing to U_NO_NUMERIC_VALUE undesirable?

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Wiki access for ihabunek

[Christoph Becker]

Ivan Habunek wrote:

> Took a little longer than planned, since i was away on a business trip
> last week. I actually ended up restructuring the document a little. To
> me it seems much more readable this way. I put it up in a Gist for you
> to have a look:
> https://gist.github.com/ihabunek/c74fb2d555fecea37aef
> 
> Any comments would be appreciated. If you're generally happy with it,
> I can apply it to the wiki and we can make incremental updates from
> there on.

IMO that's nice improvement, and I suggest to put it on the Wiki.  One
detail that might need clarification is the destination folder of the
binaries.  This is not necessarily Release_TS, but may be Release or
Debug(_TS) as well, but more importantly, it appears to be
x64/Release_TS (etc.) for 64bit builds.

-- 
Christoph M. Becker


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Change IntlChar::getNumericValue() to return something less horrible when the char is not numeric?

[Stanislav Malyshev]

Hi!

> ICU documentation:
> http://icu-project.org/apiref/icu4c/uchar_8h.html#a36982efc84143b9bb5a11bf54b86af48
> 
> Currently the PHP function returns the U_NO_NUMERIC_VALUE constant, which
> is set to the very weird "float(-123456789)"; basically it's a value that
> it's certain it doesn't have an Unicode numeric character equivalent
> counterpart.
> 
> I would change the function to return NULL instead; what do you think?

While the exact value of U_NO_NUMERIC_VALUE looks weird, nobody is going
to use it directly, you'd be using U_NO_NUMERIC_VALUE. Comparing to it
doesn't look wrong. So changing that to null doesn't seem to improve
much, just introduce incompatibility with ICU.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Wiki access for ihabunek

[Pierre Joye]

hi Ivan,

On Mon, Jul 6, 2015 at 2:51 PM, Ivan Habunek  wrote:
> Hey all,
>
> Took a little longer than planned, since i was away on a business trip
> last week. I actually ended up restructuring the document a little. To
> me it seems much more readable this way. I put it up in a Gist for you
> to have a look:
> https://gist.github.com/ihabunek/c74fb2d555fecea37aef
>
> Any comments would be appreciated. If you're generally happy with it,
> I can apply it to the wiki and we can make incremental updates from
> there on.

Great job, thanks!

You can remove references to 5.3 as we don't support it anymore.

A possible improvement would be to make either a table or a section
per PHP version for the setup (install vc9, vc11 or vc14). Maybe add a
list for VS20xx==VCn too, you can find the tuples here
http://lxr.php.net/xref/PHP_5_5/win32/build/confutils.js#57.

However it is already a big improvement, go ahead for the update! :)

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Change IntlChar::getNumericValue() to return something less horrible when the char is not numeric?

[Net Mo]

I've asked Sara to add the NO_NUMERIC_VALUE constant to IntlChar because it
is missing, but she suggested the method could return NULL instead.
Any of the two options is fine for me...

2015-07-08 21:45 GMT+02:00 Stanislav Malyshev :

> Hi!
>
> > ICU documentation:
> >
> http://icu-project.org/apiref/icu4c/uchar_8h.html#a36982efc84143b9bb5a11bf54b86af48
> >
> > Currently the PHP function returns the U_NO_NUMERIC_VALUE constant, which
> > is set to the very weird "float(-123456789)"; basically it's a value that
> > it's certain it doesn't have an Unicode numeric character equivalent
> > counterpart.
> >
> > I would change the function to return NULL instead; what do you think?
>
> While the exact value of U_NO_NUMERIC_VALUE looks weird, nobody is going
> to use it directly, you'd be using U_NO_NUMERIC_VALUE. Comparing to it
> doesn't look wrong. So changing that to null doesn't seem to improve
> much, just introduce incompatibility with ICU.
>
> --
> Stas Malyshev
> smalys...@gmail.com
>