[PHP-DEV] List of all functions
I would very much like a complete list of all functions in PHP 4.3.0. Is there a way to generate this from the source tree or do I have to go through it all by hand? -- Rickard -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: List of all functions
I'm such an idiot! 20 seconds after I posted I found this: http://www.php.net/quickref.php I'm really sorry :-) -- Rickard -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Function/variable naming convention
I don't intend to start a flame war concerning coding style here (I'm sure you've had hundreds of them already). I was just curious as to why you guys chose to separate words in functions/variables with an underscore. It's not a coding standard you run into everyday. I'm not saying I don't like it, it's just not very common. /Rickard Andersson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Should I fix this?
Melvyn Sopacua wrote: I don't agree. An avatar, by nature, has a fixed _image_ size. If you allow variable avatar image sizes, then you still have the option to use that same getimagesize() to set the width and height attributes of the HTML IMG tag and the browser (any browser), will render that image, with the set values. If the image is larger, it will simply scale down proportinally and the fun for the 'malicious haxoreditor' is spoiled already. To tell you the truth, I never really thought about running getimagesize() to get width=x height=y when displaying the images. For some reason I always thought that I would be forced to save the width and height in the database (or somewhere else) in order to display the images with the width and height HTML properties. Man, do I feel like an idiot now. I tried messing with an image and using the method you described and it works great in IE and Mozilla. Opera still has problems though (latest 7.0 beta). It seems to disregard the HTML properties and relies solely on the width and height of the actual data blocks in the image. I'm telling you, for every day that passes, my hatred towards that sorry excuse for a browser grows stronger and stronger :-) IIC - your reference for disallowing uploaded images, should be filesize rather than imagesize and as described above, you can use the bug, to restrain any layout problems that arrise. Well, there's nothing worse than a browser-scaled image in my opinion. What should be validated and what should not be is up to the forum administrator (in my case anyway). Thanks for the heads up. I guess I will scrap the patch I just finished now. That is, unless someone is interested in the code. /Kennel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Should I fix this?
Pierre-Alain Joye wrote: You do not have to feel like an idiot, I always specify the widthheight for the images. Well, since I had somehow forgotten that I could use getimagesize() with every image display, I do, but if it had been a question of using the database to save widthheight, I don't. /Kennel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Should I fix this?
Marcus Börger wrote: The advantage is that this would retrieve the correct size even for gifs with multiple images. On the other hand the disadvantage is speed loss. I've been giving this some thought. Shouldn't getimagesize() just return false if the actual size (the largest size found in any of the image blocks) differs from the size reported in the Logical Screen Descriptor (LSD)? I mean, it could just report the biggest size it encounters, but the image is by all means corrupt and when a browser tries to render it, the results are, to say the least, unpredictable. I just tried messing with the values a bit and I was wrong in my initial assumption that only IE renders it incorrectly - the problem occurs in Mozilla and Opera as well. My suggestion would be to rewrite php_handle_gif() so that it does the following: 1. Fetch width/height from the LSD (as it does now). 2. Loop through all Image Descriptors and obtain the largest values for width/height. 3. If the sizes differ, return null, otherwise return width/height from the LSD (as it does now). The problem is that step 2 requires quite a lot of seeking and reading due to the nature of the GIF file format. How big this speed loss will be I can't say, but I'm gonna give it a go when I get the time (probably not until this weekend I'm afraid). If it's a big speed loss perhaps Sebastians idea isn't so bad. BTW. I'm kinda new to contributing to large projects as this one. Should I checkout the latest CVS and patch agains that or should I use some other base for my alterations? /Rickard -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Should I fix this?
My only contribution to PHP thus far is the following bug report/feature request (#18052): getimagesize() blindly trusts the width and height specified in the header of gifs. You can just hexedit the file and set the width and height to any value and getimagesize() will believe that is the true size of the image. Even worse - Internet Explorer ignores the width and height in the header and thus it is possible to, for instance, upload a much larger image in an upload form that uses getimagesize() than what is allowed. I believe getimagesize() should just skip the header and read the size from the beginning of the Image Block. I'd be glad to write a patch for image.c (function php_handle_gif()), but I though I should ask you guys first. I wouldn't want to do it in vain. As it is now I've got PHP code that checks this for me to prevent malicious users from uploading huge avatars in my forum software. /Rickard -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
