I messaged the list about this feature before I had the RFC written up
for it. The RFC[1] is slightly different from what I proposed in the
previous thread, so please read the RFC to make sure you understand
what is being proposed before replying here.
Here's a small example:
$y = 10;
$re
I screwed up sending this earlier. Sorry if you get this twice.
On 9/30/15 12:15 PM, Scott Arciszewski wrote:
> I think random_bytes() and random_int() are great; they provide a
> much-needed building block in PHP 7.0. However, I do worry a bit that
> the most common use for random_int() (generat
On 10/2/15 1:04 PM, Sara Golemon wrote:
On Fri, Oct 2, 2015 at 4:18 AM, Peter Cowburn
wrote:
a) change all other "invalid" escape sequences to be a parse error [that
would mean "\m" would raise a parse error!]
b) change \u{} to behave like any other escape sequence, by not raising a
parse err
Den 2015-10-02 kl. 18:50, skrev Sara Golemon:
On Mon, Sep 28, 2015 at 2:29 PM, Björn Larsson
wrote:
... or if someday in the future comparison operator
without type juggling is needed.
You just blew my mind. Trying to imagine where strict
greater-than-or-equal would be used, and more to the
I'm making slow progress on an updated version of AMFEXT. Most of the
encoding functionality is complete but I'm struggling a bit with the
decoding functions because I need to return zvals and other objects. In
particular, I'm getting some memory leak notifications and I'm also getting
some weird b
On Fri, Oct 2, 2015 at 6:53 AM, Bishop Bettini wrote:
> On Fri, Oct 2, 2015 at 4:18 AM, Peter Cowburn
> wrote:
>
>> a) change all other "invalid" escape sequences to be a parse error [that
>> would mean "\m" would raise a parse error!]
>>
>> b) change \u{} to behave like any other escape sequence
On Thu, Sep 24, 2015 at 12:10 AM, Stanislav Malyshev
wrote:
>> As a PHP developer, I agree with the possible confusion between `->` and
>> `~>`.
>> `==>` is a better choice IMHO, for its similarity with Hacklang syntax, as
>> said previously.
>
> I'm getting a feeling the RFC could be more success
On Mon, Sep 28, 2015 at 2:29 PM, Björn Larsson
wrote:
> ... or if someday in the future comparison operator
> without type juggling is needed.
>
You just blew my mind. Trying to imagine where strict
greater-than-or-equal would be used, and more to the point: What you'd
make strict grater than loo
Results for project php-src-nightly, build date 2015-10-02 05:13:25+03:00
commit: b302925b72fe6338473f516329fc47070ac5d9aa
revision_date: 2015-10-01 23:21:21+03:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping
2, LLC 45 MB
On Fri, Oct 2, 2015 at 4:18 AM, Peter Cowburn
wrote:
> a) change all other "invalid" escape sequences to be a parse error [that
> would mean "\m" would raise a parse error!]
>
> b) change \u{} to behave like any other escape sequence, by not raising a
> parse error and instead keeping the literal
On Fri, 02 Oct 2015 12:58:30 +0300, Andréas H.
wrote:
My login is : screamz
I would like to edit my profile, first at all.
Then Sometimes I would like to edit french translation that are not true,
(if I can ?)
Thanks
Best regards
2015-10-02 11:54 GMT+02:00 :
Hi Andréas Hanss!
Here is
My login is : screamz
I would like to edit my profile, first at all.
Then Sometimes I would like to edit french translation that are not true,
(if I can ?)
Thanks
Best regards
2015-10-02 11:54 GMT+02:00 :
> Hi Andréas Hanss!
>
> Here is your userdata for PHP Wiki at https://wiki.php.net/
>
>
While skim reading emails (just got back from holiday), I wanted to add...
On 23 Sep 2015, at 11:40, Rowan Collins wrote:
> A non-existent variable, however, is not something I've ever come across in a
> database context - it would seem to require a result set having rows with
> different num
Just to add to the white/black listing argument...
I would say that tainting is a whitelist approach, as everything is blocked by
default (seen as untainted), and you need to escape your variables depending on
the context they will be used in (or go out of your way to say it has already
been es
While skim reading emails (just got back from holiday), I wanted to add...
On 15 Sep 2015, at 17:23, Anthony Ferrara wrote:
> All,
>
> On Tue, Sep 15, 2015 at 11:15 AM, Arvids Godjuks
> wrote:
>> I fully support your effort to get this into the PHP to be part of core
>> extensions, or at leas
Happy Friday, internals!
Prior to PHP 7, any "invalid" escape sequences within strings (as far as I
can see) were ignored and the characters treated literally. For example:
"\xGG" ("broken" hex sequence) gives "\xGG", "\99" ("broken" octal
sequence) gives "\99", "\m" (not a recognised sequence at
Hello!
The PHP development team announces the immediate availability of PHP 5.5.30.
This is a security release. Two security-related issues in PHP were fixed
in this release. All PHP
5.5 users
are encouraged to upgrade to this version.
For source downloads of PHP 5.5.30 please visit our downloads
Hi,
On Thu, Oct 1, 2015 at 11:38 PM, Anatol Belski
wrote:
> Hi,
>
> > -Original Message-
> > From: Dmitry Stogov [mailto:dmi...@zend.com]
> > Sent: Thursday, October 1, 2015 12:20 PM
> > To: Matt Ficken
> > Cc: Pierre Joye ; Anatoliy Belsky ;
> > Laruence ; PHP Internals ;
> > dmi...@ph
18 matches
Mail list logo
