Actually, a better approach is to use /dev/urandom to seed a PRG.
See my previous email in this thread regarding the FIPS approved generators.
Bryan
-Original Message-
From: Leigh [mailto:lei...@gmail.com]
Sent: Friday, August 30, 2013 6:27 PM
To: Marc Bennewitz
Cc: internals@lists.php.
First, I want to ask: Does anyone else think we should draw a distinction
between RNGs and CSPRNGs?
I ask this because the OpenSSL option here is the only CSPRNG; The others are
trivially breakable and should not be used for cryptographic applications. I
could see an argument for wanting to use
Hi!
Am 31.8.2013 um 01:39 schrieb Lazare Inepologlou :
>
>
> 2013/8/31 Bob Weinand
> Hi!
>
> Am 31.8.2013 um 00:27 schrieb Lazare Inepologlou :
>
> > 2013/8/30 Stas Malyshev
> >
> >>> don't see a reason why one should explicitly disallow doing multiple
> >>> unpacks.
> >>
> >> Because it ma
Hi!
Am 31.8.2013 um 01:39 schrieb Stas Malyshev :
> Hi!
>
>> function short (...$args) {
>>if (count($args))
>>return long(...$args, "some value");
>> }
>
> This is exactly the problem. Since $args has undefined number of
> arguments, there's no way to determine where "some value" e
Hi,
On 30 Aug, 2013, at 11:29 PM, Rasmus Schultz wrote:
> No replies probably means no one cares. oh well.
>
> For the record, the examples I posted are wrong - the correct way to
> convert the long values consistently appears to be:
>
> list($v) = array_values(unpack('l', pack('l', ip2long('2
On Fri, Aug 30, 2013 at 03:21:47PM -0700, Stas Malyshev wrote:
> Hi!
>
> > We got a performance win from exactly this at Facebook. We have some
> > extensions in HHVM to autoload that allowed us to remove almost all
> > our *_once calls.
>
> But autoloading does not remove require - you still ha
2013/8/31 Bob Weinand
> Hi!
>
> Am 31.8.2013 um 00:27 schrieb Lazare Inepologlou :
>
> > 2013/8/30 Stas Malyshev
> >
> >>> don't see a reason why one should explicitly disallow doing multiple
> >>> unpacks.
> >>
> >> Because it makes very hard to understand what's going on and makes no
> >> sens
Hi!
> As far as complicated and fragile logic, as Nikita pointed out, you
> could put all of your functions inside of a "functions,php" in a
It's the same as making it Functions.php and a class. I don't see why we
should overhaul the autoloading in the engine and add so many complexity
just to av
Hi!
> function short (...$args) {
> if (count($args))
> return long(...$args, "some value");
> }
This is exactly the problem. Since $args has undefined number of
arguments, there's no way to determine where "some value" ends up. Which
means it's impossible to understand what's going o
On 30 August 2013 20:58, Marc Bennewitz wrote:
> what is the best algorithm?
Well that is platform dependant. For example on FreeBSD you'd hope
/dev/random was used (which does not block like linux, and generates a
crypto quality pseudo-random stream)
Point being, "best" is not easily defined
Hi!
Am 31.8.2013 um 00:27 schrieb Lazare Inepologlou :
> 2013/8/30 Stas Malyshev
>
>>> don't see a reason why one should explicitly disallow doing multiple
>>> unpacks.
>>
>> Because it makes very hard to understand what's going on and makes no
>> sense semantically.
>>
>>> As you can see, he
Hi!
> Not sure I get what you mean. All languages with argument unpacking
> allow this. It's not commonly needed, but there are uses for it and I
I mean this:
>>> a = [0,3]
>>> range(*a)
[0, 1, 2]
>>> a = [1]; b = [2]
>>> range(*a, *b)
File "", line 1
range(*a, *b)
^
SyntaxE
2013/8/31 Stas Malyshev
> Hi!
>
> > We got a performance win from exactly this at Facebook. We have some
> > extensions in HHVM to autoload that allowed us to remove almost all
> > our *_once calls.
>
> But autoloading does not remove require - you still have to load the
> files.
But it remove
2013/8/30 Stas Malyshev
> > don't see a reason why one should explicitly disallow doing multiple
> > unpacks.
>
> Because it makes very hard to understand what's going on and makes no
> sense semantically.
>
> > As you can see, here two arguments are unpacked in one call.
>
> This is very special
Hi!
> We got a performance win from exactly this at Facebook. We have some
> extensions in HHVM to autoload that allowed us to remove almost all
> our *_once calls.
But autoloading does not remove require - you still have to load the
files. Only thing that can be removed is a non-loading require
Stas,
I see a number of places where hash lookup is replaced with
> zend_lookup_function, not with the macro. Moreover, zend_lookup_function
> for some reason copies and lowercases the argument, even though for hash
> lookup it should already be lowercased.
There was quite literally one place I
Hi!
> This RFC proposes to add a syntax for argument unpacking:
>
> https://wiki.php.net/rfc/argument_unpacking
>
> Basically, this is the "complement" of the variadics RFC: It is not about
> declaring variadic functions, but about calling them.
This is just another way of doing call_user_f
On 08/30/2013 05:23 PM, Nikita Popov wrote:
Hi internals!
This RFC proposes to add a syntax for argument unpacking:
https://wiki.php.net/rfc/argument_unpacking
Basically, this is the "complement" of the variadics RFC: It is not about
declaring variadic functions, but about calling them.
Am 30.08.2013 04:30, schrieb Yasuo Ohgaki:
> On Thu, Aug 29, 2013 at 9:00 PM, Ángel González wrote:
>
>> Marc Bennewitz wrote:
>>
>>> Idea for an RFC for a more powerful (and backward compatible) API of
>>> random number generator functions.
>>>
>>> The following psaudocode is self explained (hop
2013/8/30 jbo...@openmv.com
> On Wed Aug 28 11:47 AM, Nikita Popov wrote:
> >
> > https://wiki.php.net/rfc/variadics
>
> Interesting idea, expanding on:
>
> function log($message, ...$options) {}
>
> It would seem convenient to allow ...$options to be passed as a key-value
> array of argument
Am 29.08.2013 14:00, schrieb Ángel González:
> Marc Bennewitz wrote:
>> Idea for an RFC for a more powerful (and backward compatible) API of
>> random number generator functions.
>>
>> The following psaudocode is self explained (hopfully)
>>
>> const RAND_ALGO_LIBC
>> const RAND_ALGO_MERSENNE_TWIST
Hi,
Please find attached a patch for adding large file size support to PHP
5.5.1.
Basically, it allows 32 bits machine to address file larger than 4GB, get
correct results when asking for their size, allows to read and write them,
etc...
It does so by, from the PHP's side, getting double instea
On Wed Aug 28 11:47 AM, Nikita Popov wrote:
>
> https://wiki.php.net/rfc/variadics
Interesting idea, expanding on:
function log($message, ...$options) {}
It would seem convenient to allow ...$options to be passed as a key-value array
of arguments as well:
function logA($message, ...$optio
2013/8/30 Stas Malyshev
> Hi!
>
> > Well, static methods aren't the same as functions.
>
> The big difference being?
>
A function is stateless [1], a method isn't. A function operates only on
the passed parameters [1], the method operates on the parameters and the
context it inherits from the in
On Fri, Aug 30, 2013 at 05:13:05PM +0100, Leigh wrote:
> On Aug 30, 2013 1:31 PM, "Anthony Ferrara" wrote:
> > For constants and function calls, the benchmark shows that the difference
> > is well within the margin of error for the test (considering variances of
> > 5% to 10% were common in my run
No replies probably means no one cares. oh well.
For the record, the examples I posted are wrong - the correct way to
convert the long values consistently appears to be:
list($v) = array_values(unpack('l', pack('l', ip2long('255.255.255.0';
I missed the fact that array_values() returns an ar
On Fri, Aug 30, 2013 at 11:23 PM, Nikita Popov wrote:
> Hi internals!
>
> This RFC proposes to add a syntax for argument unpacking:
>
> https://wiki.php.net/rfc/argument_unpacking
>
> Basically, this is the "complement" of the variadics RFC: It is not about
> declaring variadic functions, but
On Fri, Aug 30, 2013 at 7:45 PM, Stas Malyshev wrote:
> Hi!
>
> > Assuming you mean call_user_func_array, yes. This is just syntax sugar
> > for call_user_func_array. Advantages of this syntax over cufa are
> > outlined here:
> >
> https://wiki.php.net/rfc/argument_unpacking#advantages_over_call_u
2013/8/30 Stas Malyshev
> Hi!
>
> > This RFC proposes to add a syntax for argument unpacking:
> >
> > https://wiki.php.net/rfc/argument_unpacking
> >
> > Basically, this is the "complement" of the variadics RFC: It is not about
> > declaring variadic functions, but about calling them.
>
> Thi
On Fri, Aug 30, 2013 at 4:52 PM, Johannes Schlüter
wrote:
>
> On Fri, 2013-08-30 at 16:43 +0200, X Ryl wrote:
> > Hi,
> >
> >
> > Please find attached a patch for adding large file size support to
> > PHP 5.5.1.
>
> The patch didn't make it. Please send as text/plain (i.e. using .txt
> extension
I definitely do not want a NON_STRICT mode for interpreting JSON. A
NON_STRICT mode is a very bad idea, no matter how well intentioned.
On Fri, Aug 30, 2013 at 11:48 AM, Rasmus Schultz wrote:
> array(2) {
> [2130706433]=>
> string(3) "foo"
> ["4294967040"]=>
> string(3) "bar"
> }
>
> The keys are now two different types (string vs int) on 32-bit platforms,
> which leads to problems with strict comparison.
>
Prefix your key
Hi internals!
This RFC proposes to add a syntax for argument unpacking:
https://wiki.php.net/rfc/argument_unpacking
Basically, this is the "complement" of the variadics RFC: It is not about
declaring variadic functions, but about calling them.
The syntax it introduces looks as follows:
2013/8/30 Stas Malyshev
> Hi!
>
> > A good example would be function forwarding for variadic functions,
> > without resorting to call_user_func_array.
>
> What's wrong with "resorting to" call_user_func_array?
> call_user_func_array is a PHP function and not some dark magic that one
> should avoi
Hi!
> A good example would be function forwarding for variadic functions,
> without resorting to call_user_func_array.
What's wrong with "resorting to" call_user_func_array?
call_user_func_array is a PHP function and not some dark magic that one
should avoid using unless it is absolutely must.
-
Hi!
> This seems to be the core of your argumentation in this thread: "Why
> don't you just use Foo::bar() instead of foo\bar()?"
>
> In which case, I wonder why we have functions at all. We could just use
> static methods instead after all. Maybe we should deprecate function
> support?
Maybe we
Hi!
> Assuming you mean call_user_func_array, yes. This is just syntax sugar
> for call_user_func_array. Advantages of this syntax over cufa are
> outlined here:
> https://wiki.php.net/rfc/argument_unpacking#advantages_over_call_user_func_array
The only case that I see that could make sense is $d
Perhaps this illustrates the problem better:
$value = sprintf('%u', ip2long('255.255.255.0'));
var_dump($value, (int) $value);
$a = array();
$a[$value] = 'foo';
var_dump($a);
Output on 64-bit:
string(10) "4294967040"
int(4294967040)
array(1) {
[4294967040]=>
string(3) "foo"
}
No problem.
On Fri, Aug 30, 2013 at 7:10 PM, Stas Malyshev wrote:
> Hi!
>
> > Well, static methods aren't the same as functions.
>
> The big difference being?
>
This seems to be the core of your argumentation in this thread: "Why don't
you just use Foo::bar() instead of foo\bar()?"
In which case, I wonder w
On Aug 30, 2013, at 10:25 AM, Stas Malyshev wrote:
>
>> Furthermore, I think that's up to the community to decide how to do.
>> They mostly settled on a 1-class-to-1-file rule (which was not the case
>> prior to __autoload/spl_autoload). I am fully confident that they will
>> find a way that ma
Matthew,
To give another example:
var_dump(array(sprintf('%u', ip2long('127.0.0.1')) => 'foo', sprintf('%u',
ip2long('255.255.255.0')) => 'bar'));
array(2) {
[2130706433]=>
string(3) "foo"
["4294967040"]=>
string(3) "bar"
}
The keys are now two different types (string vs int) on 32-bit
Hi!
> A function is stateless [1], a method isn't. A function operates only on
> the passed parameters [1], the method operates on the parameters and the
> context it inherits from the instance (non-static), or class (static and
> non-static).
Static method is stateless in the same meaning as una
On Fri, Aug 30, 2013 at 6:57 PM, Stas Malyshev wrote:
> And something like:
> test(1, 2, ...[3, 4], 5, 6, ...[7, 8])
>
> looks plain weird. What would be the use case for doing something like
> that?
No use case at all. This is a technical specification, so I write down what
is possible, not nec
On Aug 30, 2013 1:31 PM, "Anthony Ferrara" wrote:
> For constants and function calls, the benchmark shows that the difference
> is well within the margin of error for the test (considering variances of
> 5% to 10% were common in my running of the tests).
>
> So hopefully this will dispel any worry
Hi!
> So nothing changes from present (at all) unless a function is not
> defined. Today, that's an error case. So the only performance change
> occurs if zend_hash_find (which is already there) returns FAILURE. THEN
> the logic which includes autoloading would run.
I see a number of places where
Hi!
> Just to say : one benefit of this work would be to finally have autoload
> functionnality (which is a Core feature IMO) included in Zend/ and no more
> in an extension.
PHP core already has autoload functionality. And I don't see how with
function autoloading (which has no natural mapping a
Hi!
> Well, static methods aren't the same as functions.
The big difference being?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Fri, Aug 30, 2013 at 10:29 AM, Rasmus Schultz wrote:
> No replies probably means no one cares. oh well.
>
> For the record, the examples I posted are wrong - the correct way to
> convert the long values consistently appears to be:
>
> list($v) = array_values(unpack('l', pack('l', ip2long('255.2
On Sat, Aug 31, 2013 at 12:13 AM, Leigh wrote:
> On Aug 30, 2013 1:31 PM, "Anthony Ferrara" wrote:
>> For constants and function calls, the benchmark shows that the difference
>> is well within the margin of error for the test (considering variances of
>> 5% to 10% were common in my running of th
Hi!
> And to continue the discussion, I recall that we, as PHP contributors,
> disagreed to include a PSR-0 compatible autoloader into Core.
This has nothing to do with PSR-0 in core. This has everything to do
with the fact that class-per-file is an accepted pattern in PHP and many
other language
On Fri, Aug 30, 2013 at 10:33 AM, Laruence wrote:
> On Fri, Aug 30, 2013 at 11:23 PM, Nikita Popov
> wrote:
> > Hi internals!
> >
> > This RFC proposes to add a syntax for argument unpacking:
> >
> > https://wiki.php.net/rfc/argument_unpacking
> >
> > Basically, this is the "complement" of t
On Fri, 2013-08-30 at 16:43 +0200, X Ryl wrote:
> Hi,
>
>
> Please find attached a patch for adding large file size support to
> PHP 5.5.1.
The patch didn't make it. Please send as text/plain (i.e. using .txt
extension)
> It does so by, from the PHP's side, getting double instead of int for
>
Having said that, I think the overall concept of function autoloading is a
useful feature and haven't seen a good argument for why it shouldn't be
supported.
Bryan
-Original Message-
From: Bryan C. Geraghty [mailto:br...@ravensight.org]
Sent: Friday, August 30, 2013 8:13 AM
To: 'Julien P
The problem I see with implementing this kind of functionality in Core is
that it relies heavily on convention; PSR-0 is specifically a configuration
of the core autoloader which allows any configuration, as it should. And
while most of the community has adopted PSR-0 (as have I), I do not think
Co
Hi
The only regression can be where autoloaders are defined, and people are
> relying on the legacy undefined constant behavior (which triggers an
> E_NOTICE).
>
that makes me think about this code :
What autoload should be triggered?
"foo\bar" or "bar"?
Both are valid isn't it?
Should auto
All,
I have updated the RFC to include 2 new benchmarks.
For normal class loading, this proposal shows at worst no change to loading
time. At best, it may actually improve it because at least one
zend_function_call is avoided (to spl_autoload_call).
For constants and function calls, the benchmar
Stas,
On Fri, Aug 30, 2013 at 12:57 AM, Stas Malyshev wrote:
> Hi!
>
> > I have created a new draft RFC implementing function and constant
> > autoloading in master:
> >
> > https://wiki.php.net/rfc/function_autoloading
> >
> > All feedback is welcome.
>
> I think it is an unnecessary complicati
Stas,
Moreover, since this replaces a simple hash lookup with additional two
> function calls (and also other operations included in those) everywhere
> in the engine, it will also have performance impact of one of the most
> frequently used operations in the engine - function calls - while
> prov
hi,
On Fri, Aug 30, 2013 at 12:44 PM, Terry Ellison wrote:
> Yes I understand that, but the code processes the elements in this dirname,
> basename, filename, extension order so the two statements are equivalent in
> implementation.
>
> I am an experienced developer but a newbie-ish to the PHP d
On 30/08/13 10:43, Julien Pauli wrote:
On Fri, Aug 30, 2013 at 2:30 AM, Terry Ellison
mailto:ellison.te...@gmail.com>> wrote:
There's another one in string.c, in PHP_FUNCTION(pathinfo), that
could be applied as well, though there's little performance gain
in avoiding the copy of a
On Fri, Aug 30, 2013 at 11:46 AM, Johannes Schlüter
wrote:
> On Fri, 2013-08-30 at 10:49 +0200, Julien Pauli wrote:
>> Just to say : one benefit of this work would be to finally have autoload
>> functionnality (which is a Core feature IMO) included in Zend/ and no more
>> in an extension.
>
> What
On Fri, 2013-08-30 at 10:49 +0200, Julien Pauli wrote:
> Just to say : one benefit of this work would be to finally have autoload
> functionnality (which is a Core feature IMO) included in Zend/ and no more
> in an extension.
What is the benefit, except having more stuff in the engine? SPL is part
On Fri, Aug 30, 2013 at 2:30 AM, Terry Ellison wrote:
> On 27/08/13 10:40, Nikita Popov wrote:
>
>> On Sat, Aug 3, 2013 at 8:16 PM, Nikita Popov
>> wrote:
>>
>> Hi internals!
>>>
>>> Is there any particular reason why we only pass return_value_ptr to
>>> internal functions if they have the ACC_R
On Fri, Aug 30, 2013 at 6:57 AM, Stas Malyshev wrote:
> I think it is an unnecessary complication. Classes fit autoloader
> paradigm nicely, since the usual pattern is one class per one file
> (actually recommended in PSR), so it is easy to establish one-to-one
> automatic mapping between classes
Le 30/08/2013 10:56, Jordi Boggiano a écrit :
> I think it'd be best to resolve this in PHP because otherwise it means
> Debian (& Fedora?) users will have the bad surprise of a quirky
Debian, Fedora, Mageia, Mandriva, Ubuntu, etc.
> implementation when deploying to prod, and I can imagine the
>
On Fri, Aug 30, 2013 at 10:56 AM, Jordi Boggiano wrote:
> On 29.08.2013 09:52, Zeev Suraski wrote:
> > I have to say that I'm not wildly enthusiastic about making this change
> over
> > what appears to be a fairly minor comment in the license, and without
> even
> > going into the discussion as t
On 29.08.2013 09:52, Zeev Suraski wrote:
> I have to say that I'm not wildly enthusiastic about making this change over
> what appears to be a fairly minor comment in the license, and without even
> going into the discussion as to why we want to promote Evil :)
>
> The main concerns I have are:
>
> Link:
> http://git.php.net/?p=php-src.git;a=commitdiff;h=6fab1caa4100cf05fcf485ef0917830ae9f57563
What do you think to add the -fsanitize=address option (if available)
for the debug build ?
Note, this will make build / test slower.
Remi.
--
PHP Internals - PHP Runtime Development M
On Fri, Aug 30, 2013 at 3:23 AM, Anthony Ferrara wrote:
> All,
>
> I have created a new draft RFC implementing function and constant
> autoloading in master:
>
> https://wiki.php.net/rfc/function_autoloading
>
> All feedback is welcome.
>
Just to say : one benefit of this work would be to finally
Am 30.08.2013 10:42, schrieb Julien Pauli:
> Perhaps is it also time to talk about this subject back and finally all
> agree on a default recommanded implentation of autoloading in PHP
> (internally supported) ?
The only autoloader implementation that makes sense to me is to use a
tool such as h
On Fri, Aug 30, 2013 at 9:35 AM, Sebastian Bergmann wrote:
> Am 30.08.2013 03:23, schrieb Anthony Ferrara:
> > All feedback is welcome.
>
> Can we please get rid off the __autoload() function first before we
> consider adding new functionality?
>
Huge +1 to start deprecating this feature, then
Am 30.08.2013 03:23, schrieb Anthony Ferrara:
> All feedback is welcome.
Can we please get rid off the __autoload() function first before we
consider adding new functionality?
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/
2013/8/30 Stas Malyshev
> Hi!
>
> > I have created a new draft RFC implementing function and constant
> > autoloading in master:
> >
> > https://wiki.php.net/rfc/function_autoloading
> >
> > All feedback is welcome.
>
> I think it is an unnecessary complication. Classes fit autoloader
> paradigm
2013/8/30 Stas Malyshev
> Hi!
>
> > I disagree on the basis that namespaced functions/constants *do* fit the
> > same autoloading paradigm.
>
> If they're already namespaced, what prevents one to put it in a class
> and use good old PSR-compatible loading?
>
Well, static methods aren't the same
> If they're already namespaced, what prevents one to put it in a class
> and use good old PSR-compatible loading?
>
> Nothing, really... Just countering your specific premise.
> > Those function calls would only kick in if the function/constant wasn't
> > already defined, which will be the excep
Hi!
> I disagree on the basis that namespaced functions/constants *do* fit the
> same autoloading paradigm.
If they're already namespaced, what prevents one to put it in a class
and use good old PSR-compatible loading?
> Those function calls would only kick in if the function/constant wasn't
> a
76 matches
Mail list logo
