Re: [PHP-DEV] Proposed feature for json_encode()
Sara Golemon wrote: While it's technically safe to include user supplied data in json_encode() serialized values. The fact that characters such as ' remain as is means there room for some as-yet unidentified problem either in the browser's rendering or (more likely) elsewhere in one's codebase for this data to get into the wrong context and be executed. To that end, the attached patch allows the caller to be paranoid about their data and stipulate that ' should be encoded to hex references instead. This doesn't stop a web developer from dropping that content into an innerHTML of course, but it's one more rope holding the ship together. Obviously, since this adds five characters per pedantically escaped character, it's not something you'd want on by default, so the normal behavior would be to leave them alone. echo json_encode(foo); foo echo json_encode(foo, JSON_HEX_TAG); \u003Cfoo\u003E echo json_encode(foo bar='baz', JSON_HEX_TAG | JSON_HEX_APOS); \u003Cfoo bar=\u0027baz\u0027\u003E This was on my TODO, but you are way more productive than I am as witnessed by the 3 copies of this proposal we got. ;) -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: CVSROOT / avail loginfo
Richard Quadling wrote: The idea of a major world player contributing to our lill' old PHP sounds really exciting. The more the merrier, as long as the peer-review process works (and it seems to have kept me out of the core well enough!), let them come! We welcome any and all contributions, of course, but where there are strings attached it starts to get complicated. The problem here is that IBM employees can't contribute to open source projects without some protection in the form of a CLA. This CLA basically says that you have the rights to the contributions you make and that if the company you work for have copyrights or patents related to the contribution then you grant all rights to the receiving project. On the surface it may not sound too bad. It is sort of common sense that we aren't ripping off proprietary code from somewhere and sticking it in PHP and that we don't go out and get a patent on some concept and then put that code into PHP in order to sue everyone using PHP for violating our patent. However, the legal wording needed to do this looks something like this: http://www.apache.org/licenses/icla.txt It is long and complicated and I don't see how anybody could sign this without getting legal advice. You would also need to pass this by the legal department of the company you work for. Legal where I work wouldn't let us sign something like this for the longest time. They are working through it now, so it may be possible, but they had a long list of concerns and various needs for clarification as I am sure any company would have when their employees start signing legal documents affecting their patent portfolio. The end result is that I think there will be a significant number of current PHP contributors who either can't, or won't, sign a CLA like this. And if the code covered by this CLA is a significant part of PHP, then we have an untenable position. I would like to be proven wrong on this. I have had no part in these discussions, but from what people tell me the proposed CLA is based on the Apache CLA listed above, so have a careful read through that and make up your own mind. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposed feature for json_encode()
Stanislav Malyshev wrote: I can't because I don't know of any successful vectors *currently*. I also would have sworn that echoing htmlentified data was safeuntil I came across a browser where it wasn't. So that's what I wanted to understand, because if we add this feature, we should give some explanation on when to use it and what it does, and I don't think I understand that, so I guess it would help to have such explanation. Stuff like this often isn't completely deterministic. The attack vectors will move around and new ones will be discovered but since the syntax Sara is proposing is completely valid JSON it gives people another tool. Documenting specific attack vectors is useful too, of course, but a secondary concern in my mind. I don't think we have ever documented some of the vectors against htmlentities(), for example. Even with the latest character encoding fixes, there are still contextual attack vectors where doing htmlentities() on user data doesn't help you at all. For the curious, try this: ?php $foo = htmlspecialchars($_GET['foo'], ENT_QUOTES);? a href= onmouseover=a='?php echo $foo?';Mouse Over Me/a Then try hitting the page and set ?foo=';alert(0);// This doesn't mean there is anything wrong with htmlentities(), of course, it simply means it was used in the wrong context and another mechanism is needed here. I don't think it is hard to imagine that there are times when it would be nice to be able to move JSON data around in a context in which html tags and quotes might be inconvenient. Instead of applying a filter on top of it, having a version of json that doesn't have these is quite useful. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposed feature for json_encode()
Alexey Zakhlestin wrote: Is such filtering specific to JSON? Does it have some use out of JSON-context? Maybe it would be better to provide a set of functions for encoding characters into '\u'-entities? (similiar to htmlentities, htmlspecialchars) because if we speak of 'theoretical' problem, we might end reimplementing this for some other function later The \u syntax is specific to JSON, yes. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposed feature for json_encode()
Alexey Zakhlestin wrote: On 12/2/07, Rasmus Lerdorf [EMAIL PROTECTED] wrote: The \u syntax is specific to JSON, yes. \u syntax is specific to javascripts string literals, regular expressions and identifiers[1] And JSON is not the only way to deliver data into javascript. Manual approaches are still useful Since JSON and Javascript are synonymous, sure, \u is for javascript string literals. I thought you meant whether it was useful outside of Javascript. And I disagree with your second statement. Why wouldn't you use json anytime you wanted to jump from PHP to Javascript? script var a = ?php echo json_encode($a)?; /script That ensures that no matter what $a is on the PHP side, it will be correctly assigned to the corresponding Javascript variable. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] people.php.net
I have some new code for it. I'll try to find some time to update it over the next couple of weeks. -Rasmus Silvano Girardi Jr wrote: Gentleman, This morning I went to see Lukas speaking at the Brazilian PHP Conference and he mentioned http://people.php.net He said that it started with the idea to map the PEAR developers. I went to see it but the project seems to be stuck. Also, I was trying to find out on the mailings what you guys have already discussed about it but I have found nothing. Google shows only Antony asking on his blog if the idea died even before it was born :P I am starting a project here that could fit on the people.php.net so I'd like to know who is currently responsible for that and what I can do to help or perhaps assume it so we can have it moving forward. For those that saw the [EMAIL PROTECTED] and is wondering who I am, I have my account since 2005 when I put in the PEAR Validate_ptBR package but did not make more contributions since then. I'd like to get back with contributions and make my account worth. Regards, Silvano Girardi Jr. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] people.php.net
Nah, it does more than that. David Coallier wrote: You mean something like http://pear.php.net/map ? On Dec 3, 2007 12:44 PM, Rasmus Lerdorf [EMAIL PROTECTED] wrote: I have some new code for it. I'll try to find some time to update it over the next couple of weeks. -Rasmus Silvano Girardi Jr wrote: Gentleman, This morning I went to see Lukas speaking at the Brazilian PHP Conference and he mentioned http://people.php.net He said that it started with the idea to map the PEAR developers. I went to see it but the project seems to be stuck. Also, I was trying to find out on the mailings what you guys have already discussed about it but I have found nothing. Google shows only Antony asking on his blog if the idea died even before it was born :P I am starting a project here that could fit on the people.php.net so I'd like to know who is currently responsible for that and what I can do to help or perhaps assume it so we can have it moving forward. For those that saw the [EMAIL PROTECTED] and is wondering who I am, I have my account since 2005 when I put in the PEAR Validate_ptBR package but did not make more contributions since then. I'd like to get back with contributions and make my account worth. Regards, Silvano Girardi Jr. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposed feature for json_encode()
Stanislav Malyshev wrote: Stuff like this often isn't completely deterministic. The attack vectors will move around and new ones will be discovered but since the syntax Sara is proposing is completely valid JSON it gives people another tool. Documenting specific attack vectors is useful too, of course, but a secondary concern in my mind. I'm not talking about attack vectors and full security analysis. For me, it is a primary concern having some security oriented feature to know *what exactly* it does and when you should and should not use it. We were burned repeatedly by implementing various cool features that were misused for doing things that they weren't meant to do and then we were blamed for it - so I think we need to have clear understanding of when and why this feature is useful and explicitly document it. Otherwise what would happen is that people would use this option, pass JS data through it, stick it into DOM, get XSS and start blogging about huge XSS in supposedly secure json_encode() function in PHP. Or, not seeing how it can help them, won't use it at all. This is just a different way of encoding Javascript which depending on the context of use will enable Javascript to be embedded securely. Not providing an alternate encoding is a bit like arguing that we shouldn't have base64_encode() because if used incorrectly it could be insecure. We don't have an explanation of when base64_encode() is useful in the docs, although I suppose we could come up with some scenarios for when you want to squeeze arbitrary data into the set of characters base64_encode() uses. Same thing for this json_encode() feature. We can come up with a set of scenarios where we would like to avoid having characters that are meaningful in XML and HTML show up in our json strings. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Garbage collector patch
Antony Dovgal wrote: On 04.12.2007 18:31, Andi Gutmans wrote: You may be right longer term but shorter term I still believe there may be stability issues with this patch some of which we haven't figured out. Although we did testing and found crash bugs I wouldn't trust our level of testing to deem it stable. If we go down the route of always on we could have a hidden ini file (not listed in php.ini-dist and phpinfo()) which we can advise to turn off if something goes wrong and once we can enough confidence that there aren't any lurking bugs we could remove it. You mean provide an ini setting to be able to turn it Off? But why do you call it always On then? And what's the difference comparing to what you've proposed earlier? Concerning the stability issues, I'd say we have quite good chance to make it stable enough, as (I hope) 5.3.0 is not going to be released for at least several months more. Companies that are especially concerned of performance/stability are encouraged to step forward and give us a hand. Companies concerned about performance aren't going to use it at all. A 5% hit is significant given that it doesn't fix anything that a company already concerned about performance/stability cares about. Super leaky or recursively allocating scripts have long since been weeded out of those code bases, so it is a 5% performance hit with no gain. I am not arguing that it isn't useful in the general case. It will make PHP more robust on loosely controlled servers for what amounts to only a small penalty, but at the same time it is an easy 5% win for people with dedicated servers running well-written code. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Garbage collector patch
[EMAIL PROTECTED] wrote: I think having it configurable is a must. Turning it on / off via a compile flag will not suit everyone. Looking at the code, that isn't really possible. You could have a switch to turn off the collection, but that won't get you your performance back. To avoid the performance penalty you need it to be a compile-time decision. I only see 2 possible workable solutions here: 1. Always compile it in but leave undocumented #ifdefs in place for performance freaks. Those same performance freaks aren't going to care about the binary compatibility issue since they are the same people who build all their own stuff. 2. Drop it -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Garbage collector patch
Stanislav Malyshev wrote: 1. Always compile it in but leave undocumented #ifdefs in place for performance freaks. Those same performance freaks aren't going to care about the binary compatibility issue since they are the same people who build all their own stuff. Note that breaking BC is not only about performance - one your build is not the same as mainstream PHP, you can't use any binary extension which would do anything non-performance-related - like interfacing some external system/library, debugging, profiling, testing, security and so on. Any commercial module won't be available for the user of this switch, and all open-source modules one'd have to build by oneself, which may be serious maintenance issue. I know there are a bunch of companies that compile PHP with their own options but still use commercial modules, including both performance and non-performance ones. They couldn't use this compile switch. Yes, I know what binary compatibility means. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposed feature for json_encode()
Keryx Web wrote: Alexey Zakhlestin skrev: I think I understand what the use-case is… If the browser doesn't know anything about script tag, it is supposed to interpret it's contents as html… In which case, html-tags which appear in javascript code will actually become active ones And in the year 2007, soon 2008, what browser would that be? MSIE 2.0? (JScript was introduced in 3.0) Netscape 2.0B1? (JavaScript was introduced i B2) Mosaic? $10 to the first one who can name a browser that has a market share above 0.1% and will mistreat the contents in a script tag in this way. Nah, I'm generous, I'll make that €10! It may not be the browser that misses the script tag. It may be the developer. And I don't mean the trivial case of doing script?php echo json_encode(...)/script, this is more likely to happen in complex environments where you have XHR requests returning json and doing DOM manipulation on it. If you mess up and end up passing the returned json payload to innerHTML, you are hosed. Using the \u syntax, even if you mess up and that blob of data finds its way to an innerHTML, nothing nasty can happen. Basically this is a more robust context-protected way of encoding json. We should probably have done it this way right from the beginning, but since we didn't and since we don't really want to deal with the potential BC issues of changing working code, we have to add it as an option at this point. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Garbage collector patch
Making sure it is ifdef'ed nicely would let us leave it in CVS until we get it right and if it causes problems for some people they have a way to build PHP without it. And yes, that means their build won't be binary compatible, which is fine and no different from them trying to revert the patch themselves. -Rasmus Ilia Alshanetsky wrote: Putting it into CVS into a good idea, but lets create a revert point via a tag, so we can always easily undo the patch if need be. On 18-Dec-07, at 10:05 AM, Derick Rethans wrote: On Tue, 18 Dec 2007, Dmitry Stogov wrote: Derick Rethans wrote: On Mon, 17 Dec 2007, Dmitry Stogov wrote: Didn't I send it to you? Maybe, maybe not :) I couldn't find it atleast. I just tried to apply this to PHP 5.3, but it gives lots of failed chucks... Are you sure this is the one against 5.3? Probably I've changed ZE after the patch was done :( I'll rebuild it, but not today. Maybe we just should put it in cvs then? Then we won't have this issue and other people can test it more easily as well. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting
PHP is first and foremost a Web scripting language. Everything we do and every decision is based on that. For every feature the first question you need to ask yourselves is: Will this make it easier or harder for the average PHP user to build a web app? And if it makes it harder, is the extra pain worth the benefit? Given that HTTP is still the dominant web protocol and given that HTTP is not typed, we have to be very careful about introducing stronger typing into PHP, even if it is optional. Passing $_REQUEST['age'] to a function isn't a use-case that can be easily dismissed as it was by someone earlier. This is the primary use case. PHP takes scalar user data which comes across HTTP untyped, does stuff to it, and sends something back. The argument that adding a type hint will make documentation easier is a scary one for me. If we go and promote the use of runtime type hinting in order for people to use auto-documentation tools, they are likely to sprinkle these type hints everywhere which has the nasty side effect of causing runtime warnings or errors when something returns 1 instead of 1 whereas before this happily worked and worked correctly. And short of fuzzing all your code, you aren't going to catch this case during development. The robustness principle holds true here: Be conservative in what you do; be liberal in what you accept from others. This means that 1 and 1 should be able to travel freely within a PHP script without tripping anything up. And it means there needs to be ways for the code to be conservative in what it does with this data. Today this generally means casting and context-specific filtering. Robustness and code correctness play against each other to some extent. If you wrote your code in such a way that a function should always be passed 1 and not 1 then it might be nice to know when this isn't the case, which is what type hinting is all about. PHP has always leaned towards robustness, so having your code break in this case goes against the spirit of PHP. There are ways today to write code that is very strict in what it accepts. It is possible that we can make it a bit easier to write this style of code. But we have to keep this basic principle of PHP in mind and also keep in mind that the type check is only a part (and usually the fastest part) of the conservative data handling strategy. The context-specific filtering, like making sure -1 doesn't turn into 2147483648 in some unsigned backend, still needs to happen with or without type hints. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting
Stefan Esser wrote: Be conservative in what you do; be liberal in what you accept from others. You hopefully realise that this is exactly the opposite of your earlier opinion that ext/filter should be used to block everything and let only harmless data through. And only have raw data on demand... Not at all. Filtering is about the contents of the data, not the scalar type. It is only the most trivial of filtering that is solved by typing. It is the value of the number or the contents of the string that will trip you up, not whether it is a string or a number. I really don't understand why adding a *new feature* to the language (that you can use or just not use and) that helps writing better code and helps potential optimizers (that will come up as soon the feature is implemented) to highly optimize the code get so much resistance... I'm not against it, but if it is implemented, it needs to make sense. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] date/timelib: use system timezone database
Lukas Kahwe Smith wrote: On Jan 10, 2008, at 1:05 PM, Joe Orton wrote: I'm not sure I find the logic of the but the system-provided data will become stale arguments convincing; systems which are left unmaintained by the administrators will have old versions of software on; that's a given. I can't see why adding *more* packages (PECL timezonedb) which those admins have to keep up-to-date will make any difference to that. I think the point is not so much that the system provided one will become stale, but more that it impossible to write portable applications when relying on the system provided one. But, if every one of the thousands of packages out there included their own timezone database and there was a separate mechanism for updating each one, pushing a new timezone db to a server would be impossible. Making this an option for the distros is something we pretty much have to do. And yes, I know it makes life harder for people writing portable apps, but that's just the way it goes sometimes. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Array syntax []
And my stance hasn't changed either: http://marc.info/?l=php-internalsm=117060700805108w=2 Andi Gutmans wrote: Andi 2003: http://www.mail-archive.com/internals@lists.php.net/msg03896.html Andi's brain evolves 2007: http://marc.info/?l=php-internalsm=117057393530217w=2 And today I'm still +1. I really think by looking at some of the examples I worked through with my original posting in February and some of the recent comments the majority of people find [] more readable. It's cleaner, shorter and comes natural to most people. It's not about saving 5 characters as I type quickly, I really feel it's more readable and natural. We're kind of odd as a language in that sense i.e. array(...) I think almost everyone here agreed it'd benefit them and maybe the ones who don't would go through the same process I went through once they get used to it J Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SUMMARY: Array syntax
Johannes Schlüter wrote: But well in my results I have a problem: For Rasmus's vote I've counted a -1 while as such this syntax is appropriate I think has to be counted as +1. I don't understand how you interpreted my view as a -1. I'm somewhat ambivalent about it, but I don't think it would go against the grain of the language and I think people grasp the concept of square brackets being associated with arrays. Right from day one we have had the magical [] syntax for doing an array push, so I am not worried about readability, nor about confusing people. Take my vote as a +1 please. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP
I don't disagree with this, and that is actually why I insisted on having the unicode-semantics switch from the early days of the Unicode discussions, so you can blame me, again, if you consider it a bad design decision. My take on it was that just about all ISPs would run with Unicode semantics off and that the Unicode semantics on mode was more geared for large standalone applications and sites that wanted the luxury of working natively in their chosen character set without needing to always jump through hoops. If we get rid of the switch, then I agree that we can't make the default string IS_UNICODE. We would be crippling the implementation and taking a step backwards in terms of leading the way in Unicode adoption. The longterm goal for just about everyone has got to be a Unicode everywhere approach. It used to be that the Web was primarily a Western single-byte charset phenomena, but that hasn't been the case for years. All major applications out there have implemented various hacks to deal with these issues, some with more success than others. This is what PHP does. We take common Web development pains and try to reduce them. Think back to the pains of XML parsing in PHP 3 and even in PHP 4 compared to today. Ultimately we need to get to Unicode everywhere, and the Unicode semantics switch was an acknowledgement that the world isn't quite ready for that yet. But it sounds like the world isn't ready for the switch either. Without it, I am afraid we will never get there, and that may just be something we have to live with. -Rasmus Chris Stockton wrote: I partially agree, I have been watching this discussion and it's funny how we have such a class of high end developers saying to break old PHP code. But, the majority of the success of PHP is not due to this small class of high end developers, it's due to it's availability in a shared hosting environment, and the ease of use for beginners, and the oodles of fairly poor quality code that is easy to copy and paste onto peoples websites. Look at the adoption of php4, many webhosts haven't even updated to PHP5 completely due to things like register_globals and small backwards compatibility breakage. The list of problems is small and correctable, if you give system engineers at all of these hosting companies the choice of A. Upgrade to php6 and drive support calls through the roof, or B. Stay at PHP4/5 for eternity until a more (insert your complaints / rants here) language comes along to dethrone PHP. Problem is, PHP has been built to great success based on it's early foundation, but now a group of high class developers want it to be more then PHP was built onto. You will sacrifice it's success if backwards compatibility is not just, broke, but obliterated. Why change PHP's philosophy? Keep it easy for the new user, keep it successful, and make me work a little more when I want to implement my high class development methodologies. I don't mind, I do it already. I write this as a high class developer. -1 -Chris On Jan 22, 2008 7:32 PM, Richard Lynch [EMAIL PROTECTED] wrote: On Mon, January 21, 2008 8:38 am, Antony Dovgal wrote: 6 reasons why we must to get rid of The Switch ASAP I was +1... Until folks started posting that old PHP scripts won't run as-is in PHP 6?... That's just daft... When my webhost upgrades to PHP 6, I need all my old scripts to just keep on chugging away, as much as possible... I really think we're stuck with the default string being an old-school binary string, unless you want to lose a LOT of users in a hurry, or have PHP 5 stick around forever and ever. -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP
Richard Lynch wrote: On Wed, January 23, 2008 1:28 pm, Rasmus Lerdorf wrote: I don't disagree with this, and that is actually why I insisted on having the unicode-semantics switch from the early days of the Unicode discussions, so you can blame me, again, if you consider it a bad design decision. Would the world really end for people who write NEW apps in a NEW version of PHP, #6, if they had to put ufoo to get their nifty new-fangled Unicode strings?... Surely that is better than making a BC break of gigantic proportions for the unwashed masses that don't know a charset from a croquette and having NOBODY move to PHP 6 except a handful of large corporations... Like I said, without the unicode semantics switch, we can't make unicode strings default for BC reasons. The switch was there to allow not just large corporations, but also smaller companies and projects not restricted by portability or BC concerns to build stuff from the ground up entirely in Unicode. ufoo is a hack that will eventually disappear from the various languages that have it or something similar. 10 years from now I doubt anybody could even imagine that you could have a string that didn't carry its character set with it. Unfortunately 10 years ago, I wasn't very concerned about that. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP
David Zülke wrote: How about allowing bfoo in 5.3 (so people can start migrating their code early) and making unicode strings default in PHP7? :D That's been there for a very long time now. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP
No, sorry, I agree that was a badly written statement where the crippling part didn't refer to the previous sentence. I meant that if we remove the unicode semantics switch, then we are crippling the implementation because we wouldn't be able to make the default string literal IS_UNICODE which, I think we all agree, is where we will have to eventually get to. The question here isn't so much where we are going, but exactly how we will get there and how long that might take. In our early discussions on this stuff we did mull over this and figured we'd go ahead with the two-mode approach with the idea that PHP 6 would be the transition version where people could start off with Unicode-light (semantics off) and eventually turn them on to get ready for PHP 7 which would be all Unicode all the time. Apart from the string literals, I think setting the encoding for streams at runtime isn't that big a deal. The input encoding is a bit trickier since it happens before the script is run, but we did explore delaying the decoding until access time which again means it should be something the script can trigger at runtime which gives people the portability and BC they are aching for. -Rasmus Andrei Zmievski wrote: Did you mean to say can't make the default string IS_STRING? Because that's the only reading that makes sense given the rest of the message. -Andrei Rasmus Lerdorf wrote: If we get rid of the switch, then I agree that we can't make the default string IS_UNICODE. We would be crippling the implementation and taking a step backwards in terms of leading the way in Unicode adoption. The longterm goal for just about everyone has got to be a Unicode everywhere approach. It used to be that the Web was primarily a Western single-byte charset phenomena, but that hasn't been the case for years. All major applications out there have implemented various hacks to deal with these issues, some with more success than others. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Bug #43896 htmlspecialchars returns empty stringoninvalid unicode sequence
Peter Brodersen wrote: http://php.net/xml also documents this replacement: == If PHP encounters characters in the parsed XML document that can not be represented in the chosen target encoding, the problem characters will be demoted. Currently, this means that such characters are replaced by a question mark. == That was back in the expat days. We don't use that xml parser anymore. http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt mentions: == According to ISO 10646-1:2000, sections D.7 and 2.3c, a device receiving UTF-8 shall interpret a malformed sequence in the same way that it interprets a character that is outside the adopted subset and characters that are not within the adopted subset shall be indicated to the user by a receiving device. A quite commonly used approach in UTF-8 decoders is to replace any malformed UTF-8 sequence by a replacement character (U+FFFD), which looks a bit like an inverted question mark, or a similar symbol. It might be a good idea to visually distinguish a malformed UTF-8 sequence from a correctly encoded Unicode character that is just not available in the current font but otherwise fully legal, even though ISO 10646-1 doesn't mandate this. In any case, just ignoring malformed sequences or unavailable characters does not conform to ISO 10646, will make debugging more difficult, and can lead to user confusion. == That part is completely different. That's at the display level. Replacing it in the backend makes no sense to me. Don't use utf8_decode. Use iconv() so you know what the heck is going on. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] nowdocs again
Greg Beaver wrote: Dmitry Stogov wrote: The feature is very useful, however, I agree, the syntax would be better. :) The current syntax: $var = 'TEXT' text TEXT; I would like to see nowdocs. The closest equivalent in another syntax I can think of is xml's CDATA. Perhaps we can borrow something similar to that syntax $var = CDATA[ string here ]CDATA; No, please, let's not further promote CDATA abuse. Everyone seems to think that CDATA is some sort of binary-clean way to toss any junk they want into an XML file which isn't even close to being true. I don't think the 'FOO' syntax is very obvious either, but I can't think of a better one and if there isn't a commonly known syntax we can steal from another language, then making up our own, no matter what it is, is going to be non-obvious to a lot of people. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] BC break with callbacks in 5.3
Greg Beaver wrote:
Marcus Boerger wrote:
Hello Scott,
actually it was a bug. We, sorry I, did not spot this in earlier versions.
Now saying you rely on a bug in PHP 5 to be able to execute PHP 4 code
simply does not work.
Hi Marcus,
How is forcing users to replace call_user_func(array('Classname',
'func')) with eval('Classname::func') a good policy?
When this example code:
?php
error_reporting(E_NOTICE|E_WARNING|E_ERROR);
class A { function B (){}}
A::B();
?
functions differently from this code:
?php
error_reporting(E_NOTICE|E_WARNING|E_ERROR);
class A { function B (){}}
call_user_func(array('A','B'));
?
And in a minor version increment, this in fact introduces a bug, and
doesn't fix one.
I think the fix may be to simply add retval=0 in
zend_is_callable_check_func() here:
if ((check_flags IS_CALLABLE_CHECK_IS_STATIC)
!= 0) {
retval = 0;
} else {
if (EG(This)
instanceof_function(Z_OBJCE_P(EG(This)), *ce_ptr
TSRMLS_CC)) {
*zobj_ptr_ptr = EG(This);
zend_error(E_STRICT,
Non-static method %s::%s() cannot be called
statically, assuming $this from compatible context %s, (*ce_ptr)-name,
fptr-common.function_name, Z_OBJCE_P(EG(This))-name);
} else {
zend_error(E_STRICT,
Non-static method %s::%s() cannot be called
statically, (*ce_ptr)-name, fptr-common.function_name);
}
}
basically what is happening is that E_STRICT makes the callback invalid,
which is not technically true - the callback is valid, just not strictly
correct.
I can make a patch next week, if someone doesn't beat me to it. We need
a retval=0 in the inner else clause
Yes, I agree that we need to be consistent here.
error_reporting(E_ALL|E_STRICT);
class foo { function bar() { echo gah; } }
call_user_func('foo::bar');
foo::bar();
This needs to throw an E_STRICT in both cases. Right now we get an
E_WARNING and the call doesn't work for the first, and an E_STRICT for
the second. Having these behave differently makes no sense.
And likewise, is_callable('foo::bar') should return true.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ubuntu help, dl_open leaks?
Gregory Beaver wrote: Anyone have experience with this and advice on what I need to upgrade? It's normal. Create a suppression file and ignore those. eg. --gen-suppressions=yes And it isn't PHP calls leaking. It's just the way libdl does stuff. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) / zend_API.c zend_API.h php-src/ext/standard type.c
Cristian Rodriguez wrote: 2008/2/1, Marcus Boerger [EMAIL PROTECTED]: - Fix callable/static mess, the following will now all result in a E_STRICT . binding a dynamic function as a static callback . static call of a dynamic function . is_callable() on a static binding to a dynamic function Does not compile.. php5.3/ext/spl/php_spl.c: In function 'zif_spl_autoload_register': php5.3/ext/spl/php_spl.c:423: error: too few arguments to function 'zend_is_callable_ex' php5.3/ext/spl/php_spl.c: In function 'zif_spl_autoload_unregister': php5.3/ext/spl/php_spl.c:515: error: too few arguments to function 'zend_is_callable_ex' make: *** [ext/spl/php_spl.lo] Error 1 Did you update your Zend/ directory? It compiles fine here. I've been working through this one with Marcus a bit, and even though he fundamentally disagrees with the concept, he still wrote the code. I can't say I would have done the same in his place. So thanks, Marcus. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] get_magic_quotes_gpc, get-magic-quotes-runtime in head, get a final decision
Daniel Brown wrote: On Feb 5, 2008 3:26 PM, Daniel Brown [EMAIL PROTECTED] wrote: On Feb 5, 2008 3:23 PM, Pierre Joye [EMAIL PROTECTED] wrote: Hi, It seems that there is voices in favor of keeping the GPC related functions in HEAD/php6 but returning always FALSE. Personally XX VOTE CHANGED -1 After a quick off-list discussion with Hannes (gotta' love Gmail chat), I realized that I forgot to consider backwards-compatibility. I think a lot of people miss the point of these particular functions. This isn't about whether to keep magic quotes or not, it is whether to keep the function that tells you whether magic quote mangling is enabled. There is a lot of code out there that checks to see if this feature is on, and deals with that case. Having this function that simply tells the code to take the other path will allow it to work. This is not about restoring the magic quotes feature at all. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] _REQUEST and variable_order
Stanislav Malyshev wrote: Hi! This topic was already discussed here but never arrived to a conclusion, so I will raise it again. The Problem: We have $_REQUEST superglobal, which is often used to abstract GET/POST requests. However, in most cases we do not want GET/POST variables to mean the same as cookie and environment variables. We can avoid that by setting variables_order to 'GP' but then we lose _SERVER and _COOKIES which still can be very much useful. We cannot also reliably use something like 'CGP' since while it won't allow cookies to override GET/POST we still have no way of not accepting cookie that has no matching GET/POST. I think this should be cleaned up so that _REQUEST behavior would conform its use case. The proposal(s): 1. One way to fix it is to create a new .ini request_order that would control just _REQUEST. 2. Other solution would be to keep variables_order but drop 'C' parsing from _REQUEST - i.e. make _REQUEST never include cookies. I don't know how many people really need cookies together with get/post in REQUEST. 3. Yet another solution would be to make superglobals independent of variables_order - i.e. _COOKIE would always exist even if variables_order doesn't have the letter. I actually don't see any reason having JIT to remove any of the superglobals - if you don't use them, with JIT you don't pay for them. And with COOKIES it's not that it would be a big cost anyway - how many cookies could you have? Of course, it'd be more substantial change which could break some apps relying on some quirks of current behavior. So, what do you think on this? They are all about equivalent. Even #3 would need some sort of ini override since otherwise it removes some flexibility we have today. There are setups that specifically rely on disabling $_COOKIE to force code to go through other mechanisms to get at the cookies. Perhaps a combination of 1 and 2. By default drop cookies from $_REQUEST but have an ini override for the few cases where the app actually relies on this behaviour. I have seen multi-page forms where instead of bouncing previous inputs along in hidden fields it gets transmitted in cookies and they use $_REQUEST to keep track of all of the responses. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] _REQUEST and variable_order
Jani Taskinen wrote: On Wed, 2008-02-06 at 20:27 -0800, Rasmus Lerdorf wrote: Stanislav Malyshev wrote: Hi! This topic was already discussed here but never arrived to a conclusion, so I will raise it again. The Problem: We have $_REQUEST superglobal, which is often used to abstract GET/POST requests. However, in most cases we do not want GET/POST variables to mean the same as cookie and environment variables. We can avoid that by setting variables_order to 'GP' but then we lose _SERVER and _COOKIES which still can be very much useful. We cannot also reliably use something like 'CGP' since while it won't allow cookies to override GET/POST we still have no way of not accepting cookie that has no matching GET/POST. I think this should be cleaned up so that _REQUEST behavior would conform its use case. The proposal(s): 1. One way to fix it is to create a new .ini request_order that would control just _REQUEST. 2. Other solution would be to keep variables_order but drop 'C' parsing from _REQUEST - i.e. make _REQUEST never include cookies. I don't know how many people really need cookies together with get/post in REQUEST. 3. Yet another solution would be to make superglobals independent of variables_order - i.e. _COOKIE would always exist even if variables_order doesn't have the letter. I actually don't see any reason having JIT to remove any of the superglobals - if you don't use them, with JIT you don't pay for them. And with COOKIES it's not that it would be a big cost anyway - how many cookies could you have? Of course, it'd be more substantial change which could break some apps relying on some quirks of current behavior. So, what do you think on this? They are all about equivalent. Even #3 would need some sort of ini override since otherwise it removes some flexibility we have today. There are setups that specifically rely on disabling $_COOKIE to force code to go through other mechanisms to get at the cookies. Perhaps a combination of 1 and 2. By default drop cookies from $_REQUEST but have an ini override for the few cases where the app actually relies on this behaviour. I have seen multi-page forms where instead of bouncing previous inputs along in hidden fields it gets transmitted in cookies and they use $_REQUEST to keep track of all of the responses. What's wrong with the option 3? $_GET / $_POST / $_COOKIE should _always_ be there regardless of any ini setting. I didn't even know (before Stas brought it up) that variables_order affects these so in my book that's just a bug that needs fixing. And does not require any new ini options.. :) I pick door #3. Well, plenty of people know about this feature and make use of it. Especially since it has been documented to work this way for a long time. See: http://php.net/manual/en/ini.core.php#ini.variables-order Sets the order of the EGPCS (Environment, Get, Post, Cookie, and Server) variable parsing. For example, if variables_order is set to SP then PHP will create the superglobals $_SERVER and $_POST, but not create $_ENV, $_GET, and $_COOKIE. Setting to means no superglobals will be set. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] _REQUEST and variable_order
Jani Taskinen wrote: On Thu, 2008-02-07 at 01:43 -0800, Rasmus Lerdorf wrote: Jani Taskinen wrote: On Wed, 2008-02-06 at 20:27 -0800, Rasmus Lerdorf wrote: Stanislav Malyshev wrote: The proposal(s): 1. One way to fix it is to create a new .ini request_order that would control just _REQUEST. 2. Other solution would be to keep variables_order but drop 'C' parsing from _REQUEST - i.e. make _REQUEST never include cookies. I don't know how many people really need cookies together with get/post in REQUEST. 3. Yet another solution would be to make superglobals independent of variables_order - i.e. _COOKIE would always exist even if variables_order doesn't have the letter. I actually don't see any reason having JIT to remove any of the superglobals - if you don't use them, with JIT you don't pay for them. And with COOKIES it's not that it would be a big cost anyway - how many cookies could you have? Of course, it'd be more substantial change which could break some apps relying on some quirks of current behavior. So, what do you think on this? They are all about equivalent. Even #3 would need some sort of ini override since otherwise it removes some flexibility we have today. There are setups that specifically rely on disabling $_COOKIE to force code to go through other mechanisms to get at the cookies. I missed this from your mail. Sounds a very weird idea, do they set $_COOKIE themselves then? And can I ask where such setup is used? Very large sites with signed and encrypted cookies containing lots of sub-parts will typically want to only decrypt and validate these cookies once. Likely before they even get to PHP and provide an API to get at them instead of having all the bits downstream each try to parse the raw $_COOKIE value. Being able to turn off $_COOKIE altogether helps make sure everyone follows that approach. I pick door #3. Well, plenty of people know about this feature and make use of it. Especially since it has been documented to work this way for a long time. See: http://php.net/manual/en/ini.core.php#ini.variables-order But was it really designed to work like that? :) It was actually. Initially it was designed that way for performance reasons. Populating $_ENV on every single request if you weren't going to use it made no sense. This was obviously pre-JIT. In a pre-JIT world being able to disable these made a lot of sense. Now the performance reason is mostly gone, but it still leaves us with applications that don't expect them to be there. Worst-case we have configurations that explicitly have turned them off and create their own $_COOKIE array to implement a local security policy. Having the superglobal show up and populate what they thought was a locally created array could cause security problems. Anyway, I guess there's no other way out of this than creating another ini option, say request_variables_order which controls whatever goes in $_REQUEST. But would the variables_order still control the overal situation? For example when it is set to GP and request_variables_order is set to GPC, would $_REQUEST have all of $_GET / $_POST / $_COOKIE regardless what variables_order has in it? The less we change, the better. That includes the meanings of existing directives. We should focus on the actual problem and make the fewest changes possible to solve that. The actual problem being that by default cookie data is in $_REQUEST and that can lead to problems. So, we change that default. Now, in the few cases out there where someone really does want cookie data in $_REQUEST we can provide an ini for them to enable that. Since today we don't have the ability to have cookie data in $_REQUEST without also having $_COOKIE present, we won't break anything by not supporting that edge case. So I think we can tie the two together and perhaps throw a startup error if someone tries to make $_REQUEST contain cookie data if variables_order does not include C -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Larry Garfield wrote: You also note that this mechanism has no runtime impact. That's unfortunate, because I'd find the ability to add methods to an object at runtime conditionally based on some other value far more useful in my work. :-) Especially since, as above, there seems to be a way to implement this functionality now as-is with a little more typing, yet runtime modification is still impossible without eval() and similar scary stuff. The idea here is that we want to be able to cache opcodes, classes and functions and optimize them out of the runtime context so the executor can skip creating classes and functions on every single request. A lot of the traffic on this list over the past couple of months seems to ignore this basic premise. Features such as autoload and runtime object manipulation incur a huge performance hit in the sense that they change something that was free before and not only add the cost of the feature itself, but it also means the object in question now can no longer be cached and has to be created on every single request. This doesn't mean we can't consider such features, but people need to also consider the performance implications. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Marcus Boerger wrote: Hello Stefan, any dynamic aspect of a class has brought us to problems in inheritance and required us to design the objct/compile model in a way that inheritance often is done at run time. Imo traits are a way out of this. In fact I'd love to issue a deprecated message as soon as class is found outside of a main block. That would mean deprecating autoload as well since autoloading a class is effectively the same as defining it outside of the main block. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
Richard Lynch wrote: On Mon, February 18, 2008 7:45 pm, Rasmus Lerdorf wrote: The idea here is that we want to be able to cache opcodes, classes and functions and optimize them out of the runtime context so the executor can skip creating classes and functions on every single request. A lot of the traffic on this list over the past couple of months seems to ignore this basic premise. Features such as autoload and runtime object manipulation incur a huge performance hit in the sense that they change something that was free before and not only add the cost of the feature itself, but it also means the object in question now can no longer be cached and has to be created on every single request. This doesn't mean we can't consider such features, but people need to also consider the performance implications. Many users need opcode caches and performance is crucial... Many MORE don't, really :-) That's a bit like saying that most people don't need more money. While probably true, it certainly doesn't hurt to have much lower page latencies. Similarly, most people don't need to scale either, but that doesn't mean we should suddenly start tearing down our perfect shared nothing sandbox. If we design for good performance and scaling, the trickledown effect means that even horribly-written applications will be usable while the people who care about performance can get outstanding performance out of it. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.5 and static calls
till wrote:
Bjori just nailed it:
class foo { function foo() { echo 'foo'; } }
foo::foo();
It's some constructor BC thing.
I didn't think any of these changes were in the 5_2 tree at all. As far
as I am concerned the E_STRICT is for 5.3. We can't make a change like
this in a minor version bump.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Replace the flex-based scanner with an re2c [1] based lexer
Stanislav Malyshev wrote: Hi! be much easier, switching to re2c promises a much faster lexer. Actually, without any specific re2c optimizations we already get around a 20% scanner I think 20% faster is very cool. However, as I understand re2c is not a standard tool found everywhere. So what happens if you wanted to use it on some exotic system where re2c is not readily available as manintainer-supported software? Also, flex is available on Windows for example as part of cygwin, while I don't see re2c there. I don't think this part is a concern since we have required re2c for quite a while now to build many critical parts of PHP. People who actually need to regenerate the parser files are the same people for whom it is trivial to figure out how to install re2c. And yes, it would of course be good to use a released version of re2c, but I think by the time 5.3 is ready to go the version of re2c we need will be out there. Since it is Marcus' baby, he can just push it out, I don't think this is a stumbling block either. Some of the new stuff in re2c was specifically added to make it easier to write a PHP parser, so I don't think backporting to an older version is really an option. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: How PHP utilizes the Google SoC
Philip Olson wrote: On Mar 4, 2008, at 7:07 PM, Daniel Brown wrote: On Tue, Mar 4, 2008 at 5:17 PM, Philip Olson [EMAIL PROTECTED] wrote: The Google Summer of Code sponsors students to work on Open Source projects over each summer. This RFC introduces guidelines and goals involving how we handle the SoC process. [snip=important info] Philip (or anyone else who can answer); According to the information I've read (and I'll admit, I've *heard* of the GSoC, but am by no means familiar with it), the organization receives a small stipend as the representative group. My question is: how is this usually spent? The reason I ask is because I'd be very interested in mentoring a student on a project if we can use this money to help move the RFC Wiki (or similar) idea forward. Besides, I'd be killing two birds with one stone as it was, I was trying to figure out how I'd afford the box and bandwidth as it is, because the Wiki idea - as I think others may agree - is an excellent step toward the future of the development of PHP. So it's not an unselfish move on my part. Hello Daniel, Lack of funding is rarely a cause for such issues. Where there is a will, there is a free way. Many entities exist out there that are willing to donate boxes and bandwidth but people just need to find them. The wiki is moving forward after delays for many reasons including unknowns about if PHP wants a wiki (some people hate them), our chaotic nature, and lack of time. Lukas is now working on the wiki and it already has a domain (wiki.php.net) and CVS module (php-wiki-web) and once it goes online I have a feeling other new tools will start evolving. Just a guess. These were created yesterday. As for where the mentor SoC money goes, I think it finds its way towards random PHP user groups. The money goes directly to the students. PHP as a project does not take any money. Technically we could, but we haven chosen in the past not to. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for opcode caches
Marcus Boerger wrote: Hello Stanislav, Friday, March 14, 2008, 5:51:49 PM, you wrote: But that means we are compiling inheritance when a file is loaded form the cache. The goal should be to compiling inheritance when writing to the opcode cache file. All we achieve here is a slow down. If there is You can not do that. You do not know that until runtime. something that makes this required than at least we need to warn the user about the slow code. I Think what we need to do is deprecating class and It won't be slow. It would be much faster (in some cases 10x faster). This specific assembly of instructions might be slower in some cases, but the code altogether will be faster. That's the idea of the opcode caches. namespace use in non main blocks as well as include and require in non main blocks. And if there is no such case than everything can be bound early which is the fast state we should aim for. Lemme just think, doing inheritance at compile time before we send the stuff to an opcode cache can be slower then? How is that possible? After all late binding means we do it at run time. And no matter how much faster we can do it. It will always be slower than doing the same thing only once. We do not need to deprecate anything, and inheritance can not be bound before parent class is known, which in the case of bytecode cache means - not before the file is loaded from the cache. That's exactly what this patch enables. It does not change performance characteristics of neither cached not non-cached code, it just makes it much simpler and working in all cases. Inheritance cannot be done before the parent class is known. We still need to do the prototype checks even if we assume the class is there and insert a virtual class as parent somehow. I don't actually see early binding as being much of a problem, the real problem is when the same class is both early and late bound. If you consistently always bind early or always bind late, opcode caches should be quite happy to let you do that. But if you mix the two, things get chaotic and the problem becomes intractable. We went through all this in APC a couple of years ago. My initial, somewhat naiive attempt at fixing it: http://news.php.net/php.pecl.cvs/4288 That obviously wasn't enough to fix it, so essentially we end up simply detecting the scenario and not doing early binding for classes that are detected to also be bound late: http://pecl.php.net/bugs/bug.php?id=5314 -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] setjmp usage
We are using setjmp(__bailout) in zend_try, but setjmp behaves differently on BSD and Linux. POSIX doesn't specify whether the signal mask should be saved or not for this call, so different operating systems do different things here. I think it would be more consistent if we used sigsetjmp(__bailout,0) to always specify that we don't need to store the signal mask. This avoids an expensive sigprocmask syscall. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: php-src(PHP_5_3) /main SAPI.c SAPI.h main.c php_globals.h /sapi/apache mod_php5.c ZendEngine2 zend_execute.h zend_execute_API.c
Edward Z. Yang wrote: Rasmus Lerdorf wrote: exit_on_timeout patch Hi Rasmus, I noticed that this patch modifies the Zend Engine API slightly. Does this translate into any changes that need documentation at php.net? No, I don't think so. I checked all extensions in php cvs, including pecl, and none of them call zend_set_timeout() which is the function that was changed. And I can't see any foreign extension needing to call that function either. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CMake SoC Proposal
Gwynne Raskind wrote: My two US cents :). On Mar 19, 2008, at 9:17 PM, Jani Taskinen wrote: Here is a quick run down of some of the features of CMake and tools associated with it: • A single configure script that would be used regardless of the OS • A much simpler scripting language m4 is simple. :-p Since when? m4 is actually one of the simplest languages around. There really isn't much to it. The pain point of autoconf/automake/libtool isn't m4, it is the complicated and often obtuse relationship between those 3 tools. I don't mind exploring cmake, but it is a massive undertaking to create something that can build PHP on every UNIX and pseudo-UNIX platform out there. We should figure out what the main goal here is. If it is simply getting native build files so people can use their pointy-clickety interfaces to build PHP, then it is probably way easier to create .in files to generate those basic build templates from our current system than it is to rewrite the whole thing. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
Stanislav Malyshev wrote: I see your point... but wouldn't it be better not to need that? Johannes' idea seemed good to me, always assuming it's do-able. Well, yes, it would indeed, but we have a lot of ?= templates now so either we allow ?= on no-short-tags (if XML guys out there will be OK with it I might be OK too, as IMO no valid XML would have ?=) or invent some other syntax - in which case a) it probably would be worse than ?= since you hardly can get shorter and opening tag + = is kind-of de-facto standard for such things by now and b) it's take time to educate people to use new syntax, especially that unlike ?= it won't work on PHP 5.3 so people would stay away from it for a couple of years (heck, people still use PHP 4 out there! not talking about 5.0). So we have this: 1. Leave it as is and be in World of Configuration Pain (TM) 2. Allow ?= independent of short tags (my +1, dunno about XML templates guys) I'd be ok with that too. It's not a valid PI tag, as far as I know, but I don't think that is a problem. One interesting observation is that there was a slight BC break related to short tags between PHP 4 and 5 that I hadn't noticed before. ?= /* 123 */ ? Works in PHP4 but results in a syntax error in PHP 5. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
Soenke Ruempler wrote: Hi Rasmus, On 03/23/2008 03:32 PM, Rasmus Lerdorf wrote: This is what the filter extension is for. You should be working with escaped data by default and only poke a hole in your data firewall in the few places where you need to work with the raw data. Doing it the other way around is going to lead to all sorts of security issues. Mhm. Isn't the the right paradigm to prepare variables at the time they are passed into subsystems (sql, shell, html etc.)? So what do you mean with escaped data here? html/xml escaped, sql escaped (which sql system and which encoding?). Sounds a bit like magic_quotes reloaded *hides* It is, but it is magic_quotes done right. You apply a really strict filter that makes your data safe for display and your backend by default. The only place you can reliably do this this is at the point the data enters your system. Once it is in, having to remember to apply a filter before you use the data will never work. You might remember to do it 99.99% of the time, but that doesn't help you and you might as well not do it at all. A bit like a condom with just one little hole. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
Soenke Ruempler wrote: Hi Rasmus, On 03/23/2008 04:14 PM, Rasmus Lerdorf wrote: It is, but it is magic_quotes done right. You apply a really strict filter that makes your data safe for display and your backend by default. The only place you can reliably do this this is at the point the data enters your system. Once it is in, having to remember to apply a filter before you use the data will never work. You might remember to do it 99.99% of the time, but that doesn't help you and you might as well not do it at all. A bit like a condom with just one little hole. Well, my point is: at the stage where user generated data enter your program you don't know for which subsystem to prepare it. Maybe for one, maybe for more of them (it's a common case that user input is first written to SQL backend and then displayed again). So if everything is html escaped with the filter extension and I wanna put it into SQL I have to remember ah all my input is escaped for html so I have to DECODE it and then prepare it to go into SQL. Now the question is: What's easier, more intuitive and less headaching? No, that's the point. You never ever decode data. If you are using any sort of decode function, chances are your application is insecure. The filter extension keeps a copy of the raw data internally. The default filter you apply will filter for all the backends you use. htmlspecialchars with all single and double quotes converted as well, takes care of most commonly used stuff. When you need the raw data, or the data filtered in a different way, you ask the filter extension to re-filter from the stored raw data, you don't decode. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
Wietse Venema wrote: Rasmus Lerdorf: Soenke Ruempler wrote: Hi Rasmus, On 03/23/2008 03:32 PM, Rasmus Lerdorf wrote: This is what the filter extension is for. You should be working with escaped data by default and only poke a hole in your data firewall in the few places where you need to work with the raw data. Doing it the other way around is going to lead to all sorts of security issues. Mhm. Isn't the the right paradigm to prepare variables at the time they are passed into subsystems (sql, shell, html etc.)? So what do you mean with escaped data here? html/xml escaped, sql escaped (which sql system and which encoding?). Sounds a bit like magic_quotes reloaded *hides* It is, but it is magic_quotes done right. You apply a really strict filter that makes your data safe for display and your backend by default. The only place you can reliably do this this is at the point the data enters your system. Input fitering has valid uses, but protecting html/sql/shell/etc. is not among them. Legitimate input like O'Reilly requires different treatments depending on html/sql/shell/etc. context. It would be incorrect to always insert a \, it would be incorrect to always remove the ', and it would be incorrect to always reject the input. You can also choose to never store the raw single quote and always work with encoded data. Or, as I suggest, always filter it by default and in the places where you want the raw quote back or you want it filtered for a specific use, specify explicitly which filter you want to apply. It is the data firewall approach. Filter everything by default with an extremely strict filter and poke holes in your data firewall as necessary. It also makes it easy to audit your code because you only have to track look at the places where you have poked a hole. Data flow control (a.k.a. taint support) can detect when output isn't converted with the proper conversion function. This can be done in reporting mode (my approach) or it can be done in automatic fixing mode (other people). These different approaches make different trade-offs between programmer effort and system overhead, and avoid the data corruption that input filtering would introduce. Having to do active checks on each use is extremely expensive. You said yourself you suggest only enabling this during development. The data firewall approach isn't actually all that different from the taint approach. The big win is that there is no runtime checking necessary and thus no performance hit. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
Stefan Walk wrote: Rasmus Lerdorf schrieb: It is, but it is magic_quotes done right. You apply a really strict filter that makes your data safe for display and your backend by default. The only place you can reliably do this this is at the point the data enters your system. Once it is in, having to remember to apply a filter before you use the data will never work. You might remember to do it 99.99% of the time, but that doesn't help you and you might as well not do it at all. A bit like a condom with just one little hole. -Rasmus No, it's not done right. To work for all cases, your default filter would basically have to return an empty string all the time (if you say nonsense, does the default filter strip From from the start of a line so you can put it into an mbox?). And you don't need do do that to be safe, because you don't have to remember to apply a filter, you use the subsystem that needs the escaped data to escape the data itself. So, when passing an arg to a MySQL query, it gets escaped the right way (by using pepared statements, formatted query strings ... hundreds of possibilities). If you pass data to the HTML output subsection, it gets escaped for use in HTML. Cause this is done implicitely, you never ever call an escaping function yourself, so there is no way to forget it. But you know which backends you use. I am not suggesting that PHP can supply a default filter that works for everyone. But I am suggesting that you can supply a default filter that works for the backends you use. The vast majority of people need data to be safe from HTML and MySQL/PostgreSQL. So having a default filter that makes data safe for these uses and throw in Shell, CSS and Javascript as well, and you have a really powerful default filter. Yes, there will always be other subsystems out there that needs other filtering, in which case you extend your default filter to cover those, or you wall off those subsystems and have a secondary filter layer. The alternative of relying on the developer remembering to filter simply doesn't work. Wietse's taint mode is another approach, but it has performance implications. The data firewall approach is what I put in place at Yahoo 5+ years ago now. We have hundreds of applications written by thousands of developers and it works. Yes, there are still security issues from time to time, but they end up being logical flow issues that no amount of filtering would fix, or they stem from people applying the wrong filters in the wrong situations which again would happen under any system. What we don't see are security problems caused by developers forgetting to filter a specific bit of user data. The other thing this gives us is the ability to run 3rd-party untrusted apps. You only need to find the 2 or 3 places where the app needs something other than the default filtered data and even the most insecure app can be run with some semblance of security. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
Stefan Walk wrote: Rasmus Lerdorf schrieb: The alternative of relying on the developer remembering to filter simply doesn't work. Wietse's taint mode is another approach, but it has performance implications. As I said, when the backend does the escaping, you don't have to remember it. filtering would fix, or they stem from people applying the wrong filters in the wrong situations which again would happen under any system. What If the backend picked the escaping mechanism, *that* wouldn't happen (if the backend isn't buggy, but that can happen for any way) The other thing this gives us is the ability to run 3rd-party untrusted apps. You only need to find the 2 or 3 places where the app needs something other than the default filtered data and even the most insecure app can be run with some semblance of security. Some is the right word here. That insecure app could leak information from your server, write or read data to/from locations it shouldn't, etc. Also, I don't think it would be just 2 or 3 places. It'll be more like every point where it's real user input (and not form ids, hidden values etc), because then you have to expect almost any char that your filter has to strip to be safe - Mr. O'Reilly won't be amused if he's called OReilly, O''Reilly, Oapos;Reilly or O\'Reilly. Well, I actually have years of experience taking apps and making them run under my strict default filter. And it tends to not be very many changes, if any at all. In the O'Reilly case it gets changed to O#39;Reilly which for a pure web app is fine. If all input consistently gets changed the same way then you can store O#39;Reilly in the backend and a search will still find it since the search query itself will be encoded the same way. If you have non web tools working with the same backend data, then you may have a requirement to store it raw, in which case you'd need to poke a hole in your data firewall. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
Edward Z. Yang wrote: Rasmus Lerdorf wrote: Well, I actually have years of experience taking apps and making them run under my strict default filter. And it tends to not be very many changes, if any at all. In the O'Reilly case it gets changed to O#39;Reilly which for a pure web app is fine. If all input consistently gets changed the same way then you can store O#39;Reilly in the backend and a search will still find it since the search query itself will be encoded the same way. If you have non web tools working with the same backend data, then you may have a requirement to store it raw, in which case you'd need to poke a hole in your data firewall. Rasmus, I'm sure these techniques work very well in practice. However, it's important to note that it's still an optimization, a step down from an ideal standard which would involve keeping raw data in the database. In theory, the data in its purest form, with no extraneous escaping, would be stored. In practice, most data will be used in a web context and thus, as you note, escaping it as #39; is perfectly acceptable. I've always advocated storing both the pure data and the escaped version (in a kind of cache) in the database, because if you store just the escaped version you don't have any easy way (besides decoding) to get the raw version back. Of course, this doubles the storage requirement. Sure, although if you are going to store the raw, I think it is pointless to store the escaped version. But this is not the point. I am not advocating storing it either way, I am simply saying that by default you should never work with raw user data. You should limit the scope in your code where raw data is used. So if you need to store the raw data, fetch it just before storing it or just before sending a query to the backend. Everywhere else that same piece of data is a very strictly escaped piece of information. If you forget to fetch the raw or if you forget to re-filter it through the appropriate filter for whatever backend, then chances are your application won't work, or the user will see strange output, but at least you will be failing safe, instead of failing insecure. There are so many places where one missed filter has been the downfall of a web app. Think of an age or state select dropdown. It's very easy to forget to filter such an innocent-looking field in a web app, and even a very strict default filter isn't likely to mess up a 2-letter state name or a 2-digit number so running such an app with a couple of missing filters isn't going to affect it at all. It will simply make something that wasn't safe before, safe. By the way, if anybody on the list has a web app they'd like me to check, you have probably heard of the tool I wrote for this purpose called Scanmus. If you send me a note privately, I'd be happy to scan it for you, if for nothing else, to illustrate just how many web apps written by otherwise competent developers are insecure. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
Stefan Walk wrote: Rasmus Lerdorf schrieb: Well, I actually have years of experience taking apps and making them run under my strict default filter. And it tends to not be very many changes, if any at all. In the O'Reilly case it gets changed to O#39;Reilly which for a pure web app is fine. If all input consistently gets changed the same way then you can store O#39;Reilly in the backend and a search will still find it since the search query itself will be encoded the same way. If you have non web tools working with the same backend data, then you may have a requirement to store it raw, in which case you'd need to poke a hole in your data firewall. I have a hard time remembering the last at least half-serious web app that i touched that didn't at least include email functionality ... and even if it doesn't, storing scrambled data in the backend is not really a good idea, for example because it makes adding functionality - like email - that needs another encoding hard. Like I said, I'm not advocating storing it encrypted, I was simply saying it isn't necessarily going to break anything running an app unchanged under a default filter. And even if it does, in an app that does email, the breakage will be limited to some funny-looking #39;'s here and there in the emails that go out, assuming of course they aren't HTML emails, in which case it would look fine. Failing safe like that is much better than having XSS issues everywhere. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
Edward Z. Yang wrote: Rasmus Lerdorf wrote: Sure, although if you are going to store the raw, I think it is pointless to store the escaped version. Yeah, I was thinking more of escaping data that is computationally expensive; such as bbcodes or wikitext = HTML. I am not advocating storing it either way, I am simply saying that by default you should never work with raw user data. [snip] If you forget to fetch the raw or if you forget to re-filter it through the appropriate filter for whatever backend, then chances are your application won't work, or the user will see strange output, but at least you will be failing safe, instead of failing insecure. I understand that and how your methodology works, but I've always thought there was something fishy about it. I suppose this is the reason: the default won't always be secure, because HTML (and other formats too, I suppose) require a great variety of types of escaping. Say we're placing data in a href= attribute; the default HTML escaping will protect against breaking out of the quote, but the user can still pass javascript:xss() and cause problems. There are two levels of escaping/validation that need to happen here: the HTML escaping, and a URI validation. The default can lull users into a false sense of security, especially for more subtle vectors, whereas if you force people to be explicit you've at least *attempted* to make them think about what output format they should be using. Either that, or make it so that the only way for a developer to output something like that is a manner that also supplies the context (for example, using a DOM builder). Of course, careless developers will still make careless mistakes, and I agree that a sensible default will fix the majority of these issues. Just not 100%. Nothing will ever be 100%. There will always be context issues, but no mechanism will fix those. script?= $user_data?/script is another example of a no-win context. There is simply no filter/untainter or whatever that will make this safe. The best you can do is provide sensible default actions and make sure people realize that it isn't the entire solution. But I don't think throwing our hands in the air and doing nothing to help the developers is the answer just because there are such contexts that can't be solved by filters. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inclusion of PHP LiteSpeed SAPI in the standard PHP distribution?
Stanislav Malyshev wrote: Hi! I believe, besides the apache SAPI and fcgi SAPI, LiteSpeed SAPI is one of the top PHP SAPI being used in production environment. And LiteSpeed SAPI has the combination of best performance, configuration flexibility via .htaccess and enhanced security with SuEXEC. I did not look into the SAPI yet, but if it works good and conforms to PHP project reqs (code standards, license, etc.) then I see no reason not to add it, provided the popularity data and the fact that we have much more exotic SAPIs in the core. Well, popularity-wise it has about 0.003% of the web server market. So I wouldn't put too much stock in that. We also have yet to ever see a user request for it. You are right though, that we have other really odd SAPIs in the core, but that is mostly a result of never having figured out how build a sapi module standalone. Most of these really do belong in pecl if we could solve the standalone issue. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] '1.8' == 1.8 can return false
There is no bug here. Please read: http://docs.sun.com/source/806-3568/ncg_goldberg.html -Rasmus Todd Ruth wrote: I'm thinking there must be a bug in the heart of php causing this. I'll debug it, but I haven't looked at php source code in a few years and would like a tip as to which files are involved in evaluating ==. Here is a fragment from my code and the output: ... print pre\n; var_dump($max); var_dump($nms); var_dump($nms == $max); $max = (float)$max; $nms = (string)$nms; var_dump($max); var_dump($nms); var_dump($nms == $max); $max = (string)$max; $nms = (float)$nms; var_dump($max); var_dump($nms); var_dump($nms == $max); print /pre\n; ... string(3) 1.8 float(1.8) bool(false) float(1.8) string(3) 1.8 bool(true) string(3) 1.8 float(1.8) bool(true) I found this using php 5.2.3. I just upgraded to php 5.2.5 and am receiving the exact same result. Obviously, I can't reproduce it with a simple var_dump(1.8==1.8). :( I guess something is getting corrupted, and I will add debug output until I find out what (or Murphy removes the problem by adding debug output; then I'm not sure what I'll do). Thanks for any tips on which files I should look at it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hinting patch
Alain Williams wrote:
On Sat, Apr 26, 2008 at 05:11:29PM -0700, Chris Stockton wrote:
*cough* lambda *cough*
That would be nice, but the scoping of variables in PHP doesn't seem to
make that nice, the code below results in '' Undefined variable: aa ''
if I take the 'global' statement out, if I leave it in the echo in b()
shows it as the empty string.
Because aa is not global in your example. Variables are either global
or function-scoped in PHP. There is no such thing as a context or
parent scope which is what you are looking for here.
Getting this right would be nice as it would allow (what has been explained
to me at any rate) functional programming if a() returns an anonymous b().
The stuff below works in perl and python.
function a($aa) {
echo a called aa=$aa\n;
function b() {
global $aa;
echo in b aa=$aa\n;
}
b();
}
a('this is aa');
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Float comparison
Stefan Walk wrote: And you'll quickly see that the cast to string before comparision is a bad idea, because: $ php -dprecision=1 -r 'var_dump((string)1.4 == (string)1.1);' bool(true) Having display settings affect comparisions seems like a really bad idea to me ;) Yup, it would be a fatal flaw in the language if that ever came to be. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Some string changes/optimizations
A bit of a messy patch in that it doesn't have a single top-level
directory, but after hacking it, it applied. For others testing this,
make sure you run ext/tokenizer/tokenizer_data_gen.sh and of course
genfiles with the latest re2c.
I'm still not getting something that works though. Everything compiles
fine, but make test is throwing:
Fatal error: Invalid opcode 56/16/8. in
/Users/rasmus/php53/run-tests.php on line 547
Could we get a cleaner patch to have a look at? One that doesn't hurt
my brain quite as much to get working?
-Rasmus
Matt Wilmas wrote:
Hi all,
This patch... Saves one opcode per interpolated string by moving what was
the first ADD_STRING/ADD_VAR op into INIT_STRING; changes the
ADD_[CHAR|STRING|VAR] op types from (TMP, whatever) to (whatever,
UNUSED), since that seems to make more sense (see ADD_ARRAY_ELEMENT) and
simplifies things a bit, and saves some znode copying while compiling.
Next, after nowdoc support was added, I noticed it was mostly duplicate
heredoc code in the scanner, so I combined them for the most part, removing
the NOWDOC tokens, etc. Is that OK? It seems like they may have just been
there for the parser... but I updated the parser so that static heredocs
also work like nowdocs. Also removed the ST_START_[HEREDOC|NOWDOC] states
in the scanner, by doing their work (to catch immediate ending label) in the
initial heredoc rule.
While removing the NOWDOC references from zend_highlight.c, I made a little
change that I think improves (err... adds) highlighting of variables in
double-quoted strings, and makes literal text in heredocs/backticks the
correct highlight_string color. This makes coloring consistent across all
strings. :-) Before/after example: http://realplain.com/php/highlight.html
Speaking of backticks, while updating their parser grammar, they now behave
more precisely like shell_exec(), in that `cmd` (constant string) or `$cmd`
(one variable) won't use INIT_STRING and create a temporary variable...
Oh, almost forgot a couple things -- for HEAD: updated the yyless()
definition to match 5_3 (Nuno didn't get to it yet...), and moved
HANDLE_NEWLINES() so nowdoc text is copied first, otherwise the line number
would be off if there's an error in zend_copy_scanner_string. For 5_3:
there are NOWDOC references in tokenizer_data.c that the patch doesn't
remove, as I think it's supposed to be automated, though they're missing in
HEAD.
http://realplain.com/php/string_optimizations.diff
http://realplain.com/php/string_optimizations_5_3.diff
Thanks,
Matt
P.S. (for Marcus?), the ({LABEL}|([']{LABEL}['])|([]{LABEL}[])) part of
the heredoc rule crashed re2c (Windows) until I added the extra ( ), which
shouldn't be needed AFAIK and was fine with just 2 alternate matches...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Couple Windows build fixes
He never asked. Steph Fox wrote: Hi Hannes, CVS HEAD wasn't updated yet with the Windows build system because I was waiting for re2c development to settle down first, given that there was no re2c binary available that PHP could be built with at all for several weeks. But I agree with you, Matt should've been given access to everything from Day One, we all know he's brilliant :) - Steph - Original Message - From: Hannes Magnusson [EMAIL PROTECTED] To: Matt Wilmas [EMAIL PROTECTED] Cc: internals@lists.php.net Sent: Wednesday, May 07, 2008 9:16 PM Subject: Re: [PHP-DEV] Couple Windows build fixes Could someone explain to me why he doesn't have karma? -Hannes On Wed, May 7, 2008 at 5:28 PM, Matt Wilmas [EMAIL PROTECTED] wrote: Hi, One patch for 5.3 and one for HEAD, where they're not synched with the other. 5.3's math changes the other day missed one change to the php_* function (snaps are failing). And HEAD's Win Makefile still contains references to flex.skl after the re2c change, which causes an error for me, though its snaps are building, so maybe I'm the only one? - Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Couple Windows build fixes
Matt Wilmas wrote: BTW, if I had karma for Zend stuff, I guess I could fix Bugs #44681 and #44830 You already have Zend karma. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Curl POST emalloc leak?
Can someone spot why this code
(tested in both 5.2.5 and 5.3)
?php
function curl($post) {
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, www.fdhfkdsslak.bogus);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
if($post) {
curl_setopt($ch, CURLOPT_POST, 1);
for($args='',$i=0;$i75;$i++) $args .= a=$i;
curl_setopt($ch, CURLOPT_POSTFIELDS, $args);
unset($args);
}
curl_exec($ch);
curl_close($ch);
}
echo start .memory_get_usage().\n;
for($i=0;$i10;$i++) {
curl(0);
echo GET .memory_get_usage().\n;
}
for($i=0;$i10;$i++) {
curl(1);
echo POST .memory_get_usage().\n;
}
?
outputs:
start 326616
GET 327256
GET 327276
GET 327276
GET 327276
GET 327276
GET 327276
GET 327276
GET 327276
GET 327276
GET 327276
POST 327516
POST 327588
POST 327652
POST 327712
POST 327892
POST 328064
POST 328228
POST 328384
POST 328528
POST 328628
The leak size isn't constant even though my post data size is constant,
and the returned data (a dns error, presumably) is the same. Seems like
there is something weird in our postfield handling code in the curl
extension. Note also that it stabilizes somehow, although this is an
extremely simplified version of a long-running command-line script that
seems to grow on each post with wildly varying post data.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Curl POST emalloc leak?
Note that changing it to pass an array of post args instead of passing
it a string makes the leak go away.
This block of code in interface.c deals with the string case:
} else {
char *post = NULL;
convert_to_string_ex(zvalue);
post = estrndup(Z_STRVAL_PP(zvalue), Z_STRLEN_PP(zvalue));
zend_llist_add_element(ch-to_free.str, post);
error = curl_easy_setopt(ch-cp, CURLOPT_POSTFIELDS, post);
error = curl_easy_setopt(ch-cp, CURLOPT_POSTFIELDSIZE,
Z_STRLEN_PP(zvalue));
}
convert it to a string, estrndup it with the right args and add it to
the to_free.str list. Then in the destructor for the resource we have:
zend_llist_clean(ch-to_free.str);
So I am obviously missing something. That code looks fine.
-Rasmus
Daniel Brown wrote:
On Sat, May 17, 2008 at 3:04 AM, Rasmus Lerdorf [EMAIL PROTECTED] wrote:
start 326616
GET 327256
GET 327276
GET 327276
GET 327276
GET 327276
GET 327276
GET 327276
GET 327276
GET 327276
GET 327276
POST 327516
POST 327588
POST 327652
POST 327712
POST 327892
POST 328064
POST 328228
POST 328384
POST 328528
POST 328628
It's not a solution, Rasmus, but here's more data, taken from
5.2.4. The results were exactly the same, in the same order, after
running your code ten times.
start 57140
GET 57820
GET 57820
GET 57820
GET 57820
GET 57820
GET 57820
GET 57820
GET 57820
GET 57820
GET 57820
POST 58244
POST 58492
POST 58728
POST 58948
POST 59060
POST 59164
POST 59264
POST 59360
POST 59452
POST 59452
When changing the for() loop in the curl() function to this:
?php
for($args='',$i=0;$i75;$i++) {
$args .= $i == 0 ? a=$i : a=$i;
}
?
The results stabilize quicker:
start 57688
GET 58340
GET 58340
GET 58340
GET 58340
GET 58340
GET 58340
GET 58340
GET 58340
GET 58340
GET 58340
POST 58844
POST 59088
POST 59416
POST 59692
POST 59800
POST 59904
POST 59904
POST 59904
POST 59904
POST 59904
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Curl POST emalloc leak?
Cristian Rodríguez wrote:
Rasmus Lerdorf escribió:
Can someone spot why this code
(tested in both 5.2.5 and 5.3)
?php
function curl($post) {
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, www.fdhfkdsslak.bogus);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
if($post) {
curl_setopt($ch, CURLOPT_POST, 1);
for($args='',$i=0;$i75;$i++) $args .= a=$i;
curl_setopt($ch, CURLOPT_POSTFIELDS, $args);
unset($args);
}
curl_exec($ch);
curl_close($ch);
}
echo start .memory_get_usage().\n;
for($i=0;$i10;$i++) {
curl(0);
echo GET .memory_get_usage().\n;
}
for($i=0;$i10;$i++) {
curl(1);
echo POST .memory_get_usage().\n;
}
?
outputs:
for me
start 120400
GET 122624
GET 122624
GET 122624
GET 122624
GET 122624
GET 122624
GET 122624
GET 122624
GET 122624
GET 122624
POST 124968
POST 125928
POST 126608
POST 127272
POST 127920
POST 128552
POST 129168
POST 129768
POST 130352
POST 130920
when I request for $real_usage the results are constant..
Yes, I'm not saying there is a malloc leak. I haven't seen that, but
the emalloc leak means that eventually a script that repeatedly sends
post requests is going to hit the memory limit no matter how much
cleanup it does.
Note that you don't actually need to send the request. It looks like
repeatedly doing:
$ch = curl_init();
curl_setopt($ch, CURLOPT_POSTFIELDS, $args);
curl_close($ch);
Is enough to do it. Still looking at the code. Seems like
zend_llist_clean(ch-to_free.str); isn't doing the right thing somehow.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Curl POST emalloc leak?
Manuel Mausz wrote:
Rasmus Lerdorf wrote:
Note that you don't actually need to send the request. It looks like
repeatedly doing:
$ch = curl_init();
curl_setopt($ch, CURLOPT_POSTFIELDS, $args);
curl_close($ch);
Is enough to do it. Still looking at the code. Seems like
zend_llist_clean(ch-to_free.str); isn't doing the right thing somehow.
Is this really related to curl?
# php -n -r 'for($i=0;$i10;$i++) { for($args=,$j=0;$j75;$j++) $args
.= a=$j; unset($args); echo memory_get_usage().\n; }'
55872
56100
56172
56240
56304
56364
56420
56420
56420
56420
Yeah, I noticed that as well as I was simplifying things down further
and further. I have gotten to the point where my simplification has
lost track of the real problem, I think. My original complicated code
is leaking hundreds of K per iteration, and I assumed the smaller leak
in the simplified version was representative of that, but I don't think
it is. That would also why I haven't been able to find a bug in this
curl code I have been looking at.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Add deg2grad() and grad2deg() in PHP5.3
I think it is a bad idea to add functions for such a trivial math operation. It's not like people who need to do this can't do it today, and people who have already written code that needs it may very well have created userspace functions with these exact names which means their code will break when they upgrade PHP. I bet the number of people we piss off with this is greater than the number of people who will appreciate this tiny addition. -Rasmus Kalle Sommer Nielsen wrote: Hi Chris I didn't think of making an RFC for this mainly because its so small and one of the only use cases I could see would be the same as I see for rad2deg() and deg2rad(). And yes theres probably overflow and underflow just like in a couple of the other math functions. In my small perfect world I would do a check and add a warning or notice for incorrect values but Im sure that most around here wouldn't agree with that part ;) Kalle - Original Message - From: Christopher Jones [EMAIL PROTECTED] To: Kalle Sommer Nielsen [EMAIL PROTECTED] Cc: Guilherme Blanco [EMAIL PROTECTED]; PHP Developers Mailing List internals@lists.php.net Sent: Wednesday, May 21, 2008 3:24 AM Subject: Re: [PHP-DEV] Add deg2grad() and grad2deg() in PHP5.3 Even for small projects like this, we should get into the habit of creating an RFC on the Wiki. This is a way to explain the pros cons so the functionality can be evaluated. You can argue about the algorithm choice and point out weakness (overflow/underflow?). It allows us to see where the code will be added, and lets us see some usecases (that will become tests) etc. Chris Kalle Sommer Nielsen wrote: Ah Cheers I didn't think of number optimizations, but its done now Cheers Kalle - Original Message - From: Guilherme Blanco [EMAIL PROTECTED] To: Kalle Sommer Nielsen [EMAIL PROTECTED] Cc: PHP Developers Mailing List internals@lists.php.net Sent: Tuesday, May 20, 2008 8:47 PM Subject: Re: [PHP-DEV] Add deg2grad() and grad2deg() in PHP5.3 Hi... Are there any explanation why you used 360 and 400 and not optimized it? I know 1 full circle = 360 deg = 400 grads, but you can simplify it to: RETURN_DOUBLE((9 / 10) * deg); and... RETURN_DOUBLE((10 / 9) * grads); Regards, On Tue, May 20, 2008 at 3:22 PM, Kalle Sommer Nielsen [EMAIL PROTECTED] wrote: Greetings internals I've made two functions that allows convertion between degress and gradians, below is a pastebin of the functions as that would look in math.c: http://www.phpfi.com/318450 If no objections against it I will commit them in PHP_5_3 and HEAD and I will prepare some test cases for those aswell. Cheers Kalle -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9166-6902 MSN: [EMAIL PROTECTED] URL: http://blog.bisna.com Rio de Janeiro - RJ/Brazil -- No virus found in this incoming message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.21/1455 - Release Date: 19-05-2008 17:04 -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- No virus found in this incoming message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.21/1455 - Release Date: 19-05-2008 17:04 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] magic quotes finale
Lars Strojny wrote:
[ forgot to sent that to the list ]
Hi Philip,
Am Dienstag, den 20.05.2008, 12:55 -0700 schrieb Philip Olson:
[...]
PHP 5.3 is approaching fast, so let's conclude our dealings with
magical quotes... this should be the last time. Please have a look at
the following RFC and discuss it within this thread.
Magic Quotes in PHP 5.3 and beyond
- http://wiki.php.net/rfc/magicquotes
It recommends changes to both 5_3 and 6_0 branches, namely, removing
E_DEPRECATED from the get_ magical quote functions. Silence means
you're okay with the RFC being implemented.
Why should we leave get_magic_quotes_gpc()? If someone wants to be
backwards compatible, just use
if (function_exists('get_magic_quotes_gpc') and @get_magic_quotes_gpc())
Let's just add this to the manual, and everything is fine.
I don't see a problem with this at all and it has the advantage of
allowing use to remove all the traces of magic quotes in 6. Magic quotes
are considered a bad practice for a long time.
We have covered this a bunch of times already. magic_quotes_gpc are
gone, but we leave in the function that tells userspace code that they
are off. get_magic_quotes_gpc() will always return false which means
that thousands of applications out there will run unchanged and will
simply take the magic_quotes off code path.
I see absolutely no reason to force people to go through and change:
if(!get_magic_quotes_gpc())
to:
if (!function_exists('get_magic_quotes_gpc') || !get_magic_quotes_gpc())
when there is no technical reason to force them to do so. It is slower,
more verbose and completely useless.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC doesn't work on Windows?
Edward Z. Yang wrote: I don't really care either way, but if it's a well known fact, might as well stop trying. Does APC work on Windows? I recently submitted a patch to fix the snaps.php.net compilation of APC, but for any non-trivial script (interestingly enough, apc.php and and phpinfo() work fine), APC segfaults or otherwise fatally errors. Some errors I've seen include: [apc-error] Cannot redeclare class simpletest, referer: http://localhost/ on code that works perfectly without APC. I've scanned the bug list and there are quite a few reports of APC not working on Windows--so, is this generally known to be the case? We don't have any active developers contributing to APC on Windows at the moment. We try to not do stuff that will break Windows, but beyond that we rely on people interested in that platform to step up and help out. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Short syntax for array literals [...]
Stanislav Malyshev wrote: please add your votes I'm +1. I'm ok with it as well. Like I said over a year ago (*), it is a syntax very familiar to web developers and it feels natural to most people. (*) http://marc.info/?l=php-internalsm=117060700805108w=2 -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Short syntax for array literals [...]
Antony Dovgal wrote: On 28.05.2008 10:25, Stanislav Malyshev wrote: Hi! You do understand that you will not be able to use this syntax in your products for at least next 5 years without rising min required PHP version to the latest one, right? That makes it even more useless. That's great argument. So nice to know everything we do for 5.3 and 6 is completely useless :) No, THAT is really great argument. Compare everything we do with backward incompatible syntax that duplicates already existing one, but 5 characters shorter and find two differences. At a certain level everything is just syntax. There is nothing about a for loop that can't be done with a while loop. All OO code could be written procedurally as well. PHP has always made an effort to match the expectations of the typical web developer. 14 years ago the typical web developer knew Perl and C, so a lot of syntax was borrowed from those two languages. Then kids started coming out of universities with Java on their brains, so PHP adopted a Java-like OO syntax. Today's web developer is typically writing half their app in some variety of Ecmascript, either Javascript or Actionscript and this array syntax is second nature to all those folks. We have to be very conservative and pick our spots when it comes to evolving the language syntax, but we also can't bunker down and get stubborn and expect the world to stand still around us. If we had taken that same position at PHP 2, PHP 3, PHP 4 or even PHP 5 just because a handful of developers were content with the current state of things, we would be in serious trouble today. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Short syntax for array literals [...]
Mike wrote: In my opinion I don't think PHP would be where it is today if it wasn't for being so easy to learn and use. I attribute this directly to the fact that it didn't use a lot of syntax sugar that is unreadable and can't be Googled for. You can't Google [], and my guess is searching PHP.net for [] won't return anything useful either. Using Array() is SELF EXPLANATORY! Anyone can see that, search Google for Array and learn something about it. How many man hours are going to be wasted: 1. Searching for what the heck [] actually is. This No Magic mantra is something I have been using since day one to guide decisions like this in PHP. But I think you guys are misappropriating it. [] is already our array syntax. $a[1] assumes that the user realize that [] has something to do with arrays. If they don't, they are out of luck, because as you say, you can't search for [] and get something useful. But that's already the case and we are simply building on that existing knowledge. We have to have a minimum set of operators that we feel reasonable certain that people understand. ?: is also not easy to search for, yet we added this ternary shortcut. Likewise, is not easy to look up, but we added HEREDOC and more recently NOWDOC with this syntax. PHP is about building on the knowledge and experience of the typical target user. This target user changes slowly as we all get older and the industry we are in changes and we need to recognize that and adapt the language appropriately. What is appropriate is of course a really hard call which is what this is all about. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS Account Request: baptiste750
Actually, checking through my group@ archive, I don't see 2 messages from you. The only one I see from you is one from June 9 complaining that your cvs account wasn't granted. I see that someone has approved your account now. -Rasmus Antony Dovgal wrote: On 11.06.2008 22:44, Baptiste Autin wrote: This is my third try to get a CVS account through this webform. I have never got any answer from you. I have also sent 2 emails to [EMAIL PROTECTED] Unfortunately, the only active person in PHP Group at the moment is Rasmus, no wonder you didn't get any reply. I have never got any answer from you. No answer means your email has been buried under tons of emails in internals@ (which is often overloaded because of yet another endless thread), it doesn't mean no or we ignore you. If you didn't get any reply, try asking one of PEAR maintainers, they can ping certain people in IRC or by other means and those in turn will approve your account. Could you please create my account? Sure. Just wait for people with enough karma to read your email. It'll happen soon. If it doesn't - send a reminder to the list. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] extensions status, to move to pecl or to drop
Pierre Joye wrote: Hi Lukas, On Sat, Jun 14, 2008 at 4:26 PM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: These extension seem widely used enough that we have to make it an effort to support them. If it is so widely used, why noone complains about this removal? Why there is nobody taking care of the bugs or sending patches? I don't think this argument works very well. If we were to apply that in general terms, we should probably drop Windows support completely because there are pretty much no Windows users taking care of bugs, nor sending patches. There are a couple, I don't want to make their contributions seem insignificant, but the ratio of users to contributors is terrible for the Windows platform. For something like the SNMP extension, it works ok. SNMP isn't exciting in any way. I did some work on it so it got to the point where it was useful to me, and there have been a couple of requests over the years to extend it, but I think for most people it does all it needs to do. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] cleaning up the functions - any volunteers?
Alexey Zakhlestin wrote: On 6/22/08, David Coallier [EMAIL PROTECTED] wrote: 2008/6/21 Alexey Zakhlestin [EMAIL PROTECTED]: I did curl for 5.3 I don't have karma. You do now. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] simple solution to another namespace conundrum?
Derick Rethans wrote: On Tue, 24 Jun 2008, Alexey Zakhlestin wrote: On Tue, Jun 24, 2008 at 6:36 PM, Derick Rethans [EMAIL PROTECTED] wrote: On Fri, 20 Jun 2008, Gregory Beaver wrote: The user is obviously intentionally creating a DateTime class, and doesn't care about the internal classname in this script. The attached patch against PHP_5_3 would fix the issue by eliminating the check for conflict with CG(class_table) in the global namespace for internal classes. It however preserves this check for userspace classes so that (for instance) php-src/tests/Zend/ns_030.phpt does not fail. The basic idea is that we do have control over the userspace classes we include, but have no control over the internal classes. I am not so sure this is a good idea. I mean, for the developer that writes the code it's obvious that his version of DateTime is used. But for a second developer to come back later this could be a great WTF factor a few years down the road - wondering why the DateTime documentation on php.net doesn't match with what the class does. it won't be a serious 'wtf', as on the top of the file, there would be some kind of use MySuperLibrary::DateTime; I know, but 400 lines down in the code you can't really see that. This addition might fix the immediate issue - but it doesn't make life easier for the developers that have to maintain the code. Even less if they're not aware that stuff is namespaced. If we don't allow it to work this way, then I really don't see the point in namespaces at all, which I assume is the point you are trying to make. But, assuming at this point that we do want namespaces, then we have to make them work, and by its very nature namespacing involves code obfuscation. With or without this change, having the same userspace functions in different namespaces provides the same level of code obfuscation where a line of code read in isolation is impossible to resolve without looking at its namespace context. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New flame
Rui, thanks for your efforts on this. And yes, it would be really good if you could encourage some people to write more tests for this feature. We were completely lost in trying to maintain compatibility with this because of the lack of tests and documentation. Now we have something to go on and hopefully the re2c guys can dig in and help you finalize this. It was the last major issue holding up 5.3. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Closures: updated proposal and patch
Looking through the closures patch, I would tend to agree. GC has certainly caused us way more headaches in APC-land than closures will, from the looks of it. -Rasmus Dmitry Stogov wrote: I don't see big problems with closures. The patch is simple and stable. It's main part isolated in zend_closures.c and it doesn't affect other parts of engine. I expect more problems with GC Thanks. Dmitry. Andi Gutmans wrote: I think given closures is in a pretty fully baked state (we had an exemplary process) the main questions to ask are: a) Assuming we are going through numerous beta and RC cycles for PHP 5.3, do we think that the time it would take for other features like namespaces, garbage collector to be fully tested and stabilize would allow for closures to stabilize too in that same time frame (i.e. would not push out a final release date for PHP 5.3)? b) Are the release managers willing to manage an additional major feature as part of the release process? I am not stating my opinion here because I could go either way although ultimately my bias is not to postpone a feature freeze nor a final release so it's really up to the release managers to decide on (1) and (2). Andi -Original Message- From: Dmitry Stogov [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2008 12:27 AM To: Lukas Kahwe Smith Cc: Christian Seiler; php-dev List Subject: Re: [PHP-DEV] [RFC] Closures: updated proposal and patch Hi Lukas, From my point of view the proposed closures concept is very consistent and implementation doesn't complicate the engine at all. The code without closures will work without any changes, but code with closures (instead of eval() and create_function()) will work significant faster as lambda function will be stored in opcode caches. Opcode caches don't even need to be modified to do that. BTW: I see you point of view and it makes sense. It's just pity that we will need to wait for closures additional year(s). Thanks. Dmitry. Lukas Kahwe Smith wrote: On 02.07.2008, at 13:41, Christian Seiler wrote: I've spoken to Dmitry and he said the patch will be committed to HEAD soon. Since both Dmitry and I still want to have it in 5_3 too, we'd want to ask for opinions on this again - especially since after quite a lot of thorough review and discussion on this list basically all the side-effects have been addressed and there are now quite a few tests that ensure the correct behaviour of closures. Also, the patch is now built in a way that the main functionality remains inside zend_closures.c, so any possible not yet encountered bug can be fixed without breaking binary compability. I talked to Johannes about this. It does indeed seem like this feature is in a very solid stage at this point. However the current version of the patch is still young. Also we already have such an insanely long list of new big features, that anything that will take even the slightest focus away on getting this long list rock solid will have to wait until 5.4. Even the most rock solid proposal is bound to have some small issues after all. So as things look atm, closures will have to wait until then. But cool features like closures, traits etc will undoubtedly increase the incentive to get working quickly on 5.4 and this can happen as soon as we have 5.3 out the door and working well for our user base. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.4.9
Derick Rethans wrote: On Mon, 7 Jul 2008, Marcus Boerger wrote: how about this. We edit php_config.h to be version 4.4.8pl1. Then provide a patch for download. All reasonable distributions will pick up that patch anyway. But at least we didn't do a release as we promised, we wouldn't. Uh, no. We didn't promise we wouldn't make releases. It clearly says that if there are security issues we look at them case-by-case to see if we should make a release. There are security issues, we make a release. There is nothing more to discuss about this. We did actually. The exact text from the announcement was: After 2007-12-31 there will be no more releases of PHP 4.4. We will continue to make critical security fixes available on a case-by-case basis until 2008-08-08. The two statements do contradict each other a little bit, and I am ok with another release, but technically Marcus is correct. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.4.9
Derick Rethans wrote: On Mon, 7 Jul 2008, Marcus Boerger wrote: how about this. We edit php_config.h to be version 4.4.8pl1. Then provide a patch for download. All reasonable distributions will pick up that patch anyway. But at least we didn't do a release as we promised, we wouldn't. Uh, no. We didn't promise we wouldn't make releases. It clearly says that if there are security issues we look at them case-by-case to see if we should make a release. There are security issues, we make a release. There is nothing more to discuss about this. We did actually. The exact text from the announcement was: After 2007-12-31 there will be no more releases of PHP 4.4. We will continue to make critical security fixes available on a case-by-case basis until 2008-08-08. The two statements do contradict each other a little bit, and I am ok with another release, but technically Marcus is correct. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Zend Signal Handling
Stanislav Malyshev wrote: Hi! I am proposing the following RFC to improve signal handling in the Zend Engine: http://wiki.php.net/rfc/zendsignals Looks good. If ti works, I don't think we need two signal models - new one would be OK. I'm not sure what happens with win32 though. Note that this is conceptually based on the Yahoo signal deferring mechanism. The Yahoo signal deferring code is a bit too platform-specific though, but I will walk through and see if any of the many gotchas we deal with need to be fixed in this stuff. Gopal knows this stuff as well. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] lstat call on each directory level
Amir Hardon wrote:
I've noticed a weird behavior when doing file access from PHP:
PHP seems to make an lstat call on each of the parent directories of the
accessed file, for example see this script:
?php
$fp=fopen(/var/www/metacafe/test,r);
fclose($fp);
?
When running with strace -e lstat I see this:
lstat(/var, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat(/var/www, {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0
lstat(/var/www/metacafe, {st_mode=S_IFDIR|0755, st_size=4096, ...}) =
0
lstat(/var/www/metacafe/test, 0x7fbfff9b10) = -1 ENOENT (No such file
or directory)
Measuring total syscalls time for an apache process on a production
server, I found out
that ~33% of the time it spends in syscalls is spent on lstat.
I did a pretty deep web search on the issue and came out with nothing.
I'll also note that I did a small experiment - moving our root portal
folder to /,
this gave an amazing performance improvement!
So my questions are:
What is the reason for doing these lstat calls?
How can it be disabled? if not by configuration, maybe by patching php
(can you direct me to where is this being done in php's source?)
That's a realpath() call and it should be getting cached by the realpath
cache, so if you are seeing these on every request, try increasing your
realpath_cache size in your .ini. Without checking the realpath, you
would be able to circumvent open_basedir checking really easily with a
symlink.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] lstat call on each directory level
Amir Hardon wrote:
On Tue, 2008-07-15 at 11:40 -0700, Rasmus Lerdorf wrote:
Amir Hardon wrote:
I've noticed a weird behavior when doing file access from PHP:
PHP seems to make an lstat call on each of the parent directories of the
accessed file, for example see this script:
?php
$fp=fopen(/var/www/metacafe/test,r);
fclose($fp);
?
When running with strace -e lstat I see this:
lstat(/var, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat(/var/www, {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0
lstat(/var/www/metacafe, {st_mode=S_IFDIR|0755, st_size=4096, ...}) =
0
lstat(/var/www/metacafe/test, 0x7fbfff9b10) = -1 ENOENT (No such file
or directory)
Measuring total syscalls time for an apache process on a production
server, I found out
that ~33% of the time it spends in syscalls is spent on lstat.
I did a pretty deep web search on the issue and came out with nothing.
I'll also note that I did a small experiment - moving our root portal
folder to /,
this gave an amazing performance improvement!
So my questions are:
What is the reason for doing these lstat calls?
How can it be disabled? if not by configuration, maybe by patching php
(can you direct me to where is this being done in php's source?)
That's a realpath() call and it should be getting cached by the realpath
cache, so if you are seeing these on every request, try increasing your
realpath_cache size in your .ini. Without checking the realpath, you
would be able to circumvent open_basedir checking really easily with a
symlink.
-Rasmus
I've already increased the realpath_cache to the point it didn't give
any more benefit(And it did give benefit),
but there are still many lstat calls, and still placing our portal dir
in the root directory gave a huge performance benefit(After fine-tuning
realpath_cache).
We don't use open_basedir.
I think it might be wise to make this dir check configurable, as the
performance impact is major.
Anyway - can you please direct me to the place where this check is made
in php's source, so I'll be able to disable it manually?
Well, it is used in other places too, like in figuring out _once paths.
Including the same file using different paths still needs to be caught.
Are you calling clearstatcache() manually anywhere? That blows away the
entire realpath cache and completely destroys your performance, so you
will want to avoid doing that very often.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] lstat call on each directory level
Lars Strojny wrote: Hi Rasmus, Am Dienstag, den 15.07.2008, 11:40 -0700 schrieb Rasmus Lerdorf: [...] That's a realpath() call and it should be getting cached by the realpath cache, so if you are seeing these on every request, try increasing your realpath_cache size in your .ini. Without checking the realpath, you would be able to circumvent open_basedir checking really easily with a symlink. Couldn't we do that check only if open_basedir is active? Like I said, it is used for other things too, like include_once filename resolution. Check the code. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] lstat call on each directory level
Arvids Godjuks wrote: Hello. I think this should be optimized. I'm not an expert ofcourse, but as I understood there is only one case witch need a special treatment - require/include _one when a file with equal contents is included from different directories. You can make a switch witch controls if lstat is made or not in these cases. People who know what they are doing will switch it to off and make sure their includes don't result in Fatal error (anyway, to my opinion it is bad desing if such thing happens). Ofcourse open_basedir users will don't have any benefit from it, but that's their choise. So I think you should think it out and make this optimization to 5.3 release. It would be great optimization, IMHO. But all these lstats should be getting cached, so I don't see how it would affect performance very much. If you are blowing your realpath cache, you need to take a look at why that is happening. We probably should disconnect clearstatcache() from the realpath_cache, and we could perhaps look at doing partial path caches through our own realpath implementation. The other thing that can suck is when you have an include_path miss. We don't cache misses like this, so if you are relying on include_path to find your files and you don't hit it on the first try, you are going to see a bunch of stats. But that is again something that is easily fixed by not writing crappy code. I think that breaking code that looks like this: require_once './a.inc'; require_once 'a.inc'; require_once '../a.inc'; require_once 'includes/a.inc'; when these all refer to the same a.inc file depending on where the parent file is and what the coder had for breakfast that morning would be a very bad idea. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] lstat call on each directory level
Amir Hardon wrote: On Wed, 2008-07-16 at 06:45 -0700, Rasmus Lerdorf wrote: Arvids Godjuks wrote: Hello. I think this should be optimized. I'm not an expert ofcourse, but as I understood there is only one case witch need a special treatment - require/include _one when a file with equal contents is included from different directories. You can make a switch witch controls if lstat is made or not in these cases. People who know what they are doing will switch it to off and make sure their includes don't result in Fatal error (anyway, to my opinion it is bad desing if such thing happens). Ofcourse open_basedir users will don't have any benefit from it, but that's their choise. So I think you should think it out and make this optimization to 5.3 release. It would be great optimization, IMHO. But all these lstats should be getting cached, so I don't see how it would affect performance very much. If you are blowing your realpath cache, you need to take a look at why that is happening. We probably should disconnect clearstatcache() from the realpath_cache, and we could perhaps look at doing partial path caches through our own realpath implementation. The other thing that can suck is when you have an include_path miss. We don't cache misses like this, so if you are relying on include_path to find your files and you don't hit it on the first try, you are going to see a bunch of stats. But that is again something that is easily fixed by not writing crappy code. I think that breaking code that looks like this: require_once './a.inc'; require_once 'a.inc'; require_once '../a.inc'; require_once 'includes/a.inc'; when these all refer to the same a.inc file depending on where the parent file is and what the coder had for breakfast that morning would be a very bad idea. -Rasmus Since the realpath cache is only relevant for a single request(right?), removing these lstats calls will a major benefit. No, of course not. It would be a useless cache if that was the case. The cache spans requests. Before moving our portal dir to the / dir, ~40% of our page requests were slow on the server side (I'm not sure if my company policies allow me to expose exactly what is considered slow), after moving it ~20% of the page requests were slow! this is significant. And there are still many lstat calls made inside our portal's directory tree. Yes, you need to figure out why you are not hitting the cache, or why you are seeing so many lstat calls. There are 3 main possibilities: 1. You have a crapload of files and they simply won't fit in the cache. Increase your realpath_cache size to address this. 2. Something somewhere is calling clearstatcache() often. Don't do that. 3. You are relying on include_path to find your files and you are always missing the file on the first couple of tries. Hint, it is a good idea to get rid of . from the beginning of your include_path and always use ./foo.inc to include something from the current directory instead of having include_path do this for you. That lets you put some other path first in the include_path and you can then include path/file.inc and have that be relative to the first path in your include_path. And make sure all your include_path includes are relative to that first path. Never include something that will hit the second component of include_path. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] lstat call on each directory level
Arvids Godjuks wrote:
Yesterday I made some tests on my site with strace to see how much lstat
I have and how can I optimize them. Well, I managed to get rid of them
almost at all, but now I have some questions about include_path and
including files based on current dir.
I have such structire of files
/home/file/www (that's my site root dir)
include/
- bittorrent
- global.php
lang/
- eng.lang
- rus.lang
index.php
My files are
index.php ---
require './include/bittorrent.php';
--- common.php ---
require './include/global.php';
require './lang/eng.lang';
And some other files from include dir
Default include path is .:/usr/share/php5:/usr/share/php and if I
don't change it it results in a bunch of lstat. Here is the trace
http://pastebin.com/m37704b6a
The thing I don't understand from trace is WHY it tests include path
BEFORE the ./ ? Why it doesn't try to load file based on relative path
first (it should hit it on first try) and then use include path?
Ok, I make in bittorrent.php - set_include_path('/home/file/www');
The only lstat i have now is
lstat(/home, {st_mode=S_IFDIR|0755, st_size=144, ...}) = 0
lstat(/home/file, {st_mode=S_IFDIR|0755, st_size=1112, ...}) = 0
lstat(/home/file/www, {st_mode=S_IFDIR|0755, st_size=11880, ...}) = 0
lstat(/home/file/www/bittorrent.php, 0x7fff8d95cca0) = -1 ENOENT (No
such file or directory)
open(/home/file/www/bittorrent.php, O_RDONLY) = -1 ENOENT (No such
file or directory)
open(/home/file/www/include/bittorrent.php, O_RDONLY) = 14
So the question is - why are they happen at all, if I include
bittorrent.php as require './include/bittorrent.php' in index.php. As i
understand it should hit the right folder from first time. Could you,
please, explain how all this works, because as it turned out it is not
so obvious as it should be...
I have PHP 5.2.6 (Gentoo Linux package name is dev-php5/php-5.2.6-r2)
and lighttpd 1.5
You missed something. You have an include 'bittorrent.php' in there
somewhere. This thread would really be more appropriate on php-users at
this point.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New string functions: str_startswith() and str_endswith()
For the start of the string: substr($haystack,0,strlen($needle)) == $needle And for the end of the string: substr($haystack,-strlen($needle)) == $needle For case-insensitivity, just strtolower both. Writing built-in functions for something that can be done with trivial one-liners isn't something we typically do. -Rasmus Lars Strojny wrote: Hi Martin, first of all, thanks for you work! A few comments below. Am Samstag, den 19.07.2008, 14:55 +0200 schrieb Martin Jansen: Attached you'll find a patch against PHP_5_3 that implements two new string functions: str_startswith(haystack, needle [, case_sensitivity]) That's in my opinion too easy to solve with strpos($haystack, $needle) === 0. checks if haystack starts with needle. The check is performed case-insensitively, but this can be overridden by passing TRUE as the value for the third parameter. The second function str_endswith(haystack, needle [, case_sensitivity]) [...] Suffix checking is indeed a bit harder. But I'm not sure if we should introduce a function for every special case. Suffix verification often is about verifying file extensions. That could be easily solved with pathinfo() (and to make that easier, it would be more helpful to allow the engine to directly access returned arrays like pathinfo($file)['extension']). The other thing I would love to see is something I really love in Ruby: you have various ways to work with substrings[1]. For example you can do foobar[-3,3] == bar to check the suffix. That's in my opinion much easier and flexible. So -1 from me for the new string functions, but +1 for niftier variants to work with offsets. [1] http://pleac.sourceforge.net/pleac_ruby/strings.html cu, Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New string functions: str_startswith() and str_endswith()
I agree that many existing functions can be implemented with a combination of others, but in this case it is really just one call. The strlen() call is almost free, and in many cases you wouldn't even use it. If you are looking for .php files, for example: if(str_endswith($path,'.php')) vs. if(substr($path,-4)=='.php')) I just don't see that this is solving any real painpoint. -Rasmus Stan Vassilev | FM wrote: Hi, Actually starts with and ends with is a very common case. I see your concerns, but I can see instantly quite a lot of places in my code where I'd use those. And I bet it'll be faster too. Many of the string functions can be replicated with one-liners using other string functions, same for array functions. I still think a very common case should be addressed natively. Regards, Stan Vassilev For the start of the string: substr($haystack,0,strlen($needle)) == $needle And for the end of the string: substr($haystack,-strlen($needle)) == $needle For case-insensitivity, just strtolower both. Writing built-in functions for something that can be done with trivial one-liners isn't something we typically do. -Rasmus Lars Strojny wrote: Hi Martin, first of all, thanks for you work! A few comments below. Am Samstag, den 19.07.2008, 14:55 +0200 schrieb Martin Jansen: Attached you'll find a patch against PHP_5_3 that implements two new string functions: str_startswith(haystack, needle [, case_sensitivity]) That's in my opinion too easy to solve with strpos($haystack, $needle) === 0. checks if haystack starts with needle. The check is performed case-insensitively, but this can be overridden by passing TRUE as the value for the third parameter. The second function str_endswith(haystack, needle [, case_sensitivity]) [...] Suffix checking is indeed a bit harder. But I'm not sure if we should introduce a function for every special case. Suffix verification often is about verifying file extensions. That could be easily solved with pathinfo() (and to make that easier, it would be more helpful to allow the engine to directly access returned arrays like pathinfo($file)['extension']). The other thing I would love to see is something I really love in Ruby: you have various ways to work with substrings[1]. For example you can do foobar[-3,3] == bar to check the suffix. That's in my opinion much easier and flexible. So -1 from me for the new string functions, but +1 for niftier variants to work with offsets. [1] http://pleac.sourceforge.net/pleac_ruby/strings.html cu, Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Syscall Optimization
On most requests we end up with a getcwd() followed by a chdir() to the
same directory and then a second chdir() to the same directory at the
end of the request:
getcwd(/var/www, 4095) = 14
chdir(/var/www) = 0
... request is processed ...
chdir(/var/www) = 0
which comes from this code in main.c:
if ((primary_file-type == ZEND_HANDLE_FILENAME ||
primary_file-type == ZEND_HANDLE_STREAM) primary_file-filename) {
VCWD_GETCWD(old_cwd, OLD_CWD_SIZE-1);
VCWD_CHDIR_FILE(primary_file-filename);
}
...
if (old_cwd[0] != '\0') {
VCWD_CHDIR(old_cwd);
}
free_alloca(old_cwd, use_heap);
We probably can't get rid of the second chdir() since we should preserve
our sandbox and leave the process in the same state that we started in
and all sorts of things along the way could theoretically have changed
the cwd. But we should be able to get rid of that first chdir() when
the directory we want to change to is the same as old_cwd.
Perhaps a new macro to not break other code using it?
VCWD_GETCWD_CHDIR_FILE(primary_file-filename, old_cwd, OLD_CWD_SIZE-1)
And have this macro only do the chdir if the directories are different.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New string functions: str_startswith() and str_endswith()
Brian Moon wrote: Stan Vassilev | FM wrote: I'm particularly for begins/endswith() function as I do this all over my code and I'd appreciate the simplification and free extra performance. I really don't mean to be rude here, but shorter and less typing !== performance gain. The PHP string functions are very fast. And if you are looking to improve your applications performance by using different string functions, you are likely looking in the wrong place. It also isn't any shorter: if(str_endswith($path,'.php')) vs. if(substr($path,-4)=='.php') And there would be no performance gain since it can be done in a single call now and the code would do pretty much exactly what substr does. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Volunteers for Subversion 1.5 conversion of cvs.php.net?
Now that Subversion 1.5 has been out for a little while and it is at the point where it might actually have some benefit to us, do we have some volunteers who have some time to try converting over the repository and all the post-commit and ACL rules from CVSROOT? Talking to people here at OSCON, the consensus seems to be that moving to Subversion at this point would worthwhile. The Git/Bzr/Merc folks have better tools to deal with a central svn repository than cvs at this point, and the svn workflow and Windows tools won't leave all our less technical committers floundering. I think the most convenient approach would be to do the conversion directly on the cvs.php.net machine and run the two side-by-side with periodic imports to svn while we test things and then a freeze and a switchover at some point. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Volunteers for Subversion 1.5 conversion of cvs.php.net?
Gwynne Raskind wrote: On Jul 24, 2008, at 8:05 PM, Rasmus Lerdorf wrote: Now that Subversion 1.5 has been out for a little while and it is at the point where it might actually have some benefit to us, do we have some volunteers who have some time to try converting over the repository and all the post-commit and ACL rules from CVSROOT? Talking to people here at OSCON, the consensus seems to be that moving to Subversion at this point would worthwhile. The Git/Bzr/Merc folks have better tools to deal with a central svn repository than cvs at this point, and the svn workflow and Windows tools won't leave all our less technical committers floundering. I think the most convenient approach would be to do the conversion directly on the cvs.php.net machine and run the two side-by-side with periodic imports to svn while we test things and then a freeze and a switchover at some point. See my Wiki on it at http://wiki.php.net/svnmigration, I'm planning to get back to it this weekend. Yes, I read that. But the conversion of the repository itself is only half the battle. There are a bunch of scripts in CVSROOT that need to be ported over to SVN somehow. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
marius popa wrote: On Fri, Jul 25, 2008 at 5:06 AM, Gwynne Raskind [EMAIL PROTECTED] wrote: At this point it's clear that moving from CVS to SVN for PHP has become a more or less official project. As such, there is a new mailing list isn't better to migrate to git or mercurial ? http://weblog.rubyonrails.org/2008/4/2/rails-is-moving-from-svn-to-git it's faster and better on my opinion (why wasting time to convert later from svn to git ) We have 1000+ people with commit access, many of whom are not very technical. We need something with mature Windows tools for those folks and something that isn't completely different to their way of working. The git and hg integration with svn is also good so any developer who prefers to have a local repository can very easily use either git or hg and easily merge into the central svn repository. We don't need to be on the bleeding edge of revision control systems. In fact, I prefer to very much be a very very slow follower in that particular area to make sure that all tools are extremely mature by the time we go anywhere near them. The last thing we want to do is slow down PHP development any further by forcing people to fight with a bleeding edge set of tools. When a winner eventually emerges in the de-centralized revision control world and everyone creates tools for all the various platforms, we'll have a look, but I predict that to be years away. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS to SVN Migration
Lukas Kahwe Smith wrote: The git and hg integration with svn is also good so any developer who prefers to have a local repository can very easily use either git or hg and easily merge into the central svn repository. However I think we should provide the infrastructure for developers to setup a dvcs. I dont know if we want to standardize on a specific one. But collaboration on exterimental stuff that requires a dvcs should be possible on php.net servers. What do you mean by that? hgsvn and git-svn don't need any server-side support to enable you to work locally and do local git or hg checkins and then sync to the central svn repository when you are ready. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSoC Update (XDebug project)
Chung-Yang(Kenneth) Lee wrote: Most of the functionalities were done. Users can now upload a file to get parsed and visualized from the interface. After the file is parsed, the interface will display information like function names, total self cost in ms and by percentage, invocation count. The information is displayed in a grid after the file is parsed and users can perform sorting, grouping / ungrouping, and moving columns on the grid as for now. This sounds cool. Can we try it somewhere? -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PEAR Build fix
Could someone please fix this:
Generating phar.php
Generating phar.phar
Pear package PHP_Archive found: API Version: 1.0.0 (stable).
Pear package PHP_Archive or Archive.php class file not found.
clicommand.inc
directorygraphiterator.inc
directorytreeiterator.inc
invertedregexiterator.inc
pharcommand.inc
phar.inc
Build complete.
Don't forget to run 'make test'.
The problem is that in phar.php it does a
pear list-files PHP_Archive
This outputs a bunch of filenames ending with:
test /usr/local/lib/php/test/PHP_Archive/tests/test_require.php
test /usr/local/lib/php/test/PHP_Archive/tests/test_tar.tar
test /usr/local/lib/php/test/PHP_Archive/tests/twophars.phpt
php /usr/local/lib/php/PHP/Archive.php
in phar.php the regex to check if Archive.php exists looks like this:
if (preg_match(,^php[ \t]+([^
\t].*pear[/]PHP[/]Archive.php)$,, $ent, $matches)) {
which is obviously not going to match that last Archive.php line. So,
two fixes here. First, fix the error message to more accurately
describe what is going on. And second, assuming
/usr/local/lib/php/PHP/Archive.php is the right file here, fix the regex.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Zend Signal Handling
Dmitry Stogov wrote: I see several issues with the patch 1) It assumes that web server (and webserver extensions) won't setup any signal handlers after PHP startup. This assumption may be wrong. It may be. But there is really no way around that. That's why we talked about having an optional request shutdown check that would tell you if something hi-jacked one of the signals so at least you know that this is happening. 2) It is incompatible with ext/pcntl 3) It breaks 3 tests (in debug mode) tests/classes/destructor_visibility_001.phpt tests/func/005a.phpt ext/standard/tests/general_functions/phpinfo.phpt 4) I would also see the patch for HEAD (to commit them together) I think it's not a good idea to commit it in this state. Correct me, if I'm wrong. I've done just a very quick review. It is much better than what we have now. We currently have nothing that provides any sort of critical section protection from signals. This patch at least gives us this for most cases. The exceptions being weird extensions that set their own signal handlers and pcntl stuff that tries to fiddle with them directly. But in both cases I would argue that you get what you deserve if you are doing that. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Making PHP upload hooks available through session variables?
Johannes Schlüter wrote: Hi, On Wed, 2008-07-30 at 13:46 -0700, Tore B. Krudtaa wrote: As most of you probably know Rasmus Lerdorf made som upload hooks available in PHP 5.2 some long time back. This was great news for those that wanted more control of uploads and/or wanted to give real time feedback to client about upload progress, and had APC installed as well. Most PHP installations does not have APC installed, so therefore the upload hooks are not available. I would like to be able to use the upload hooks without installing the APC. There's also a package called uploadprogress or something like that in PECL. I would eventually like to be able to use those upload hooks using session variables. I think that's not possible in a good way as the uploading process would have to open and parse the session file, update the status, serialize it and store it again to disk everytime the status changes (aka. every few bytes received), APC does that using shared memory, uploadprogress using special files in /tmp, I think. The real solution here would be to have any extension that handles any sort of storage implement these hooks. The memcached extension, would be a good start. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_3) / NEWS
Jani Taskinen wrote: -- Changed PCRE, Reflection and SPL extensions to always be enabled. (Marcus) +- Changed PCRE, Reflection and SPL extensions to be always enabled. (Marcus) That was amazingly pedantic, even for you Jani. Captain Kirk blasted away the split infinitive rule when he decided to boldly go where no man had gone before. The rule was actually outdated years before Star Trek. You can read all about it at http://en.wikipedia.org/wiki/Split_infinitive As far as I am concerned, Marcus' split infinitive version of that sentence sounds less awkward. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] clearstatcache change
I think we either need to make clearstatcache() not affect the realpath cache, or we should add an optional argument to it to specify whether or not the realpath cache should be cleared as well. The realpath cache makes a huge difference on includes and having the cache blown away by a script calling clearstatcache() really hurts. In almost all cases the script is doing it to clear the stat cache for some local file it is doing stuff to and the author has no idea that she is blowing away the realpath_cache as well. And if that script is run on every request, the realpath_cache becomes completely useless. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] clearstatcache change
Johannes Schlüter wrote: On Wed, 2008-08-06 at 21:00 +0200, Arnaud Le Blanc wrote: btw. I just noticed chroot() calls this realpath_cache_clean()..intentional? I'd assume that, as /foo inside a chroot is different from /foo outside... Also some streams stuff uses the php_clear_stat_cache() func but those should propably use the realpatch_cache_del() instead and not blow away whole cache? Yes, I think too. I added that to your patch: http://arnaud.lb.s3.amazonaws.com/clearstatcache_optional_params.patch :) It also adds the filename argument to clearstatcache([bool clear_realpath_cache[, filename]]) I reply to myself, actually this may cause troubles to not clear the full cache in plain_wrapper.c :/ I updated the patch, just left the filename argument to clearstatcache(). If you fix the arginfo like Hannes it's, good. If the name of the second parameter in the proto (filename) is the same as in the implementation (pathname) it might even be a bit better :-) Looks good to me too. Don't forget the [DOC] comment on the commit :) -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] include bug in 5.3
Christian Stocker wrote:
Hi
Since quite some time (weeks), I have this very strange and annoying
include bug in 5.3-dev and now I think is the time to report it :)
The reproducable script is here:
http://trash.chregu.tv/include-bug.php.txt
In short, when I have
foo/alpha (empty)
bar/alpha/bar.php
and set the include path to foo/:bar/
and then do
include(alpha/bar.php);
it throws an not-found error.
But if I remove foo/alpha, it works correctly.
In the meantime (while I wrote this), I found a similar bug report:
http://bugs.php.net/bug.php?id=45044
and added my script.
Can please someone look into that, it's not an area where I feel
comfortable :)
I have tried to reproduce this on both OSX and FreeBSD and so far I
haven't had any luck.
This is what I have:
11:18am trainburn-lm:~/Web l foo/alpha/
total 0
drwxr-xr-x 2 rasmus users 68 Aug 7 11:10 ./
drwxr-xr-x 3 rasmus users 102 Aug 7 11:10 ../
11:18am trainburn-lm:~/Web l bar/alpha/
total 8
drwxr-xr-x 3 rasmus users 102 Aug 7 11:10 ./
drwxr-xr-x 3 rasmus users 102 Aug 7 11:10 ../
-rw-r--r-- 1 rasmus users 12 Aug 7 11:10 bar.php
11:18am trainburn-lm:~/Web cat foo.php
?php
ini_set('include_path','foo/:bar/');
include alpha/bar.php;
?
I am getting the contents of bar.php quite nicely both from the command
line and through Apache. This should be really easy to debug with gdb,
but it requires a reproducable case.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] include bug in 5.3
Felipe Pena wrote:
Em Qui, 2008-08-07 às 20:55 +0200, Hannes Magnusson escreveu:
On Thu, Aug 7, 2008 at 20:20, Rasmus Lerdorf[EMAIL PROTECTED] wrote:
Christian Stocker wrote:
Hi
Since quite some time (weeks), I have this very strange and annoying
include bug in 5.3-dev and now I think is the time to report it :)
The reproducable script is here:
http://trash.chregu.tv/include-bug.php.txt
When trying debug it days ago, I noticed add that:
+++ TSRM/tsrm_virtual_cwd.c 4 Jul 2008 03:05:16 -
@@ -557,9 +557,11 @@ CWD_API int virtual_file_ex(cwd_state *s
if (use_realpath != CWD_EXPAND) {
#if !defined(TSRM_WIN32) !defined(NETWARE)
char resolved_path[MAXPATHLEN];
+ printf( %s\n, path);
if (!realpath(path, resolved_path)) { /* Note: Not
threadsafe on older *BSD's */
+ printf( 1\n);
if (use_realpath == CWD_REALPATH) {
+ printf( 2\n);
LINUX:
/home/felipe/php5/sapi/cli/php
/home/felipe/php5/sapi/cli/php
/home/felipe/php5/sapi/cli/php-cli.ini
1
/usr/local/lib/php-cli.ini
1
/home/felipe/php5/sapi/cli/php.ini
1
/usr/local/lib/php.ini
/usr/local/lib/php.ini
/home/felipe/test/test.php
/home/felipe/./foo.php
1
2
/usr/local/lib/php/foo.php
1
2
/home/felipe/test/foo.php
foo
--
BSD:
/usr/home/felipe/php5/sapi/cli/php
/usr/home/felipe/test/test.php
/usr/home/felipe/./foo.php
Warning: include(/usr/home/felipe/foo.php): failed to open stream: No
such file or directory in /usr/home/felipe/test/test.php on line 1
Warning: include(): Failed opening 'foo.php' for inclusion
(include_path='.:/usr/local/lib/php') in /usr/home/felipe/test/test.php
on line 1
That's not the same thing though. Your case seems to show that it isn't
using the include_path at all. On BSD after checking ./foo.php why
doesn't it continue on to /usr/local/lib/php/foo.php? It certain does
for me here.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] include bug in 5.3
Dmitry Stogov wrote: Hi, The attached patch is going to fix the problem. It implements its own realpath() function, so we won't depend on system anymore. It also improve realpath cache usage by caching intermediate results. Very nice. The intermediate caching is going to drastically reduce the amount of memory we need for the cache. I have seen a number of cases where sites had to increase the realpath cache size by quite a bit. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
