Hi,
I'm Noah Overcash, and want to help the PHP community. I've been actively
using PHP in most of my projects for some time now, and thought it was time for
me to help the language itself rather than just having the language help me.
-Noah Overcash
(803) 238-0451
smileytech...@smileytechguy.co
On Mon, Nov 7, 2016 at 1:38 PM Fleshgrinder wrote:
> Hey guys! :)
The first one should definitely be an error since it makes no sense.
Sense be damed ;-) . I'd attribute it to an identity of sorts (if it was to
go all out with comparison chaining). Yes it makes little sense, in
practice, but
On 11/7/2016 3:41 PM, Alice Wonder wrote:
> On 11/07/2016 04:29 AM, Nikita Nefedov wrote:
>> It might make even more sense to not provide a default here at all. As
>> history shows that those methods that are considered secure today can
>> become less-than-desirably secure in a couple of years. Whi
2016-11-06 20:22 GMT+01:00 Pedro Magalhães :
> Hi internals,
>
> I've created a PR (https://github.com/php/php-src/pull/2187) aiming at
> the removal of the binary string forward compatibility.
>
> Reproducing the description of the PR:
>
> In version 5.2.1, the b prefix and the (binary) cast
Results for project PHP master, build date 2016-11-07 06:25:01+02:00
commit: 80cb79f
previous commit:5aad73a
revision date: 2016-11-06 20:45:13+00:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
On 11/07/2016 04:29 AM, Nikita Nefedov wrote:
*snip*
Hey,
It might make even more sense to not provide a default here at all. As history
shows that those methods that are considered secure today can become
less-than-desirably secure in a couple of years. Which means the same cycle of
depr
Hi,
Joe Watkins wrote:
Afternoon Andrea,
A case can be made that the binary cast might at some point do
something: "(binary) $ustring"
There is no case whatever for the literal b prefix, it will *never*
have a function if we are not changing the default string representation.
I
Afternoon Andrea,
A case can be made that the binary cast might at some point do
something: "(binary) $ustring"
There is no case whatever for the literal b prefix, it will *never*
have a function if we are not changing the default string representation.
If we do adopt a literal prefi
> On 7 Nov 2016, at 03:35, Scott Arciszewski wrote:
>
>> On Sun, Nov 6, 2016 at 2:19 PM, Jakub Zelenka wrote:
>> Hi,
>>
>> On Thu, Nov 3, 2016 at 4:11 PM, Scott Arciszewski
>> wrote:
>>>
>>> Hi,
>>>
>>> Can we change openssl_public_encrypt() and openssl_private_decrypt() from
>>> defaultin
Hi,
Joe Watkins wrote:
Morning Andrea,
Who is widely deploying something that does absolutely nothing ?
PHAR uses (binary), or so Pedro's email says.
The only reason to keep it would be that we are going to change the
default representation, as pointed out we're not.
If we were
10 matches
Mail list logo