Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
Hi List, Wouldn't it be possible to have it default to the system's timezone if available? Most software seems to be able to use the correct timezone. From a user's pov it is strange that PHP is pretty much the only service which has to have it's own timezone configuration. I appreciate the current state of things. There's only one thing worse than having an operation return the wrong answer, and that's having it return the wrong answer silently. The latter can happen with the wrong TZ setting. I've got a myriad of different systems to deal with, some distro-based installs of PHP separating out php.ini for the CLI, and for Apache. Other installs using the same file like I expect. I make mistakes. I'm currently maintaining ~100 servers from a slew of different providers around the world. The clock is hard enough to trust, let alone what the system's TZ setting is. The #1 answer from providers when we complain that the clock is 2 hours off is to just change the timezone. When I get the blast of warnings, I'm shaken from complacency to invest one minute to find the right file, add the setting, and forget about it once more. paul
Re: [PHP-DEV] PHP User Survey
customers are trapped. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=**contacthttp://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.**ukhttp://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Paul Reinheimer Zend Certified Engineer
[PHP-DEV] PHP User Survey
Hi All, My apologies for the intrusion, I'll keep this brief. In many discussions over the past few months there has been talk about what the community at large needs. Pierre said just earlier today: I would also say it us time for us to get back in sync with the communities needs. I am not talking about the last days RFCs but in general. The other point that comes up is the difficulty in reaching a large portion of the community. They don't come to conferences, they don't sit on this list, they don't go to user groups. They work with PHP for months or years, but the rest of the community doesn't even know who they are. I believe Rasmus has mentioned this on a few occasions. So my suggestion is simple, let's ask them: What they want, What they need, how they installed PHP (source, rpm, deb, provided by hosting provider, Zend Server), etc. Let's create a survey, and link to it prominently on php.net. I considered just writing a survey myself, but even if everyone I knew tweeted it I'd still lack the reach to hit those outside the traditional community. While this is clearly not a suggestion to change PHP, i'll write this up in RFC format if there's interest. Should give people an opportunity to discuss questions and such. thanks for your time paul -- Paul Reinheimer
Re: [PHP-DEV] JPEG Upload
I dealt with jpegs with injected metadata quite a bit at a previous employer. In the end we ended up confirming the file was a proper image with the filetype functions, then stripping the metadata using some command line tools, and finally using a blacklist for key strings (like ?php) that could show up in the file. paul -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] readfile() memory usage
Hi Everyone So, I think we're back to urban legend territory. I've updated the documentation for readfile() to help send more people down the path of checking for output buffering, and disabling that rather than contriving loops with fread(). http://docs.php.net/readfile paul -- Paul Reinheimer -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] readfile() memory usage
Hi Larry,
Fascinating. I even verified the md5sum of the file I got on the other end
just to be sure. I'll hold off on the blog post then. :-) I look forward
to your test setup.
The server in question is still on PHP 5.2.13
Script:
?php
ini_set('memory_limit', '8M');
$name = uniqid() . .zip;
header('Content-type: application/zip');
header(Content-Disposition: attachment; filename=\$name\);
readfile('../../filestorage/4f9e9e3b9bcff.zip');
File Information:
[user@host public]$ ls -alh ../../filestorage/4f9e9e3b9bcff.zip
-rw-r--r-- 1 apache apache 27M Apr 30 10:14 ../../filestorage/4f9e9e3b9bcff.zip
Error:
[Tue May 01 09:30:48 2012] [error] [client 198.136.162.2] PHP Fatal
error: Allowed memory size of 8388608 bytes exhausted (tried to
allocate 27617281 bytes) in
/home/lots/of/path.org/stuff/public/rf822.php on line 6
I'll try something newer, but I wanted to prove myself not crazy and
do it on the server in question first.
paul
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] readfile() memory usage
Hi All, Unfortunately, you've ignored Uwe's e-mail... The problem is not the PHP version; the problem is that you're buffering unlimited amounts of data. Check your configuration and make sure ob_get_level() returns 0. My apologies in the delay, ob_get_level() returns 1, good catch. phpinfo() reports output_buffering as 4096 Does this push what I'm getting into expected behaviour? paul -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] readfile() memory usage
Hi, It sounds like it. In that case the memory spike is happening in the output buffer, where the file is streamed into by readfile() in 8K chunks until the output buffer explodes. :-) So, I think we're back to urban legend territory. That's good to know. Thanks, and my apologies for adding confusion to the issue. One question, with a value of 4096 for the ini directive, shouldn't it be flushing data to the client long before I run into memory issues? What have I missed here. thanks paul -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] readfile() memory usage
Hi Larry, 4) So given #2 and #3, the readfile() will kill your memory, don't use it line is a persistent urban legend that belongs on Snopes as debunked. Looping on fread() for performance is a red herring. I implemented this earlier this very year to avoid memory issues (a quick look at project history shows me working on it in January). The difference between using readfile, and some convoluted method from the documentation comments was clear and immediate: corrupted download with out of memory error in the logs, to things working just fine. Let me re-create with a simple test script and share my server details before we call snopes :) paul -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
Hi All, In parallel I'd also see if there are any key extensions which we think are mainstream, stable and well maintained enough to be included. For example, http comes to mind. With regards to the http extension, I've been using it in production for a while, but ran into an issue where it segfaulted and killed the worker when parsing incomplete headers (as returned by some servers) bug 19390 [1]. While this has been resolved in a more recent release, the thought of things segfaulting makes me nervous. Are there additional hoops for pecl extensions to jump through to 'prove' their stability before making it into the core? thanks paul [1] http://pecl.php.net/bugs/bug.php?id=19390 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: What's up with Quercus?
Hi, And so far as PHP6... a lot of the features that were supposed to be in PHP6 actually ended up in 5.3. So rather than canceled, no longer necessary might be a better description of what happened to PHP6. With the loss of Unicode (which now lacks even an implementation plan) no longer necessary seems wildly inaccurate. I've no wish to pull this thread off topic, but far too many developers and teams were anticipating that feature to let that statement slide uncontested. paul -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] deprecation status of $str{42} versus $str[42]
So unless this thread changes something, an E_DEPRECATED will be added to
HEAD (PHP 6.0.0) for curly brace string access ( $str{42} ) and the
documentation will remain as is.
I'm well aware that I don't get a vote, so I'll skip the +1.
That being said, I'd like to argue in favour of depricating the curly
braces. My reasoning is simple, every time a new feature is up for inclusion
in the language hours/days/weeks/months are spent arguing over what
characters/operators will be used in order to identify the new feature.
We're out of characters.Killing the duplication now means that when PHP 7
roles around we've got two characters we can use for some killer new
feature.
(I'll go back to the quiet corner now)
paul ([EMAIL PROTECTED])
--
Paul Reinheimer
Re: [PHP-DEV] Internals read-only
Hi This is a subject I have discussed with several parties over the past year, and I meet the fact that someone has finally suggested it publicly with simultaneous relief and concern. I see this move as having two primary effects, first to reduce the signal to noise ratio on this list, which will hopefully improve the list for those who use it to communicate on the future of the language, and those of use who primarily read it to be kept in the loop (like myself). I think this increase in efficacy would be good for those of you either working, or volunteering your time to improve the language used by millions. The second effect would be to make it harder for new people to join the team. Regardless of the alternatives available (some discussion list rarely touched by the core team, bug reports, blindly emailing people you've never met before on the core team, etc) I think we can admit that this would present an additional barrier to entry for people wishing to get involved in the language. I could be mistaken, but it looks to me as though the core team is shrinking, both in head count and in hours spent coding. People move on to new jobs, priorities change, etc. this is inevitable and I harbour no ill will (in fact you all have my thanks for your time). Making the list read only can help increase the efficiency of those still around, but how will new blood enter the fold? While I feel it is necessary to protect the time of the people improving the language, I don't think this is a step you can take until a path for joining this exclusive list is made clear, otherwise in a few years there might not be a core team left. Paul Reinheimer ([EMAIL PROTECTED])
[PHP-DEV] CVS Account Request: preinheimer
Requesting: phpdoc I'd like to help maintain the documentation, I've been working with a few people on IRC to get some pointers, and avoid making rookie mistakes (spelling errors, one too many spaces, tabs, etc.). Philip suggested I request an account. Sean mocked me a bit. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is this what Stefan Esser was referring to ...?
I think it's rather extreme to be directing any animosity towards Chris Shiflett on this particular issue, since while he leads that group, he isn't the lead for that project. I would also not that to the best of my knowledge (being on that team) that no one has attempted to bring it up with the people working on the tool. I'll bring it up on that mailing list. paul -- Paul Reinheimer
Re: [PHP-DEV] foreach, assigning to a reference, and E_NOTICE
Being the colleague Sean refered to in his first post I thought I might weigh in. While I agree that once I looked at the base case that Sean worked out of my code the problem didn't take too long to recognize, that's not where I first experianced the problem. Problems first rear their head deep within your code, looking at it there I had no idea what was going on, all I could tell was that for some reason I was getting two copies of an object in a foreach loop (I hadn't yet noticed that I was missing one). Once Sean was able to break my code down into the simple base case and replicate the issue I understood what was happening, but just looking at my code as a whole? Not a chance. A warning on strict or or notice would have helped a lot, and that's really what I think a lot of those messages are, notices to the programmer that something odd /may/ happen. as a side note, running the zend code analyzer did not give me any warnings either. paul -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
My prefrerence would be for the interpreter to look for ?\w when
short tags is enabled (that was brace, question mark, white space), I
don't think i've ever come across an instance when a space or line
break wasn't used. I don't have a huge code repository handy but are
there any good counter examples live?
It seems that checking for whitespace (or the long tag) would resolve
all of the ?xml* issues, while retaining the majority of BC, and
hopefully allow PHP to do what it does best, work the way developers
expect it to.
paul
On 8/27/05, Steph [EMAIL PROTECTED] wrote:
Yep. I saw this happening during the PHP 5 coding contest we held last year
at Zend - some people used short open tags so I had to have that 'on' in my
php.ini to test, but having it 'on' screwed the entries that used XML, so I
was forever switching short open tags off and on.
I was supposed to prove that there was a problem in that area, at the time,
having opened my mouth over this issue.
regretI didn't actually make time to do so/regret
- but yes, I believe it's an issue.
- Original Message -
From: Sara Golemon [EMAIL PROTECTED]
To: internals@lists.php.net
Sent: Sunday, August 28, 2005 12:02 AM
Subject: Re: [PHP-DEV] PHP 6.0 Wishlist
It would be nice if PHP could not get tripped up by ?xml tags when
short_tags is on.
Already included, you may have seen this feature used before, ?php :-)
I gather he meant making the scanner intelligent enough to see that the ?
is followed by 'xml' and just ignoring the fact that short open tags is
on.
I wouldn't expect to see it happen (or want it to), but if he wants it,
here's a sloppy implementation:
Index: Zend/zend_language_scanner.l
===
RCS file: /repository/ZendEngine2/zend_language_scanner.l,v
retrieving revision 1.131
diff -u -r1.131 zend_language_scanner.l
--- Zend/zend_language_scanner.l3 Aug 2005 13:30:54 -
1.131
+++ Zend/zend_language_scanner.l27 Aug 2005 21:55:36 -
@@ -1379,6 +1379,12 @@
}
}
+INITIAL?xml([ \t]|{NEWLINE}) {
+ zendlval-value.str.val = (char *) estrndup(yytext, yyleng);
+ zendlval-value.str.len = yyleng;
+ zendlval-type = IS_STRING;
+ return T_INLINE_HTML;
+}
INITIAL%=|?= {
if ((yytext[1]=='%' CG(asp_tags)) || (yytext[1]=='?'
CG(short_tags))) {
--
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
--
Paul Reinheimer
Zend Certified Engineer
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: SOAP SSL support doesn't work when allow_url_fopen is turned off
Since comments comments were called for I thought I might weigh in with my $0.02cdn When configuring PHP I want a way to protect myself, and my users from themselves when it comes to doing something silly, I've actually seen include($_GET['function']) in running code, though thankfully never on one of my projects. I would like to be able to prevent something like this from happening at the .ini level, wether thats allow_url_fopen or some other setting doesn't really matter. Beyond that, I'm only mildly interested in granularity, and then probably at the user/directory of execution level rather than the particular function level. So something like: allow_users_to_be_foolish(yes/no) - disable remote file loading in include/require allow_remote_data_retreival(yes/no) - disable remote file retreival with fopen, file_get_contents, streams, etc. If you're setting this option don't bother installing --with-curl, problem solved. Would suit me fine. Being able to do that in .htaccess or within some other apache based structure would be great, but not really needed. I agree with the previously mentioned If their aim is that good, they deserve to be shot in the foot completely paul On 7/28/05, Jason Sweat [EMAIL PROTECTED] wrote: On 7/28/05, Sean Coates [EMAIL PROTECTED] wrote: That won't work, eval() is not a function... Ah yes, you're right... I guess we do need another INI setting. Or constructs-that-look-like-functions could be governed by disable_functions (eval, echo).. that would cause other problems (like a disabled return), though. S I think Zeev's earlier comment about If their aim is that good, they deserve to be shot in the foot applies equally well to disabled return Regards, Jason -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Paul Reinheimer -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: 'include' Considered Harmful
Quoted Text: In other words, it can only be used to include files at or below the current directory. This is counter productive, it is a horrible idea to store include files within (/below) the document root, if you're going to suggest strange sweeping changes go the reverse direction, ensure that any include'd files are outside the document root (though possibly on the local server). paul -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Yet Another Stupid Question: Why Bother with Compatibility?
The advantage of maintaining reverse compatibility is that it helps encourage people to upgrade. Many more people would have many more concerns if the 4 - 5 upgrade broke programs using depreciated practices. ISPs and hosting companies in particular would be extremely reluctant to upgrade as it would promptly result in several (hundred?) support tickets asking My code worked yesterday, now it doesn't! What did you do?!?!!. I will be honest, I've written the majority of my code in the last year, but am I 100% positive that I'm not using anything that was marked as depreciated in PHP 4? Absolutely not. For all I know I might be using some deprecated function in some arcane, rarely used administrative include file hiding somewhere in the depths of my file system. Everything would apparently keep working when I upgraded, and even for days/weeks after the fact. Then boom, one day something important brakes, and I have no idea why. I would assume that the percentage of people willing to upgrade is directly proportional to the percentage of BC. just my 2cents (canadian). paul On 4/15/05, GamblerZG [EMAIL PROTECTED] wrote: Maintaining compatibility between different major versions of PHP must be extremely hard. Maybe that is obvious, but I do not quite understand why developers do it. Why PHP 5 has to understand deprecated syntax of PHP 4? I mean, if someone needs to execute old scripts, they can always use old engine. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Paul Reinheimer Zend Certified Engineer -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Hello
noted On Wed, 19 Jan 2005 00:24:03 +, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Important notice! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Paul Reinheimer Zend Certified Engineer -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why we don’t like PHP / PHP’s anti -Apache2 FUD
I would personally consider Rich Bowen an authority on the subject, and as such trust what he is saying as true. paul On Mon, 20 Dec 2004 20:28:09 -, Nuno Lopes [EMAIL PROTECTED] wrote: Is the AddType stuff true? If yes, I can change the docs to AddHandler.. Nuno - Original Message - From: Sebastian Bergmann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 20, 2004 2:21 PM Subject: [PHP-DEV] Why we don't like PHP / PHP's anti-Apache2 FUD Via PlanetApache: - http://drbacchus.com/wordpress/index.php?p=843 - http://drbacchus.com/wordpress/index.php?p=844 Season's Greetings, Sebastian -- Sebastian Bergmann http://www.sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Paul Reinheimer Zend Certified Engineer -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
