Am 20.06.2012 08:39, schrieb Pierre Joye:
hi Chris,
On Tue, Jun 19, 2012 at 11:45 PM, Christopher Jones
wrote:
We should take this offline - I can see cases where I'd strongly disagree.
I see no reason to move a discussion offline or off list, this is a
topic that interests many other read
On Thu, Jun 21, 2012 at 2:47 PM, Pierre Joye wrote:
> hi,
>
> On Thu, Jun 21, 2012 at 12:21 AM, Nikita Popov
> wrote:
>
>> We currently have a big mess concerning the behavior of json_encode()
>> with incorrectly encoded UTF-8 strings.
>>
>> To summarize the situation:
>>
>> PHP <= 5.3.13, PHP 5.
hi,
On Thu, Jun 21, 2012 at 12:21 AM, Nikita Popov
wrote:
> We currently have a big mess concerning the behavior of json_encode()
> with incorrectly encoded UTF-8 strings.
>
> To summarize the situation:
>
> PHP <= 5.3.13, PHP 5.4, master behave as follows when an invalid UTF-8
> string is encou
On Wed, Jun 20, 2012 at 8:51 PM, Laruence wrote:
> On Thu, Jun 21, 2012 at 11:39 AM, Yader Hernandez
> wrote:
> > I'm trying to reverse an array but I keep getting bizarre results, such
> as
> > seg faults
> >
> > 0x006d0940 in gc_remove_from_buffer (zv=0x7fffb550) at
> > /home/yader
On Thu, Jun 21, 2012 at 11:39 AM, Yader Hernandez
wrote:
> I'm trying to reverse an array but I keep getting bizarre results, such as
> seg faults
>
> 0x006d0940 in gc_remove_from_buffer (zv=0x7fffb550) at
> /home/yaderbh/php-5.4.3/Zend/zend_gc.h:189
> 189 root->next->prev = root->prev
I'm trying to reverse an array but I keep getting bizarre results, such as
seg faults
0x006d0940 in gc_remove_from_buffer (zv=0x7fffb550) at
/home/yaderbh/php-5.4.3/Zend/zend_gc.h:189
189 root->next->prev = root->prev;
or I'll get "PHP Fatal error: Allowed memory size of" errors when
> Resume is similar to return, but can only be used in catch blocks or
> in error handling functions. When encountered the run time returns to
> the line after the exception was initially thrown and, well,
> "resumes".
Interesting idea. Just by reading that I thought of this scenario instead:
--
Hi internals!
We currently have a big mess concerning the behavior of json_encode()
with incorrectly encoded UTF-8 strings.
To summarize the situation:
PHP <= 5.3.13, PHP 5.4, master behave as follows when an invalid UTF-8
string is encountered:
* The invalid string is replaced with "null", thu
Hi Nikita,
I've just tried to compile your generators branch on windows, the build is
broken there. This are the relevant messages before the compilation bails
out:
c:\php-sdk\phpmaster\vc9\x86\nikic\zend\zend_execute.c(1543) : error
C2065: 'tsrm_ls' : undeclared identifier
c:\php-sdk\phpmaster\v
On Mon Jun 18 07:14 PM, Anthony Ferrara wrote:
>
> https://wiki.php.net/rfc/hash_pbkdf2
>
I like this proposal, it could be useful to add a simpler api that has
defaults matching the NIST recommendation:
hash_password($password, $salt, $algo = 'sha1', $iterations = 1000);
if the salt doesn't h
I can't get this out of my head after two weeks, but some part of me
says this is a *really* bad idea. Of course another part of my brain
things its a great idea and I'm getting tired of the argument.
Resume is similar to return, but can only be used in catch blocks or
in error handling functions
Pierre,
On Jun 20, 2012 8:27 AM, "Pierre Joye" wrote:
>
> hi Anthony!
>
> On Wed, Jun 20, 2012 at 12:12 PM, Anthony Ferrara
wrote:
>
> >> I would update the RFC with the current available algorithms or
> >> recommended to be used (depending on the usage or goal).
> >
> > When you say "currently
hi Anthony!
On Wed, Jun 20, 2012 at 12:12 PM, Anthony Ferrara wrote:
>> I would update the RFC with the current available algorithms or
>> recommended to be used (depending on the usage or goal).
>
> When you say "currently available algorithms", are you talking about
> the hash library as a who
Pierre,
> Very nice work! Thanks :)
Thanks!
> I would update the RFC with the current available algorithms or
> recommended to be used (depending on the usage or goal).
When you say "currently available algorithms", are you talking about
the hash library as a whole? Or recommended for use with
Angel,
> I don't think the code is the most appropiate one, but I suppose that's
> not a final proposal.
Correct, it was just to fill out the interface a bit so that people
could play with it and see how the interface worked...
> The interfaces look good to me.
> I'd maybe set the default $algo
Hi Anthony,
i think your RFC is very good!
I like the idea to have PBKDF2 implementation that is able to act, at
the same time, as secure hash value generator (without the length
parameter) and as key derivation function (with the length parameter).
I think we should be consistent with the API of
16 matches
Mail list logo
