Re: PHP File Upload Security Hole - Still No Fix?

Jon Ribbens wrote: > You didn't notice all the constructive suggestions then? I suggest you > go look harder. shit merde sheis shit merde flower sheis shit <-find the flower :-) Hmm. I, for one, would appreciate posts that required less digging. Perhaps you could <rant></rant> tag, to make your content easier to read? > I cannot write the documentation. Anybody can contribute to the errata. If errata on an issue builds up, or is important enough to put into the documentation, it is added in. This allows for _anybody_ to contribute, without having to learn DSSSL, XML, Jade, etc. etc. > Do you not understand what documentation is and does? Documentation > is a guarantee of what works, and what will work in the future. How should > I know the answers to these questions? Documentation is no guarantee. :-) It is a statement of intent, of what is currently known. This is why documentation is revised, edited, corrected, and added to. Indeed, PHP has gone _much_ further than most other languages by having real-time, 24x7, documentation correction/addition avialable to *every* user who wishes to contribute. > I would only suggest that 3 or 4 of the most frequently used functions > would be given short names. I would recommend, maybe: htmlentities, Never used it. > urlencode, Used it twice in over 120K of code lines. > addslashes Used it 15 times in the same code base. I'm trying to point out that short names and their viability depend on the functions which are used the _most_, and who uses which functions _most_ varies wildy. If we erred on the side of Perl, where massive amounts of short names lead to the "obsfusication" mockery of the language, we make PHP less usable for code portability/reading/maintenance reasons. > Sheesh, the one-letter thing is a compromise on my part anyway to make things > easier for programmers. Making things easier for programmers is usually not > the right thing to do. I think that the one letter thing is the wrong way to go, in almost all cases. Shorted mnemonics can be helpful to a point, but even figuring out which ones to use would be a battle between code styles. You see, I do a _lot_ of maintenance coding. Most coding is maintenance coding, not code authoring, so the best thing for a coding house is to use lots of longer syntax, to increase code readability. This, of course, makes the initial coding much more difficult, but the initial coding is only 10-30% of a piece of code's lifespan IME. Maintenance coders appreciate long, descriptive, variable names, descriptive function names, readable indents, etc. I've appreciated it much more when I edited my _own_ code two years after I wrote it. -Bop -- Brought to you from boop!, the dual boot Linux/Win95 Compaq Presario 1625 laptop, currently running RedHat 6.1. Your bopping may vary.