On Dec 24, 2014 2:38 PM, "Stanislav Malyshev" wrote:
>
> Hi!
>
> > But: return 0 and return FAILURE... which is simpler?
>
> It's equally simple to write, but FAILURE of course is way simpler to
> understand when read.
I totally agree.
I do not care much about the value of failure or success bu
Hi!
> But: return 0 and return FAILURE... which is simpler?
It's equally simple to write, but FAILURE of course is way simpler to
understand when read.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub
On Dec 24, 2014 3:17 AM, "Andrea Faulds" wrote:
>
>
> > On 23 Dec 2014, at 20:12, Yasuo Ohgaki wrote:
> >
> > Hi,
> >
> > On Wed, Dec 24, 2014 at 4:51 AM, Pierre Joye
wrote:
> >
> >> This issue has been reported earlier on secur...@php.net and is being
> >> discussed and analyzed. It is not a si
Hey:
thanks, that is the first thought of mine too.
On Wed, Dec 24, 2014 at 1:06 PM, Andrea Faulds wrote:
>
>> On 24 Dec 2014, at 03:25, Xinchen Hui wrote:
>>
>> Hey:
>>
>> We use SUCCESS/FAILURE as return value in some APIs, but use
>> 0/1(false/true) in others.
>>
>> I'd like to remove
> On 24 Dec 2014, at 03:25, Xinchen Hui wrote:
>
> Hey:
>
> We use SUCCESS/FAILURE as return value in some APIs, but use
> 0/1(false/true) in others.
>
> I'd like to remove SUCCESS/FAILURE at all, use 0/1 instead..
>
> what do you think?
>
> thanks
Hi,
Honestly, I don’t think SUCCES
Hi,
http://php.net/ChangeLog-5.php#5.4.36
does not mention CVE-2014-8142.
Fixed bug #68594 (Use after free vulnerability in unserialize()).
should be
Fixed bug #68594 (Use after free vulnerability in
unserialize())(CVE-2014-8142).
like 5.5/5.4's changelog.
Regards,
--
Yasuo Ohgaki
yohg...@ohgak
> On Dec 24, 2014, at 12:55 PM, Xinchen Hui wrote:
>
> Hey
>
>
>> On Dec 24, 2014, at 12:49 PM, Stanislav Malyshev wrote:
>>
>> Hi!
>>
>>> Hey:
>>>
>>> We use SUCCESS/FAILURE as return value in some APIs, but use
>>> 0/1(false/true) in others.
>>>
>>> I'd like to remove SUCCESS/FAILU
Hi!
> I think if(func()) is better, more readeable than if(func() == success)
Not really, especially given the fact that for major part of libc
if(func()) means checking for error, not for success, as success value is 0.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Deve
Hey
> On Dec 24, 2014, at 12:49 PM, Stanislav Malyshev wrote:
>
> Hi!
>
>> Hey:
>>
>> We use SUCCESS/FAILURE as return value in some APIs, but use
>> 0/1(false/true) in others.
>>
>> I'd like to remove SUCCESS/FAILURE at all, use 0/1 instead..
>>
>> what do you think?
>
> I think it
Hi!
> Hey:
>
>We use SUCCESS/FAILURE as return value in some APIs, but use
> 0/1(false/true) in others.
>
>I'd like to remove SUCCESS/FAILURE at all, use 0/1 instead..
>
>what do you think?
I think it would make reading code harder. Why do it - is there any
benefit in it? SUCCESS/
Hey:
We use SUCCESS/FAILURE as return value in some APIs, but use
0/1(false/true) in others.
I'd like to remove SUCCESS/FAILURE at all, use 0/1 instead..
what do you think?
thanks
--
Xinchen Hui
@Laruence
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing
On Tue, Dec 23, 2014 at 9:12 PM, Yasuo Ohgaki wrote:
> Hi,
>
> On Wed, Dec 24, 2014 at 4:51 AM, Pierre Joye wrote:
>
> > This issue has been reported earlier on secur...@php.net and is being
> > discussed and analyzed. It is not a simple task.
> >
>
> If we are not going to use other hash (i.e.
Hi!
> By this I mean I have looked at implementing it a couple of different ways
> and each time I get caught up on timing code that spans multiple lines such
> as:
>
> $array = array(
> 'my_key' => 'my_value',
> );
I would ignore that if I were you and use whatever lines the engine
assigns
>
> 1. If you want precision, it would slow down your code a lot, as
> basically you need to record timing of each opcode, which can be very
> expensive.
I'm not too concerned about the cost as this would only be running locally
and the for the purpose of profiling. The proviso with this would be
On Tue, Dec 23, 2014 at 10:28 PM, Jacob Bednarz
wrote:
> Hey,
> I have been working on some profiling of an application recently and
> whilst xhprof and xdebug are good to get an overall picture to further
> break into, I haven’t been able to find a tool for line by line profiling
> in PHP for a
Hi!
> The questions I have are: - Is this even possible?
Yes, should be possible but:
1. If you want precision, it would slow down your code a lot, as
basically you need to record timing of each opcode, which can be very
expensive.
2. If you're ok with less precision, you can do sampling, but in
Hey,
I have been working on some profiling of an application recently and whilst
xhprof and xdebug are good to get an overall picture to further break into, I
haven’t been able to find a tool for line by line profiling in PHP for a
particular file. I have done a bit of research and found rblinep
Not all json_decode()s will operate on user-supplied data. Why not add a
DoS-resistant variant?
I propose the addition of json_safe_decode() to use a randomized hash.
I'm not trolling about the bin2hex() -> ts_bin2hex() when I say this. Well,
not entirely.
On Tue, Dec 23, 2014 at 3:16 PM, Andrea
> On 23 Dec 2014, at 20:12, Yasuo Ohgaki wrote:
>
> Hi,
>
> On Wed, Dec 24, 2014 at 4:51 AM, Pierre Joye wrote:
>
>> This issue has been reported earlier on secur...@php.net and is being
>> discussed and analyzed. It is not a simple task.
>>
>
> If we are not going to use other hash (i.e. h
Hi,
On Wed, Dec 24, 2014 at 4:51 AM, Pierre Joye wrote:
> This issue has been reported earlier on secur...@php.net and is being
> discussed and analyzed. It is not a simple task.
>
If we are not going to use other hash (i.e. half MD4 like other langs), how
about
add max allowed collisions? It w
This issue has been reported earlier on secur...@php.net and is being
discussed and analyzed. It is not a simple task.
I have to thank the reporter to have it done the right way.
Maybe Lukas can learn from them for his next report.
Cheers,
Pierre
On Dec 23, 2014 11:20 PM, "Scott Arciszewski" wr
> -Ursprüngliche Nachricht-
> Von: Stanislav Malyshev [mailto:smalys...@gmail.com]
> Gesendet: Dienstag, 23. Dezember 2014 19:34
> An: Robert Stoll; 'Leigh'; guilhermebla...@gmail.com
> Cc: 'PHP internals'
> Betreff: Re: AW: [PHP-DEV] [RFC] Package private class
>
> Hi!
>
> >
> > namespa
Hi!
>
> namespace ch.tutteli.foo{ public for ch.tutteli.bar, ch.tsphp*
> private class Foo{} }
This looks like a recipe for totally unmaintainable situation, where
each class has its own list of places where it is visible, and the lists
are different for each class. I can kind of get when the p
http://lukasmartinelli.ch/web/2014/11/17/php-dos-attack-revisited.html
Sigh
> De : Pierre Joye [mailto:pierre@gmail.com]
> Anyone dying while waiting to see PHP having case sensitive symbols
> handling should go ahead with a RFC. He will also have to deal with
> file ops while being at it. Should they remain case insensitive? Do
> manual checks to match the path actua
Hi Robert,
Answers inline.
On Tue, Dec 23, 2014 at 7:59 AM, Robert Stoll wrote:
>
>
> > -Ursprüngliche Nachricht-
> > Von: Leigh [mailto:lei...@gmail.com]
> > Gesendet: Dienstag, 23. Dezember 2014 04:34
> > An: guilhermebla...@gmail.com
> > Cc: PHP internals
> > Betreff: Re: [PHP-DEV] [
> -Ursprüngliche Nachricht-
> Von: Leigh [mailto:lei...@gmail.com]
> Gesendet: Dienstag, 23. Dezember 2014 04:34
> An: guilhermebla...@gmail.com
> Cc: PHP internals
> Betreff: Re: [PHP-DEV] [RFC] Package private class
>
> On 23 December 2014 at 00:32, guilhermebla...@gmail.com
> wrote:
On Tue, Dec 23, 2014 at 9:00 AM, Maxime Veber wrote:
> Even if i'm a php developer since a while, i never new or see usage of the
> case-insensitive "feature". IMO that's something a bit terrible and people
> do not use it but make mistakes that PHP "automatically fix". This behavior
> is very wei
Even if i'm a php developer since a while, i never new or see usage of the
case-insensitive "feature". IMO that's something a bit terrible and people
do not use it but *make mistakes* that PHP "automatically fix". This
behavior is very weird and comes with bad code quality.
Of course this is a BCB
29 matches
Mail list logo
