Re: [PHP-DEV] Re: Re: OpenSSL bug in 5.4.33 and 5.5.17
> FYI: I've tagged 5.6.1 and I had to revert the following commits for this: > 372844918a318ad712e16f9ec636682424a65403 > f86b2193a483f56b0bd056570a0cdb57ebe66e2f > 30a73658c63a91c413305a4c4d49882fda4dab3e > 84a4041ba47e92e7a0ba03938d0ebf88b5fcf6cf > 98e67add15a6b889efe152c23ed15a61f022a63a > > 98e67add15a6b889efe152c23ed15a61f022a63a and 30a73658c63a91c413305a4c4d49882fda4dab3e were merge commits with conflict resolution > > Could you review that the current status of ext/openssl/xp_ssl.c is proper in the tag? > Thanks! > > -- > Ferenc Kovács Please also revert the following commit or we will still have problems: 6569db88081562f68a4f79e52cba83482bdf05fc Other than this commit everything else looks good. I *have* verified a new patch with the horde folks as solving the problem. However, I'm travelling for the next week (starting in a couple of hours) and I don't want to rush a (potentially) half-baked fix into the next 5.4 and 5.5 releases without comprehensive testing. If tags must be created before the end of next week then the best course of action is to revert these same commits for 5.4/5.5. I will be able to respond to any correspondence if you have questions in the coming days. Otherwise, I'll resolve this once and for all when I'm back in the office. Regards, Dan
Re: [PHP-DEV] Invokation on __toString() for object used as array key
Am 24.09.2014 22:01 schrieb "Andrea Faulds" : > > Now, if we were to add actual object key support, that I might like. But if we’re going to keep with just integers and strings, I’d much prefer to just support __toString here. I think users are smart enough to understand that PHP arrays only have string or int keys, so it casts to a string. Once you do that - automatically use __toString on objects used as keys, the way to full object key support in the future, is completely blocked, because BC. I'd much more like to see full object key support, with spl_object_hash or a magic __hash() method only used to determine hash slot position internally. best regards Patrick
Re: [PHP-DEV] [RFC] ZPP Failure On Overflow
> On 25 Sep 2014, at 02:17, Stas Malyshev wrote: > > Hi! > >> So, the problem comes with built-in functions, which have some side >> effect, which can be usefully run with a bogus value for an integer >> argument. In contrast, any function which has some side effect which is >> actively harmful given a bogus value would be a beneficiary of the change. > > No bogus value ever gets to a function - it always gets INT_MAX on > overflow. If INT_MAX is harmful for this function, this change does not > help as you could still pass INT_MAX and this change would not do anything. > > The thing is relying on this would not really improve your code - it is > very rare that INT_MAX+1 is harmful for your function but INT_MAX-1 is > not. But it may be useful to know that you can pass any value and it > will be capped at INT_MAX. No it won't. Normally it truncates (module), only some functions cap. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] ZPP Failure On Overflow
Hi! > So, the problem comes with built-in functions, which have some side > effect, which can be usefully run with a bogus value for an integer > argument. In contrast, any function which has some side effect which is > actively harmful given a bogus value would be a beneficiary of the change. No bogus value ever gets to a function - it always gets INT_MAX on overflow. If INT_MAX is harmful for this function, this change does not help as you could still pass INT_MAX and this change would not do anything. The thing is relying on this would not really improve your code - it is very rare that INT_MAX+1 is harmful for your function but INT_MAX-1 is not. But it may be useful to know that you can pass any value and it will be capped at INT_MAX. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] ZPP Failure On Overflow
On 24/09/2014 18:40, Stas Malyshev wrote:
That said, most cases of "garbage in, garbage out" would presumably
remain so, since most ZPP failures result in a return of NULL or
FALSE, which would probably end up cast back to the expected type
(int(0), string(''), etc) by the surrounding code.
Right. It’s not an E_RECOVERABLE_ERROR, you’d just get an E_WARNING.
No, you'd get E_WARNING *and* function would not run. Where before it
did run. That is the problem, not the warning - you add more cases where
the function does not run when it did before, and that can have profound
consequences on the code that depends on it.
So, the problem comes with built-in functions, which have some side
effect, which can be usefully run with a bogus value for an integer
argument. In contrast, any function which has some side effect which is
actively harmful given a bogus value would be a beneficiary of the change.
A function with no side effects will simply go from "garbage in, garbage
out" to "garbage in, NULL out".
I wonder how many functions actually fall into each category.
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Little switch improvement: get the used variable
On 24/09/2014 22:33, Andrea Faulds wrote:
On 24 Sep 2014, at 22:17, Rowan Collins wrote:
Perhaps rather than a magic function or constant, though, the switch statement could be
extended with an "as" argument, which would store the evaluated expression into
a normal variable, allowing nesting, and easier optimisation of the engine where the
feature isn't used. Thus you could write this:
switch( some_expression() as $switch_value ){
case 1:
do_something();
break;
//...
default:
throw new Exception('Undefined input: ' . $switch_value);
break;
}
Incredibly, some brave soul has gone back in time and already implemented this,
when none of us was looking!
switch($switch_value = some_expression()) {
...
}
Heh, now I feel like a fool for not thinking of that.
Treating assigments as expressions just isn't something that jumps to
mind, I guess!
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Little switch improvement: get the used variable
On 24 Sep 2014, at 22:17, Rowan Collins wrote:
> Perhaps rather than a magic function or constant, though, the switch
> statement could be extended with an "as" argument, which would store the
> evaluated expression into a normal variable, allowing nesting, and easier
> optimisation of the engine where the feature isn't used. Thus you could write
> this:
>
> switch( some_expression() as $switch_value ){
> case 1:
>do_something();
> break;
> //...
> default:
>throw new Exception('Undefined input: ' . $switch_value);
>break;
> }
Incredibly, some brave soul has gone back in time and already implemented this,
when none of us was looking!
switch($switch_value = some_expression()) {
...
}
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Little switch improvement: get the used variable
You can already do:
$a = 1;
$b = 2;
switch( $switch_value = $a + $b ) {
default:
print $switch_value;
}
No magic or new operator required
-- S.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 24 Sep 2014, at 21:46, Johannes Schlüter wrote: > I don't think there is a clear leader on usage of __toString(), for some > it is a debugging feature, for some a "normal" operation. If people want debugging, there is a method specifically for that, __debugInfo. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Little switch improvement: get the used variable
On 23/09/2014 08:29, Sanford Whiteman wrote:
>> The `get_the_used_switch_variable()` is just a placeholder, name can be
>> changed to something natural...maybe a constant.
>
> I feel this has diminished utility once you consider that the "switch
> variable" is actually an expression and could well include multiple
> $variables. Plus there's also the pattern switch(true) { } where the
> interesting variables appear in case statements. Hard for me to see
> the justification, but maybe I'm missing it. My $0.02...
Surely that makes it *more* useful - the switch statement never contains
"multiple variables", it contains a single expression, the exact value
of which is not discoverable to the programmer. A key property of switch
statements is that the expression is evaluated only once, so the engine
is already storing this value, it just needs to be put somewhere accessible.
Perhaps rather than a magic function or constant, though, the switch
statement could be extended with an "as" argument, which would store the
evaluated expression into a normal variable, allowing nesting, and
easier optimisation of the engine where the feature isn't used. Thus you
could write this:
switch( some_expression() as $switch_value ){
case 1:
do_something();
break;
//...
default:
throw new Exception('Undefined input: ' . $switch_value);
break;
}
Which would be shorthand for:
$switch_value = some_expression();
switch( $switch_value ){
...
As it happens, I've been pondering my own proposed extension to
switch(), after some of the discussion that came up from the
standardisation.
Currently, switch always uses a "loose" comparison (==), so cannot
distinguish between "case 3" and "case 3.0". Occasionally, it would be
nice to switch on a strict comparison (===); but then I thought, why
stop there? What if you could use switch with any comparison operator?
My idea is to give the switch() statement an optional "use" clause
(since that's an existing keyword) containing a single comparison
operator, like so:
switch ( $number ) use ( === ) {
case 3:
// ...
break;
case 3.0:
// No longer unreachable! :)
break;
}
But also:
switch ( $age ) use ( < ) {
case 2:
$type = 'infant';
break;
case 18:
$type = 'child';
break;
default:
$type = 'adult';
}
This would work well in combination with the "as" keyword:
switch ( calculate_age($birth_date, $departure_date) as
$age_at_departure ) use ( < ) {
case 2:
$type = 'infant';
$infants++;
break;
case 18:
$type = 'child';
$child_ages[] = $age_at_departure;
break;
default:
$type = 'adult';
$adults++;
}
As well as comparison operators, instanceOf might also be useful:
switch ( $product ) use ( instanceOf ) {
case ProductInterfaces\Flight:
// ...
break;
case ProductInterfaces\Accomm:
// ...
break;
default:
// ...
}
Bitwise operators might be interesting too, but then you're into more
complex implementation, because you've got to evaluate the operator and
cast the result to boolean before evaluating the case. So the
restriction should probably be "any binary operator which evaluates to a
boolean result".
Thoughts?
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On Wed, 2014-09-24 at 20:45 +0100, Andrea Faulds wrote:
> On 24 Sep 2014, at 13:24, Johannes Schlüter wrote:
>
> > Taking this sample code:::
> >
> > > class C {
> >function __toString() {
> >return "C";
> >}
> > }
> >
> > $a = [];
> >
> > $c1 = new C();
> > $c2 = new C();
> >
> > $a[$c1] = 23;
> > $a[$c2] = 42;
> > ?>
> >
> > There the assumption would be that this leads to an array $a with two
> > elements, where in fact there is only one if __toString() is being
> > called. The only thing "making sense" would be using using the objects
> > identity (i.e. via spl_object_hash()) everything else leads to issues.
>
> I’m not sure this is a fair example. Don’t classes usually implement a
> `__toString()` that is based on the data they contain? If they don’t,
> I’m not sure they’re useful for indexing anyway.
"Usually" is a bad term - we have no idea what >99% of our suers do ;)
I don't think there is a clear leader on usage of __toString(), for some
it is a debugging feature, for some a "normal" operation.
The interesting question are value objects
We can define we're using object identity as I did above or we add a
__hash() method, which again is more magic.
Last time this was discussed the magic didn't win and therefore having
objects as keys is forbidden so the user has to decide on
hashing/identifying himself in an explicit way.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 24 Sep 2014, at 21:08, Stas Malyshev wrote:
> The hash doesn't have to be a nonsensical hex value, it can be something
> like "My Object Number 42" if you want to. The difference is that
> __toString is for human reading, and it's not always suitable for
> hashing purposes. Just read the docs on any of the languages that have
> separate hash method - they all have the same argument, there's a
> different between printing an object for output and using the object as
> a key.
Actually, yeah, I see your point. I suggest this, then:
public function __toKey() : int | string {}
Psuedo-code, since you can’t have multiple return types. I think it’s a better
name than __hash (fits well with __toString IMO), and this way we can support
integer keys too, where that makes sense.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
Hi!
> I’m not sure that’d make much sense. The object isn’t the key, the
> value the magic method returns is. It would be quite odd to do this:
>
> $someArray = [$my__hashImplementingObject => 1];
> var_dump($someArray);
>
> And see something like this, because we’ve called a hash function:
>
> array(1) { ["ec10e5a66e281d105f302cacfb1aaca8"]=> int(0) }
The hash doesn't have to be a nonsensical hex value, it can be something
like "My Object Number 42" if you want to. The difference is that
__toString is for human reading, and it's not always suitable for
hashing purposes. Just read the docs on any of the languages that have
separate hash method - they all have the same argument, there's a
different between printing an object for output and using the object as
a key.
> I don’t really see what advantage this has over the normal
> __toString. Furthermore, having a special method we use to cast here
> that’s used nowhere else seems weird.
That's the point - it's not a cast. It's an operation that requires
object's identity. Again, given that so many languages have it, I don't
think it's really that weird. I think it's pretty natural.
> Now, if we were to add actual object key support, that I might like.
> But if we’re going to keep with just integers and strings, I’d much
> prefer to just support __toString here. I think users are smart
> enough to understand that PHP arrays only have string or int keys, so
> it casts to a string.
The problem is you mix here two completely different domains. On one
hand, you may want the object to have text representation for output
purposes - say, XML object would have XML output as it's string rep. On
other hand, I don't think you want to use 100K XML as a key, because
using as a key is a completely different issue. Converting to string is
a hack that mixes two different problems into one method, and that's why
it will lead to problems. The solution for this problem is known and
widely used - have a separate hash method. With PHP, you can actually
have a luxury of using a human-readable keys while still keeping them
nice and clean and independent from string representation. And if you
want maximum efficiency, you could switch to ints instead.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 24 Sep 2014, at 20:56, Stas Malyshev wrote:
>> There the assumption would be that this leads to an array $a with two
>> elements, where in fact there is only one if __toString() is being
>> called. The only thing "making sense" would be using using the objects
>> identity (i.e. via spl_object_hash()) everything else leads to issues.
>
> This is a valid concern. For this, Java, for example, has separate
> methods hashCode() and toString(). Python has __str__, __repr__ and
> __hash__. Ruby has object.hash. So maybe we should have another magic,
> something like __hash(), that would produce a value for key? Then
> objects that implement __hash would be hashable and those that don't
> won't be, while still having usable __toString.
I’m not sure that’d make much sense. The object isn’t the key, the value the
magic method returns is. It would be quite odd to do this:
$someArray = [$my__hashImplementingObject => 1];
var_dump($someArray);
And see something like this, because we’ve called a hash function:
array(1) {
["ec10e5a66e281d105f302cacfb1aaca8"]=>
int(0)
}
I don’t really see what advantage this has over the normal __toString.
Furthermore, having a special method we use to cast here that’s used nowhere
else seems weird.
Now, if we were to add actual object key support, that I might like. But if
we’re going to keep with just integers and strings, I’d much prefer to just
support __toString here. I think users are smart enough to understand that PHP
arrays only have string or int keys, so it casts to a string.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
Hi! > I already figured out how to solve the `is_resource()` issue. Create > an almost-useless, uninstantiatable class called Resource which any > new resource-replacing classes inherit from. Then, make > `is_resource()` check whether something is an instance of that > class. This is a nice idea, but maybe interface would be even better? > Of course, 3rd-party extensions are still a problem, but this should > mostly fix it. Of course, gettype() is still going to return “object” > not “resource”, but I suspect people are more likely to use > is_resource(). yeah, I don't think I've seen many examples of something like checking gettype() of fopen() return. I've definitely seen checking it for is_resource. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
Hi! > There the assumption would be that this leads to an array $a with two > elements, where in fact there is only one if __toString() is being > called. The only thing "making sense" would be using using the objects > identity (i.e. via spl_object_hash()) everything else leads to issues. This is a valid concern. For this, Java, for example, has separate methods hashCode() and toString(). Python has __str__, __repr__ and __hash__. Ruby has object.hash. So maybe we should have another magic, something like __hash(), that would produce a value for key? Then objects that implement __hash would be hashable and those that don't won't be, while still having usable __toString. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 24 Sep 2014, at 13:24, Johannes Schlüter wrote:
> Taking this sample code:::
>
> class C {
>function __toString() {
>return "C";
>}
> }
>
> $a = [];
>
> $c1 = new C();
> $c2 = new C();
>
> $a[$c1] = 23;
> $a[$c2] = 42;
> ?>
>
> There the assumption would be that this leads to an array $a with two
> elements, where in fact there is only one if __toString() is being
> called. The only thing "making sense" would be using using the objects
> identity (i.e. via spl_object_hash()) everything else leads to issues.
I’m not sure this is a fair example. Don’t classes usually implement a
`__toString()` that is based on the data they contain? If they don’t, I’m not
sure they’re useful for indexing anyway.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 24 Sep 2014, at 20:39, Stas Malyshev wrote: >> I also wonder why we still need them. Doing what has been done with gmp >> for all resources would be a good move for 7. > > In general, I think we do not - IIRC everything resources do objects can > do better now, and the problems that prevented one from using objects > instead of resources are long gone. > > However, is_resource() checks and lots of third-party extensions using > resources may be a bit of a problem for eliminating them. I already figured out how to solve the `is_resource()` issue. Create an almost-useless, uninstantiatable class called Resource which any new resource-replacing classes inherit from. Then, make `is_resource()` check whether something is an instance of that class. Of course, 3rd-party extensions are still a problem, but this should mostly fix it. Of course, gettype() is still going to return “object” not “resource”, but I suspect people are more likely to use is_resource(). -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
Hi! > I also wonder why we still need them. Doing what has been done with gmp > for all resources would be a good move for 7. In general, I think we do not - IIRC everything resources do objects can do better now, and the problems that prevented one from using objects instead of resources are long gone. However, is_resource() checks and lots of third-party extensions using resources may be a bit of a problem for eliminating them. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [VOTE] Remove alternative PHP tags
Hi internals! The vote for removal of alternative PHP opening/closing tags in PHP 7 is now open: https://wiki.php.net/rfc/remove_alternative_php_tags#vote Nikita
Re: [PHP-DEV] [RFC] ZPP Failure On Overflow
Hi!
>> That said, most cases of "garbage in, garbage out" would presumably
>> remain so, since most ZPP failures result in a return of NULL or
>> FALSE, which would probably end up cast back to the expected type
>> (int(0), string(''), etc) by the surrounding code.
>
> Right. It’s not an E_RECOVERABLE_ERROR, you’d just get an E_WARNING.
No, you'd get E_WARNING *and* function would not run. Where before it
did run. That is the problem, not the warning - you add more cases where
the function does not run when it did before, and that can have profound
consequences on the code that depends on it.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] ZPP Failure On Overflow
On 24 Sep 2014, at 16:04, Rowan Collins wrote:
> That said, most cases of "garbage in, garbage out" would presumably remain
> so, since most ZPP failures result in a return of NULL or FALSE, which would
> probably end up cast back to the expected type (int(0), string(''), etc) by
> the surrounding code.
Right. It’s not an E_RECOVERABLE_ERROR, you’d just get an E_WARNING.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] ZPP Failure On Overflow
Andrea Faulds wrote (on 24/09/2014):
Especially a BC break in a form of "it worked before but now it
>fails" - this can break code in so many hard to catch ways, where you
>didn't actually care at the least if the function truncates the arg
>(common situation in proxy/glue libraries, etc. - they'd be completely
>fine with garbage in - garbage out) but need special code to handle
>situations where the function fails to run altogether.
How do these libraries you speak of handle passing other types of arguments
that fail? Surely this isn’t a new phenomenon.
I think Stas's point was not that libraries don't need to think about
such things *in general*, but that the checking to handle *this
particular case* will not currently be in place, and might not be put in
place until someone is unfortunate enough to trigger the new behaviour.
That said, most cases of "garbage in, garbage out" would presumably
remain so, since most ZPP failures result in a return of NULL or FALSE,
which would probably end up cast back to the expected type (int(0),
string(''), etc) by the surrounding code.
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] ZPP Failure On Overflow
On 24 Sep 2014, at 01:22, Stas Malyshev wrote: > It would be nice to describe why this change is good. So far the > motivation is "it is unintuitive" which is a fancy way of saying "I > don't like it". Could you list which use cases this functionality > improves, which real-life bugs it could fix, etc.? Basically, it would mean we fail safe rather than silently mangling data in the unusual case where some large float is passed to a function expecting an integer. There are actually quite a few bugs caused by truncation. Among the tests I have to update, one is for a date/time bug caused by a floating-point timestamp being truncated on 32-bit platforms resulting in a completely different date. Should this RFC pass, in these situations you just get an error rather than having your data mangled. If you want it to continue mangling it, that’s fine, (int) exists. If you want to handle it better, that’s also an option. > If this is necessary for your BigInt RFC which would not work without it > for some reason (I have no idea if it is the case, but if it is) then > please state so explicitly and describe why. That may also help to find > alternatives in case somebody else sees any other solution that you may > have missed. It’s not completely necessary, but I think bigints would make more sense with this RFC than without it. This RFC would make floats out of bounds cause an error when passed to functions expecting integers. Naturally, if this passes, the bigint patch would then do the same thing for bigints passed to functions which only support platform-native longs (32-bit or 64-bit). I want this to error, because otherwise bigints would truncate like floats, and I think that’s likely to trip people up. While PHP’s integer type would now have arbitrary precision, for obvious reasons most internal functions don’t need to handle integers larger than 32-bit or 64-bit (e.g. for a bit mask argument, or a string length). I’d much prefer if trying to do, say, str_split(“foobar”, 2 ** 128); would error rather than simply truncate silently, especially since passing such a large value here is almost certainly an error. If we truncate silently, it may seem like nothing has gone wrong. After all, if a function runs normally, raises no errors, and does not return an error value, it is usually safe to assume that everything is working fine. > If there are some other arguments for it, please add them to the RFC. > Right now it looks kind of thin. I personally don't have any reason to > assume what you are proposing is better that what we have now, and BC > break is a cost that always must be offset by something that is worth > more. Especially a BC break in a form of "it worked before but now it > fails" - this can break code in so many hard to catch ways, where you > didn't actually care at the least if the function truncates the arg > (common situation in proxy/glue libraries, etc. - they'd be completely > fine with garbage in - garbage out) but need special code to handle > situations where the function fails to run altogether. How do these libraries you speak of handle passing other types of arguments that fail? Surely this isn’t a new phenomenon. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Re: OpenSSL bug in 5.4.33 and 5.5.17
On Wed, Sep 24, 2014 at 5:41 AM, Ferenc Kovacs wrote: > > > > On Tue, Sep 23, 2014 at 4:41 PM, Julien Pauli wrote: >> >> On Tue, Sep 23, 2014 at 3:24 PM, Ferenc Kovacs wrote: >> > >> > >> > On Tue, Sep 23, 2014 at 7:39 AM, Daniel Lowrey wrote: >> >> >> >> >> Hi, >> >> >> >> >> >> That's a bad thing we need to fix ASAP. >> >> >> >> >> >> I think for 5.6.1 we'll revert it , if not, we'll need an RC2, which >> >> >> is something we usually don't do (but as this could involve security, >> >> >> we may do it). >> >> >> The fix can be merged to 5.5.18RC1, next week, to have an RC cycle if >> >> >> not part of a 5.6.1RC2 (tag is tomorrow) >> >> >> >> >> >> 5.6 and 5.5 actually overlap in the release weeks. 5.6 is planned on >> >> >> odd weeks whereas 5.5 is on even weeks. >> >> >> >> >> >> Waiting for Ferenc's advice anyway. >> >> >> >> >> >> Julien.P >> >> > >> >> >I have no issues with reverting at this point as that's the best route to >> >> >get stable releases back on track. I thought I had fixed some really old >> >> >bugs with those commits but the medicine turned out to be worse than the >> >> >disease. My apologies again for letting those problems sneak into >> >> > releases >> >> >:/ >> >> >> >> I've got the necessary fixes lined up at this point, I just need to know >> >> how you guys would prefer to proceed on this. >> >> >> >> I can commit the relevant changes to 5.4, 5.5 and 5.6 and double-check >> >> with >> >> RMs to ensure they make it into this next set of releases or we can revert >> >> the previous commits and forget about the bug fixes altogether. >> >> >> >> Just let me know which you prefer. Thanks. >> > >> > >> > hi, >> > >> > I would prefer reverting the regression from 5.6.1, and I would be fine >> > having the proper fix later on, but I think it would be nice if we could >> > keep that off from the stable branches until we can validate (feedback from >> > the Horde guys would be nice but it would really help a ton if we could have >> > tests for both the original problem this was intended to fix and for the >> > regression introduced while doing so) that the patch is now proper (maybe >> > keeping it in a pull request in the meanwhile). >> > What do you think? >> >> For me its all right and safe. >> >> Next week we'll have 5.5.18RC1, which could contain the fix if it's >> been validated and want to go for an RC stage. >> >> Julien.P > > > FYI: I've tagged 5.6.1 and I had to revert the following commits for this: > 372844918a318ad712e16f9ec636682424a65403 > f86b2193a483f56b0bd056570a0cdb57ebe66e2f > 30a73658c63a91c413305a4c4d49882fda4dab3e > 84a4041ba47e92e7a0ba03938d0ebf88b5fcf6cf > 98e67add15a6b889efe152c23ed15a61f022a63a > > 98e67add15a6b889efe152c23ed15a61f022a63a and 30a73658c63a91c413305a4c4d49882fda4dab3e were merge commits with conflict resolution > > Could you review that the current status of ext/openssl/xp_ssl.c is proper in the tag? > Thanks! > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu I will review and report back on the 5.6.1 later today. I've checked with the horde folks and my recent uncommitted patch resolves any bugs (both old and new). I plan to commit this for 5.4 and 5.5 today and then subsequently merge these changes so they can appear in the next 5.6.2. Starting this evening I will be travelling for the next seven days -- I can communicate during this time but will likely be unable to write/submit any code.
Re: [PHP-DEV] VCS Account Request: leigh
On Wed, Sep 24, 2014 at 2:33 PM, Leigh wrote: > I currently have a patch awaiting review in the online editor. > > I have done a few in the past but am having trouble locating them. > > Found a small one: > http://svn.php.net/viewvc/?view=revision&revision=331339 > > I can safely say that while I don't necessarily love kittens, I accept > that they are a necessary part of the process. > > I've found some more: http://svn.php.net/viewvc?view=revision&revision=331381 http://svn.php.net/viewvc?view=revision&revision=327145 based on this, I think it is already ok to grant the phpdoc karma, keep up the good work! -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] VCS Account Request: leigh
I currently have a patch awaiting review in the online editor. I have done a few in the past but am having trouble locating them. Found a small one: http://svn.php.net/viewvc/?view=revision&revision=331339 I can safely say that while I don't necessarily love kittens, I accept that they are a necessary part of the process. On 24 September 2014 13:07, Ferenc Kovacs wrote: > > > On Sat, Sep 20, 2014 at 3:26 PM, Leigh T wrote: >> >> Over the past 3 years I have made several small code and documentation >> contributions to the project. >> >> I do *not* want php-src commit access. I want to submit all of my >> contributions via pull request and have them double checked for sanity. >> >> I currently have two RFCs under discussion and would like the ability to: >> * Vote on my and other peoples RFCs >> * Assign bugs to myself when I feel capable of fixing the issue >> * Maintain documentation (in English) related to any work I carry out >> >> Thanks, >> >> Leigh. >> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> > > Hi Leigh, > > Do you have any track record/previous contribution to the > documentation(either via edit.php.net or sending in patches)? > Usually we request a couple of patches before handing out karma, if you need > help (as our our documentation infrastructure can be a bit overwhelming at > first) check out http://doc.php.net/tutorial/ and if you have any question > just drop a mail to php...@lists.php.net or check out the #php.doc irc > channel on efnet. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
Hi, On Tue, 2014-09-23 at 10:04 +0200, Nicolai Scheer wrote: > until 5 minutes ago I thought it would be perfectly legal to use an object > as an array key, given that its __toString() method is in place. Taking this sample code::: There the assumption would be that this leads to an array $a with two elements, where in fact there is only one if __toString() is being called. The only thing "making sense" would be using using the objects identity (i.e. via spl_object_hash()) everything else leads to issues. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] VCS Account Request: leigh
On Sat, Sep 20, 2014 at 3:26 PM, Leigh T wrote: > Over the past 3 years I have made several small code and documentation > contributions to the project. > > I do *not* want php-src commit access. I want to submit all of my > contributions via pull request and have them double checked for sanity. > > I currently have two RFCs under discussion and would like the ability to: > * Vote on my and other peoples RFCs > * Assign bugs to myself when I feel capable of fixing the issue > * Maintain documentation (in English) related to any work I carry out > > Thanks, > > Leigh. > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Hi Leigh, Do you have any track record/previous contribution to the documentation(either via edit.php.net or sending in patches)? Usually we request a couple of patches before handing out karma, if you need help (as our our documentation infrastructure can be a bit overwhelming at first) check out http://doc.php.net/tutorial/ and if you have any question just drop a mail to php...@lists.php.net or check out the #php.doc irc channel on efnet. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] PHP 5.4.33 RC1 => mod_proxy_fcgi still broken
On Wed, Sep 24, 2014 at 10:12 AM, Remi Collet wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Le 24/09/2014 09:33, Ferenc Kovacs a écrit : > > > We could have used the same NEWS entry from 5.6 I suppose: . Fixed > > bug #67606 (revised fix 67541, broke mod_fastcgi BC). (David > > Zuelke) > > > > I fixed NEWS in 5.4 / 5.5 "before" the release (5.4.33 / 5.5.17) > > In 5.6, there is no entry for 65641 (but one for 67541...) > oops, sorry, you are right, I was just mixing up those numbers in my head. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Re: Re: OpenSSL bug in 5.4.33 and 5.5.17
On Tue, Sep 23, 2014 at 4:41 PM, Julien Pauli wrote: > On Tue, Sep 23, 2014 at 3:24 PM, Ferenc Kovacs wrote: > > > > > > On Tue, Sep 23, 2014 at 7:39 AM, Daniel Lowrey > wrote: > >> > >> >> Hi, > >> >> > >> >> That's a bad thing we need to fix ASAP. > >> >> > >> >> I think for 5.6.1 we'll revert it , if not, we'll need an RC2, which > >> >> is something we usually don't do (but as this could involve security, > >> >> we may do it). > >> >> The fix can be merged to 5.5.18RC1, next week, to have an RC cycle if > >> >> not part of a 5.6.1RC2 (tag is tomorrow) > >> >> > >> >> 5.6 and 5.5 actually overlap in the release weeks. 5.6 is planned on > >> >> odd weeks whereas 5.5 is on even weeks. > >> >> > >> >> Waiting for Ferenc's advice anyway. > >> >> > >> >> Julien.P > >> > > >> >I have no issues with reverting at this point as that's the best route > to > >> >get stable releases back on track. I thought I had fixed some really > old > >> >bugs with those commits but the medicine turned out to be worse than > the > >> >disease. My apologies again for letting those problems sneak into > >> > releases > >> >:/ > >> > >> I've got the necessary fixes lined up at this point, I just need to know > >> how you guys would prefer to proceed on this. > >> > >> I can commit the relevant changes to 5.4, 5.5 and 5.6 and double-check > >> with > >> RMs to ensure they make it into this next set of releases or we can > revert > >> the previous commits and forget about the bug fixes altogether. > >> > >> Just let me know which you prefer. Thanks. > > > > > > hi, > > > > I would prefer reverting the regression from 5.6.1, and I would be fine > > having the proper fix later on, but I think it would be nice if we could > > keep that off from the stable branches until we can validate (feedback > from > > the Horde guys would be nice but it would really help a ton if we could > have > > tests for both the original problem this was intended to fix and for the > > regression introduced while doing so) that the patch is now proper (maybe > > keeping it in a pull request in the meanwhile). > > What do you think? > > For me its all right and safe. > > Next week we'll have 5.5.18RC1, which could contain the fix if it's > been validated and want to go for an RC stage. > > Julien.P > FYI: I've tagged 5.6.1 and I had to revert the following commits for this: 372844918a318ad712e16f9ec636682424a65403 f86b2193a483f56b0bd056570a0cdb57ebe66e2f 30a73658c63a91c413305a4c4d49882fda4dab3e 84a4041ba47e92e7a0ba03938d0ebf88b5fcf6cf 98e67add15a6b889efe152c23ed15a61f022a63a 98e67add15a6b889efe152c23ed15a61f022a63a and 30a73658c63a91c413305a4c4d49882fda4dab3e were merge commits with conflict resolution Could you review that the current status of ext/openssl/xp_ssl.c is proper in the tag? Thanks! -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On Sep 24, 2014 10:19 AM, "Michael Wallner" wrote: > > On 24/09/14 08:30, Stas Malyshev wrote: > > Hi! > > > >> Well, then let's remove this restriction from resources, too. > > > > Not sure what use would it be for resources - resource IDs are not > > controlled by user code and for all intents and purposes are opaque > > numbers, which also do not have to be unique over the life of the > > script. What use would it be to index by those, especially by implicit > > convert? I don't think right now we have implicit convert of resources > > to ints anywhere, like we do have with __toString. > > > > There's currently no way to associate any data with a resource, except > by its ID. > > $context[(int) $resource] = ...; > > IIRC resources *were* implicitely converted to integers up until a > specific version, I'll have to look that up in history, though. > I also wonder why we still need them. Doing what has been done with gmp for all resources would be a good move for 7.
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 24/09/14 08:30, Stas Malyshev wrote: > Hi! > >> Well, then let's remove this restriction from resources, too. > > Not sure what use would it be for resources - resource IDs are not > controlled by user code and for all intents and purposes are opaque > numbers, which also do not have to be unique over the life of the > script. What use would it be to index by those, especially by implicit > convert? I don't think right now we have implicit convert of resources > to ints anywhere, like we do have with __toString. > There's currently no way to associate any data with a resource, except by its ID. $context[(int) $resource] = ...; IIRC resources *were* implicitely converted to integers up until a specific version, I'll have to look that up in history, though. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4.33 RC1 => mod_proxy_fcgi still broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 24/09/2014 09:33, Ferenc Kovacs a écrit : > We could have used the same NEWS entry from 5.6 I suppose: . Fixed > bug #67606 (revised fix 67541, broke mod_fastcgi BC). (David > Zuelke) > I fixed NEWS in 5.4 / 5.5 "before" the release (5.4.33 / 5.5.17) In 5.6, there is no entry for 65641 (but one for 67541...) 5.6.1 have no FPM changes 5.6.2 will have the fix for #65641 But perhaps I have miss something.. Yes... these fcgi issues are a mess.. (and some are still open, perhaps duplicates) Remi. -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlQifPsACgkQYUppBSnxahh8zwCfTRvoN7/NdzQycsaDxK5m+QWW FQwAoPThXlv8Jn9n+g2gpfwCm4h94NTT =/bGU -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4.33 RC1 => mod_proxy_fcgi still broken
On Mon, Sep 15, 2014 at 8:37 AM, Remi Collet wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Le 11/09/2014 09:19, Remi Collet a écrit : > > Le 11/09/2014 09:16, Remi Collet a écrit : > >> Le 09/09/2014 07:54, Stas Malyshev a écrit : The big issue I > >> see, is the news entry: > > > >> . Fixed #65641 (PHP-FPM incorrectly defines the SCRIPT_NAME > >> variable when using Apache). (David Zuelke) > > > > Should probably be: > > > > . Fixed #67606 (FPM with mod_fastcgi/apache2.4 is broken) > > I fixed the NEW entry in > > 5.4: 2775dc2b443fc8abc3ae0a659c3a8a800ab90035 > 5.5: 6dc6daf7e33524531e429ea0ac8b2ecfd9325122 > > Can you please cherry-pick this in 5.4.33 / 5.5.17 before the release ? > > > I plan to apply the patch for 65641 later in 5.5+ > so for 5.5.17, 5.6.2, as this one really need tests > and don't want to break anything else... > > > Remi > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlQWiUAACgkQYUppBSnxahiukACg6YuLevbuZQw7/LjWNCgmub+L > KzgAoOrZ8QUwjZZULKh68nCIxwQzgMOx > =UvXq > -END PGP SIGNATURE- > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > We could have used the same NEWS entry from 5.6 I suppose: . Fixed bug #67606 (revised fix 67541, broke mod_fastcgi BC). (David Zuelke) -- Ferenc Kovács @Tyr43l - http://tyrael.hu
