Re: [PHP-DEV] Q: ZEND_HANDLE_STREAM and wincache extension on PHP 5.4
hi, On Fri, Mar 16, 2012 at 7:49 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: It's best you send him an e-mail to dmi...@zend.com No, it is best to send a mail to internals and cc him. I was talking with Pierre yesterday, and there was some question about whether there was some distinction between streams that were created as a result of zend_compile_file versus just those files that were called by calling zend_stream_open_function. What would this distinction be and what would be the implication? See the wincache code please. This comment was only about the wincache implementation. Also it is only about knowing whether we are in RINIT or at runtime, as in, compile file being called from the SAPI or from require/includeco. I think the reason phar causes no problem is because CGI will not be opening phar:// files as a first script, which is all php_cgi!main() deals with. So phar's zend_stream_function will in this case end up falling back on the default implementation and cause no problem. Yes, see my reply earlier. In any case, it's true that default implementation of zend_stream_open_function (php_stream_open_for_zend_ex) does store a php_stream* in handle. However, this clearly isn't the general case (even it were, breaking the abstraction would already be dubious). This is definitely a bug. It is not necessary a bug but a breakage in the ABI, and not documented. I discussed it with Dmitry and it was not seen as a bug but as an optimization. The problem in wincache is somehow special due the file caching mechanism, which mix up both SAPI file open and runtime file open, which ends in the current issue. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Account Request: laltin
2012/3/16 Ángel González keis...@gmail.com On 16/03/12 18:45, Lütfi Altın wrote: I want to read PHP source and help PHP for further development. You don't need a svn account to read the php source. You can just download the source from http://php.net/downloads.php#v5 view the development version at http://svn.php.net/viewvc/php/php-src/trunk/ Or download through svn with svn checkout https://svn.php.net/repository/php/php-src/trunk/ You can then provide patches through the Bug Tracking System at https://bugs.php.net/ And only after having proved that you are a valuable contributor, would be appropiate to request svn access. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Hi, Lütfi If I got it right, the community decided to switch all projects to git soon (only php-src is missing: http://git.php.net/). They will also connect their repositories to github. After that it should be possible to forge the repository, change something and start a pull-request. This will then send an email to a group of people who will look through the changes and give you feedback. Please correct me if I got it wrong. Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Scalar-type-hinting - which way is the best to go?
Hi, all Today I read a post around that: http://nikic.github.com/2012/03/06/Scalar-type-hinting-is-harder-than-you-think As some of us are leading to the 3rd and some to the 4th or other ways described in here (I think we can simply exclude the first one ...) Would it be an option (to get this moved forward) to let people vote which way they like most (or which comes closest to their best-solution)? I pretty much like the 3rd way ... the only thing I see that has not been discussed enough is how to handle integers on 64bit and 32bit installations. Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar-type-hinting - which way is the best to go?
tl;dr: strict type hinting and Boxing based type hinting (the second one with some changes). Just read through it, and I was unaware there's still ideas to continue working on type hinting in PHP. That's good news, at least for me :) I'm just lurking around here, but if my thoughts can help, here they are. Here's a short mapping of considerations related to the various implementations exposed on that blog post: 1. Strict type hinting (also aliased by me YES please, yes!): - It enforces the developer to keep his code cleaner - It helps framework devs in reducing the overhead caused by casting within internal classes - Unsure devs can always call `foo((int) $bar);` if they are unsure of what their code produces. The loss of performance will be only because of crap code. - Documentation of return values will become somehow a must - Throwing exceptions, yes please... Unsure what level anyway... I like the E_CATCHABLE_FATAL way. That gives enough flexibility... 2. Unenforced type hinting: - If you have mixed types, then you just don't need type hinting. Lazy devs can still avoid using it. Lazyness shouldn't really be encouraged, so providing some kind of backwards compatibility just makes the feature useless :\ - This is not a feature, it's just better implicit documentation for methods 3. Casting weak type hinting: - This is just case (1) with implicit casting. In my opinion, developers should do the casts themselves with `foo((int) $bar)`. - Implicit casting in method calls would lead to chaos in tracking bugs (for me). Not to mention warnings in N-level hierarchies where values are pushed forward and backward. Let's throw the exception before it becomes chaos! - I am unsure if it also would degrade performance, but I know very little of internals. 4. Strict weak type hinting: I don't really see allowing any of [int, string, float] for any type hint for int, string or float as a feature. That's a silent failure to my eyes. An alternative could be throwing warnings if there's a type mismatch, otherwise the feature doesn't (again) provide anything new to me... It probably just makes it messier. 5. Boxing based type hinting: This is unrealted to the other 4 points to me. What PHP could probably do for us is to cast an object to a scalar when the object implements the compatible magic method (like `__toString`). Anyway, `__toScalar()` and `__fromScalar($scalar)` feels weak. I'd prefer a strict, well defined list of possible magic methods for the various internal types. Would that be a big performance issue? Marco Pivetta http://twitter.com/Ocramius http://marco-pivetta.com On 17 March 2012 14:38, Simon Schick simonsimc...@googlemail.com wrote: Hi, all Today I read a post around that: http://nikic.github.com/2012/03/06/Scalar-type-hinting-is-harder-than-you-think As some of us are leading to the 3rd and some to the 4th or other ways described in here (I think we can simply exclude the first one ...) Would it be an option (to get this moved forward) to let people vote which way they like most (or which comes closest to their best-solution)? I pretty much like the 3rd way ... the only thing I see that has not been discussed enough is how to handle integers on 64bit and 32bit installations. Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar-type-hinting - which way is the best to go?
On Sat, Mar 17, 2012 at 10:37 AM, Marco Pivetta ocram...@gmail.com wrote: Unenforced type hinting: - If you have mixed types, then you just don't need type hinting. Lazy devs can still avoid using it. Lazyness shouldn't really be encouraged, so providing some kind of backwards compatibility just makes the feature useless :\ - This is not a feature, it's just better implicit documentation for methods I just want to quick point out that I suggested the idea of introducing a scalar type hint that would accept all scalars but would disallow passing in arrays or objects. Additionally, the proposal outlined the option of introducing aliases for the scalar hint (bool, int, float, string) which would help developers better declare their intentions in terms of how they expected to use the scalar type. I don't think Nikita was referring to my idea when he referenced unenforced type hinting, as his examples show that passing in an object or array would both succeed even with an int (scalar) type hint. That said, I couldn't find a proposal suggesting a type hinting proposal that was purely documentational, so I wanted to take the time to make sure there was no miscommunication. Adam
[PHP-DEV] Randomize hash-function in php
Hi, All I just came around that talk a couple of days ago .. http://www.youtube.com/watch?v=R2Cq3CLI6H8 I don't know much about hash-maps and internal php-stuff at all, but they say that the fix provided in 5.3.9 (and 5.4.0) is more a work-around than a fix ... Would it be an option to provide a real fix in PHP 6.0? They got the feedback that this will take some time and is not trivial, but we have a good time before PHP6 and can also break backwards compatibility for php-plugins if really necessary. As they said in the movie, PHP seems to have the algorithm DJBX33A implemented as Ruby. So as they're so proud of the fix provided by the Ruby-Team, may we can use that for PHP as well :) https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-4815 This is not much because some attacker can do something, but what if you have a real-world-application that (for some reason) build up an array that just will blow up because of that? I haven't experienced that until now, but it's possible ... Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Randomize hash-function in php
Hi! I don't know much about hash-maps and internal php-stuff at all, but they say that the fix provided in 5.3.9 (and 5.4.0) is more a work-around than a fix ... This is true, it is a workaround in a meaning that the hash stays the same, but the fix prevents one from using excessive amounts of data that makes the hash unusable. Would it be an option to provide a real fix in PHP 6.0? They got the Definitely. However doing this has some challenges. We're working on it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Randomize hash-function in php
On 17/03/12 23:17, Simon Schick wrote: Hi, All I just came around that talk a couple of days ago .. http://www.youtube.com/watch?v=R2Cq3CLI6H8 I don't know much about hash-maps and internal php-stuff at all, but they say that the fix provided in 5.3.9 (and 5.4.0) is more a work-around than a fix ... Would it be an option to provide a real fix in PHP 6.0? They got the feedback that this will take some time and is not trivial, but we have a good time before PHP6 and can also break backwards compatibility for php-plugins if really necessary. As they said in the movie, PHP seems to have the algorithm DJBX33A implemented as Ruby. So as they're so proud of the fix provided by the Ruby-Team, may we can use that for PHP as well :) https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-4815 This is not much because some attacker can do something, but what if you have a real-world-application that (for some reason) build up an array that just will blow up because of that? I haven't experienced that until now, but it's possible ... Bye Simon Hi, Fairly new to this list so go easy :P.. Anyway I was looking at the hash function in PHP the other week, and was playing around with some different implementations. DJBX33A is fast, which I guess is why PHP uses it as it is hit so many times in the execution. However I tried and benchmarked a few different algorithms, I didn't try the patch you mentioned, however the only algorithm that came anywhere close to matching the DJBX33A method is Paul Hseih's Super Fast Hash algorithm: http://www.azillionmonkeys.com/qed/hash.html I benchmarked the DJBX33A against Hseih's algorithm and compared the results using an Intel x86 architecture and an AMD 64 machine and both algorithms performed similarly. The benchmarks weren't robust as they were only quick, 'let's hack and see' tests. Would be interesting if anyone else has had a go. If I can find it I'll post a patch so you could? Cheers Sam
Re: [PHP-DEV] Randomize hash-function in php
Hi! Anyway I was looking at the hash function in PHP the other week, and was playing around with some different implementations. DJBX33A is fast, which I guess is why PHP uses it as it is hit so many times in the execution. Some time ago we've checked various implementations of hash functions and the result was none produces better results consistently than one we already have. Note that you have to account not only for the function itself but for the usage patterns - e.g., distribution of key sizes for variables, functions, classes, etc. However bigger question is - wouldn't another hash function be as vulnerable? Unless we have a perfect hash we'll still have collisions, and that means it still can be attacked if collisions are easy to generate. Obvious solution would be to use a salt for the hash, which prevents blind pre-computing of hash collisions. However, due to the fact that PHP hash values can be reused in different processes by bytecode caches, implementing it properly is not trivial. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Scalar-type-hinting - which way is the best to go?
From: Marco Pivetta [mailto:ocram...@gmail.com] tl;dr: strict type hinting and Boxing based type hinting (the second one with some changes). Just read through it, and I was unaware there's still ideas to continue working on type hinting in PHP. There's been some recent discussion facilitated by understanding past fears and embracing some foundation principles as requirements of a successful solution (which solves a major problem with the scalar typing discussions from the past.) That's good news, at least for me :) I'm just lurking around here, but if my thoughts can help, here they are. Here's a short mapping of considerations related to the various implementations exposed on that blog post: 1. Strict type hinting (also aliased by me YES please, yes!): If you want scalar typing you'll have to move past this. I go into this a little below, but you should also look through the arguments in the archives. This is too strict (more strict that C++ actually). There are some rock solid arguments that have basically shut the door on this one forever. It will never pass a vote. 2. Unenforced type hinting: This almost happened in 5.4, but eventually got pulled. More interestingly, the *community* rejected it because it is useless. See the comments at http://sebastian-bergmann.de/archives/900-Scalar-Type-Hints-in-PHP-5.3.99.html for a good picture of why people hated this idea. Previous discussions on this mailing list also point out that this idea would ultimately be a dead end (a very good catch by...someone...). 3. Casting weak type hinting: Silently casting and discarding lost data is a huge problem and ultimately doesn't offer any substantial benefit. This was discussed previously. Also creates a dead end. 4. Strict weak type hinting: This realm is the most likely to succeed because the core already does something like this for internal functions (via zend_parse_parameters). This balances utility (enforcing the type) with fundamental language design principles (juggling). You need to understand the fundamental language principles to understand why any solution MUST lie somewhere in this realm. Remember that: 1.2 === 12; 2+2 === 4; substr(12345, 2) === 345; This type juggling affects the language in all sorts of ways. For example, PHP uses '.' for concatenation (not '+' like most similar languages) which ensures that there is no ambiguity as to whether you are operating against the integer value or the string value. PHP is designed so that you generally don't have to care whether a value is ACTUALLY an integer or a string internally, it will be treated as whatever type you use it as. In PHP int(2), float(2.0), and string(2) can generally be used completely interchangeably with no variation in results whatsoever. When core devs say that strict typing would make it not PHP anymore, this is what they mean; it would badly violate this core concept. If you want scalar typing, you need a solution that embraces this fundamental design principle. 5. Boxing based type hinting: This is a hack that's been proposed before, but you don't need to look very far to see why this ultimately breaks down badly. Even aggressive casting additions to the language would not make this work particularly well. Anyone who's ever tried to create a class wrapper for a scalar in C++ (which probably includes the core devs) is not likely to be down with this idea. John Crenshaw Priacta, Inc.
Re: [PHP-DEV] Scalar-type-hinting - which way is the best to go?
Thank you for clarifying some things :) 4. Strict weak type hinting: This realm is the most likely to succeed because the core already does something like this for internal functions (via zend_parse_parameters). This balances utility (enforcing the type) with fundamental language design principles (juggling). You need to understand the fundamental language principles to understand why any solution MUST lie somewhere in this realm. Remember that: 1.2 === 12; 2+2 === 4; substr(12345, 2) === 345; This type juggling affects the language in all sorts of ways. For example, PHP uses '.' for concatenation (not '+' like most similar languages) which ensures that there is no ambiguity as to whether you are operating against the integer value or the string value. PHP is designed so that you generally don't have to care whether a value is ACTUALLY an integer or a string internally, it will be treated as whatever type you use it as. In PHP int(2), float(2.0), and string(2) can generally be used completely interchangeably with no variation in results whatsoever. When core devs say that strict typing would make it not PHP anymore, this is what they mean; it would badly violate this core concept. If you want scalar typing, you need a solution that embraces this fundamental design principle. Yeah, I don't want to start a discussion on that now nor start a (probably already repeated) war on it, but I think those principles are dead since very long time... 5. Boxing based type hinting: This is a hack that's been proposed before, but you don't need to look very far to see why this ultimately breaks down badly. Even aggressive casting additions to the language would not make this work particularly well. Anyone who's ever tried to create a class wrapper for a scalar in C++ (which probably includes the core devs) is not likely to be down with this idea. That's not about working with scalar wrappers (which, anyway, would be very useful in Doctrine). It is about casting any object to array... `((int) $dbTableGateway)` could implicitly cause an sql `COUNT` query and stuff like that :) Maybe I'm too java-ish, but those look like good improvements to me :)
Re: [PHP-DEV] Randomize hash-function in php
On Sun, Mar 18, 2012 at 8:12 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Obvious solution would be to use a salt for the hash, which prevents blind pre-computing of hash collisions. However, due to the fact that PHP hash values can be reused in different processes by bytecode caches, implementing it properly is not trivial. What if php uses salts for specific hashes only, such as GPC (or all hashes whose lifetime is limited to the current reuqest), and use a zero-value salt for all others? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
