Slashdot Mirror

Because that what they say they will return. Regardless if you pass in unchecked arguments.

  How can you properly debug code if documented fuctions dont behave in the way documented and acts inconsistantly??

If you're too lazy to wrap intval around, or put (int) in front of, a string which is NEEDED to be a number -- what other horrible abominations might your code contain? In accounting software, no less? *shudders*

Also, you're flat out wrong.

http://php.net/manual/en/migration53.incompatible.php

The newer internal parameter parsing API has been applied across all the extensions bundled with PHP 5.3.x. This parameter parsing API causes functions to return NULL when passed incompatible parameters. There are some exceptions to this rule, such as the get_class() function, which will continue to return FALSE on error.

So yeah, that link. It's some kind of Barbara Streisand thing, people just don't get how hard it backfires :P Not saying PHP isn't kind of a minefield; but if you don't code accordingly, I'm just gonna point and laugh when you blow up, sorry. And hey, nobody uses PHP because it's so great, but because it runs on just about any webhost, period. See how that works? You're comparing apples with oranges when you bring up any alternative which, well, isn't really one. That's saying "use this car instead, it has much better controls for people who can't drive, and nicer seats for people who are lazy; that it only runs on main roads is surely a minor concern". Which again makes me question the whole logic/brain thing, just like posts getting modded as they are in some kind Pavlovian ballet haha.

Digging around in PHPs github repository reveals that yes - they did commit the buggy code mentioned, but it was never part of any official release. The following release - 5.2.4 - had already been fixed. (To the best of my knowledge.) This is not a general defense of PHP. I have my own reason to dislike the language as well as the community.

Because the devs have a strong stance on most of the things complain about, so you can't contribute back - like the lack of finally , for example.

They don't say what it will return if you pass in something other than a number. I just checked the documentation (php.net). This is a function that takes a float value and formats it for display as a string. The documentation clearly states it takes a float, if you pass in a string (empty or not) you are relying on how that string is treated by PHP.

Should an empty string be formatted as 0? I could imagine a situation where an empty string is returned by some other method because a value was not found in a DB, not because the value was 0. In that case formatting as 0 would be wrong. Lack of knowing a value doesn't make it 0, it makes it an unknown.

The PHP manual doesn't say that it will return 0, it says that it will return a formatted version of the $number input. When that input variable isn't a float as the function expects, exactly what is the function supposed to return?

http://us2.php.net/manual/en/function.number-format.php
string number_format ( float $number , int $decimals = 0 , string $dec_point = '.' , string $thousands_sep = ',' )

Maybe it should cause a fatal error because the input did not meet the criteria, would that be better?

That would cause isolating the already established user base.

Like when you consider mysql_escape_string vs mysql_real_escape_string

Also camel case vs underscores in function names. I am no big fan of Java, but having consistency between class name cases and function name cases helps a lot, in a way that you can just "guess" a function name. If you change all of those right now, the already written PHP code will be such a big mess.

Though something like Python did with utility 2to3 could actually be used in the next PHP major release, but I suppose they are too cocky to bring about that change.

That would cause isolating the already established user base.

Like when you consider mysql_escape_string vs mysql_real_escape_string

Also camel case vs underscores in function names. I am no big fan of Java, but having consistency between class name cases and function name cases helps a lot, in a way that you can just "guess" a function name. If you change all of those right now, the already written PHP code will be such a big mess.

Though something like Python did with utility 2to3 could actually be used in the next PHP major release, but I suppose they are too cocky to bring about that change.

The problem lies at its core. You can't fix people.

This still sounds like a weak argument. Heck, even PHP has single-call salted hashing with Blowfish these days. The problem is poor education - developers don't even know what hashing and salting is, or why it's important for passwords, so they don't even bother to look up how to do it right.

Most web hosts offered it. The PHP manual is very good.

"If the third parameter strict is set to TRUE then the in_array() function will also check the types of the needle in the haystack."

PHP is a language where you have a bit more to know what you are doing, it is easier to make mistakes (in the sense of expecting the wrong result)...

RTFM, if you want to avoid the dynamic typing, then you can...
http://php.net/manual/en/function.in-array.php

$a = array('7.1');
var_dump(in_array('7.10', $a, $STRICT=TRUE)); // false

I won't say PHP doesn't have it's faults, but dynamic typing is more feature than fault IMHO. Just use it properly.

New users are advised to use MySQL Improved mysqli_ functions

That's a user comment, not part of the official documentation, and it was added today. At least it's a little documented now as of 11 hours ago.

The fact that every function under the mysql extension has the note..

No it doesn't. I'm looking at it right now, at http://www.php.net/manual/en/function.mysql-query.php, and that string does not exist on the page.

The fact that most new users will be using a framework rather then directly writing everything anyway.

Oh, so the language admittedly sucks, but frameworks abstract that suckiness away from new users. Way to move the goalposts.

Just face it, you don't know what you're talking about, stop acting like a little kid.

You're not very good at the whole "staying on subject and presenting evidence" things, but that's OK. It'll come to you with time if you keep at it.

http://php.net/manual/en/book.mysql.php

New users are advised to use MySQL Improved mysqli_ functions rather than the older [replaced] mysql_ functions where applicable and subject the appropriate latest stable versions of Apache, php and MySQL, etc.

The fact that every function under the mysql extension has the note..

Use of this extension is discouraged. Instead, the MySQLi or PDO_MySQL extension should be used. See also MySQL: choosing an API for more information.

The fact that most new users will be using a framework rather then directly writing everything anyway. Just face it, you don't know what you're talking about, stop acting like a little kid.

Yeah, it also has this:
http://us.php.net/manual/en/pdo.prepare.php

You can still kill yourself in C++ many ways as well, you just have to be smart enough to not shoot yourself in the foot.

create a function that loops through an array and calls "bind param", or whatever MySQLi prepared statments use, for each value in the array.

As I understand it, $stmt->bind_param() is not designed to be called in a loop. It is a variadic function designed to be called once per call to $db->prepare(), with one string designating the type associated with each placeholder in the statement and one additional parameter passed by reference for each placeholder in the statement. If I were to try to bind one parameter at a time, the first call would raise an error that the parameter count does not match, in other words, that I didn't bind all the parameters in the first shot. From the documentation: "The number of variables and length of string types must match the parameters in the statement" (my emphasis on "number of variables").

Exactly.
And it does exists in PHP.
You can do that with PDO for example, which is also database agnostic.

Prepared statements. Even PHP supports them, although they don't emphasize that fact enough (such as by causing calls to mysql_query to segfault, or ideally make the server hosting it catch on fire).

I say that in humor, but I'm actually dead serious about always using prepared statements - in any language - over directly executing concatenated query strings. It's one thing if you're the person writing the DB interface library that everything runs through and the database itself doesn't provide some kind of facility for helping you. In that case, you go to heroic lengths to test, test, test that your library is bulletproof. But most people aren't writing client libraries; they're writing apps that use them. Those people should never be manually building query strings. Not "well, not usually but..." or "there are some situations where...". No there aren't. Don't do that or let anyone else around you do it, either.

as long as you escape your strings before passing them to MySQL

You know, I only hear PHP developers saying stupid shit like that. No one in Python talks about escaping strings (unless they're writing database libraries). Rubyists don't escape strings. Perl monks sure as hell don't escape strings. VB(\.Net)? programmers might escape strings, but we don't really count them. No one escapes strings anymore because it's stupid, error prone, and dangerous.

And yet PHP coderz still do it. Why? Oh, right: because the official docs teach them to:

// Formulate Query
// This is the best way to perform an SQL query
// For more examples, see mysql_real_escape_string()
$query = sprintf("SELECT firstname, lastname, address, age FROM friends
WHERE firstname='%s' AND lastname='%s'",
mysql_real_escape_string($firstname),
mysql_real_escape_string($lastname));

// Perform Query
$result = mysql_query($query);

Fucking hell. In 2012, we're still exposing newbies to that idiocy, and when they do it poorly and some kid in Latvia owns a major PHP project as a result, defenders jump out to yell "it's the programmer, not the language!"

> No licensing
Wrong

> stable
This news post is proof that's wrong.

> great track record
Wrong.

> flexable
About as flexible as your spelling.

> modules for everything
This is true. AND THEYRE ALL PART OF THE CORE API! ImageMagick, MySQL (THREE TIMES!), Curl, etc .. all in the core API.

PHP is a fucking disgrace and a blight on the world and needs to die a fiery death.

(Spend a few minutes reading the url I linked above at veekun.com for a wonderful break won on why PHP is a heinous pile of horseshit.)

http://php.net/license/index.php PHP has a license which must be respected by law. Certain parts of it have various licenses too. These are Open Source licenses, and as such have many benefits. Nevertheless, there are licenses.

Well, PHP seems to me to be perl except without the powerful regular expression manipulation, so that would make it worse.

Ahem.

PHP is -- like most languages in which people actually get shit done -- ugly in spots. But I'm constantly amazed at the flat-out inaccuracy of many haters.

All far too dense for an 11 year old, and all pretty much require more background knowledge than an 11 year old is likely to have. I'm not sure there really is an answer to the OP's question though, at that age, even a very bright kid is almost certainly going to lack the prerequisite knowledge to learn to program from just a book.

Say what?! I was programming at age 11, self-taught, using 'just books.' (Unless you count some early -- and very rudimentary -- Logo exposure in grade school; later scholastic use of the computer was, IIRC, limited to Oregon Trail, though once you got to high school you could take a class that taught Pascal...)

I got started hand-keying source code from magazines and books available at local booksellers. As I progressed, I picked up a copy (likely got it as a present) of the AppleSoft Basic Programmer's Reference Manual.

These days, I have to imagine it would be both easier (every API you need to get started is quickly available online, often with excellent accompanying tutorials and/or with user-contributed sample code snippets), and perhaps more intimidating (as the complexity of our systems has increased precipitously). (On the flip side, much, much easier to get a GUI working under Java than back in the day when you had to hand-code memory bank switching and deal with the bizarre "but it saved a chip!" oddities of Apple II graphics programming...)

Mind you, I wasn't a very good programmer, and honestly wouldn't be until I was finally exposed to proper procedural programming (C), then OOP (C++, and when it was released, Java), in college. But I had fun with it, and my stuff worked. Wasn't terribly robust or full-featured, but, it worked. (My database was a flat-file, not relational, and, um, written in BASIC... ;))

Okay, all that said, it might be worth checking out the Head First books. Head First Programming uses Python and is supposed to be a general introduction to programming. There's also Head First Java. No direct experience with either, but people rave about 'em.

1998 called, they want their troll back. It's called PDO, its been part of the core since 5.1 (released 7 years ago) is easier to use than any of the dated SQL functions.

What serious developer doesn't use PDO/mysqli and prepared statements?

What serious developer uses mysqli? (Just kidding of course!)

But really, all of our business data is on SQL Server or DB2/400. And the PDO drivers for either SQL Server or ODBC (DB2) are buggy and incomplete. Hell, the entire PHP implementation of ODBC is buggy, it intentionally trashes all numeric data types and instead treats them as strings.

PHP is my bread and butter, but it's also kind of a ghetto.

I've barely worked with Rails, but from what you're describing, isn't this bug somewhat like the security problems with register_globals in PHP, which started defaulting to "off" almost a decade ago?

Everything old is new again...

Thank you. This brings up another question: By when do you expect most shared web hosts to have adopted PHP 5.4, which according to this page is the first to include zend.multibyte?

PHP has had some security issues, but they can largely be avoid. First, always use parameterized queries (prepared statements) using PDO or MySQLi. Register Globals, which was a big problem in the past has been removed in 5.4. Most of the security problems I'm aware of can be summed up in those two things. I think the reason it has such a bad reputation is that it has so many newbie developers on it, and because there are a lot of bad tutorials out there (possibly written by newbies) that show bad practices, such as not using parameterized queries.

For me it still sounds pretty weird.. :)

But yeah, ram will help a lot, both for caching files, and especially if you use an opcode cache, like APC (which can also have a hot cache in ram).

The more ram, the less it has to wait for the horribly slow disk to spin around, and thus faster answer. Great Win (TM) :)

I'm still waiting for reasonably priced SSD's becoming normal in servers. *sigh* Being able to use an SSD for caching hot data automatically, without killing it instantly.. Sure, RAM is faster and cheap, but SSD is quite a bit larger compared to price, and still vastly superior to HDD. Ram first cache, ssd 2nd cache, disk for the stuff that no one use.

And regarding the game you mentioned.. My experience is that in the vast majority of cases, the speed problem isn't the language, but stupid code.. Write smarter, not harder! :D I don't know what he did wrong, but I know that he did something (or many things) very wrongly. 12 cores? For 400 users?

Reminds me of one of my sites, where you have long polling. First implentation (which I knew was bad, but it was easy and worked for small amounts of users) was just apache -> mod_python -> django -> polling events table every 1 second to see if latest id was changed. And abort routine after 60 seconds and reconnect.

As I said, it worked... For small amounts of users. When it started to hit the limit it hit it in a spectacular fashion. As requests got delayed, and errors started cropping up, connect queues piled up and clients reconnected and reconnected... It was like a small snowflake starting to roll downhill, and suddenly a house-sized snowball hit our server.

The current rewrite works fine for up to 1000 concurrent requests (tested on my dev server, which is weaker than prod), and worked (albeit with noticeable delays) up to 1500 connections. Current peak is around 500 connections. If we hit the new limit I'll need to rewrite it again. I have some ideas, but it would require more complexity overall, so for now the current one works great.

Err, anyway my point with that rambling was.. If you do something very stupid, then you need gigantic amounts of hardware, and can probably do things smarter. Of course..You have to look at the situation :)

There is a LUA PHP PECL extension: http://pecl.php.net/package/lua

It's relatively new, but this kind of attention could really skyrocket the extension forward. It's a great idea at large, there are a variety of situations where you want to defer decisions to your customer. Historically that meant creating a kind of pseudo DSL with a bunch of forms to fill out for the customer, with hopefully most major options covered, but usually failing to satisfy a variety of corner cases.

Another alternative is the V8JS extension (JavaScript). The advantage of JS is that more people know it already, and in may ways, JS is surprisingly elegant (not that Lua isn't). It won't perform as well as LUA though, and requires more resources to maintain the VM.

There are a handful of times where goto is simply the most elegant solution, and a handful of times where performance really matters, so encapsulating logic into a function to avoid a goto will be too costly. I've used it once since my high school BASIC days; interestingly it was only a few months ago.

We had a costly operation working against arbitrary precision numbers, with some nondeterministic aspects. Part of the data produced is very publicly visible, and because of the nondeterministic aspects of things, we had an incident where some undesirable output was produced (valid by system design, but humans found it offensive). So rather than restart the whole operation to let the nondeterministic side of things produce something more desirable, we want to change just a chunk of the data and jump back into the middle of things to recompute the downstream results.

I know I'm being vague, I have to be. I wrote the procedural equivalent, and not only did it separate tightly related logic, the performance cost was significant at this scale, even for the non-exception scenarios, and the amount of markup to support it was prohibitive. It also actually upped the CRAP score (which was already unusually high because the focus was on performance optimization). The goto alternative was literally two lines: one label and one goto, and introduced essentially no overhead for the most common use case (the vast majority of the time the produced data contains nothing offensive).

I'm still embarrassed by it, but even now going back and looking at it, I'm not sure how I would do it in a more readable or performance equivalent manner. I made sure to include a link to this comic in the source next to it, along with a clear description of why that was the path chosen over a more traditional approach.

I could be that I just fundamentally structured the flow wrong. Maybe there there was a better path through this. My team mates ribbed me for using the goto, but agreed that it was both more readable in the end, and observed the performance cost of the alternate approach; a rare exception was made in code review to allow this.

I decided to look it up.. turns out I was remembering things wrong. That's just strict variable declarations. What you want is the -l command-line option. That'll do full syntax checking for you.

Reference: http://us3.php.net/manual/en/features.commandline.options.php

The code should be separate from the HTML, not mixed.

That's why you use a framework, or at least a templating engine like Smarty. There's no reason not to do MVC with PHP other than ignorance or (short term) lazyness.

Does PHP support parameterized inputs?

Yes

The later versions of PHP (from 5.2 or so) support pretty much anything you'd expect from a modern scripting language. The only problem is, because most of these features were bolted on later, with backward compatibility an important factor, the syntax is less than ideal. In the same way, the standard library is an insane (but reasonably complete) mess in terms of naming conventions, etc.

If you can look at the first table here without wincing you've been doing PHP for too long :P

The code should be separate from the HTML, not mixed.

That's why you use a framework, or at least a templating engine like Smarty. There's no reason not to do MVC with PHP other than ignorance or (short term) lazyness.

Does PHP support parameterized inputs?

Yes

The later versions of PHP (from 5.2 or so) support pretty much anything you'd expect from a modern scripting language. The only problem is, because most of these features were bolted on later, with backward compatibility an important factor, the syntax is less than ideal. In the same way, the standard library is an insane (but reasonably complete) mess in terms of naming conventions, etc.

If you can look at the first table here without wincing you've been doing PHP for too long :P

Will if I must.
Scoping is a mess in PHP
http://php.net/manual/en/language.variables.scope.php

php: pros: easy, straightforward, multiplatform cons: practically web-only

I'm obviously a bit biased as a (primarily) PHP developer, but I should point out that PHP isn't completely web-only or dependent on a web server. It's not the best shell scripting language, but it has its uses there too.

I understand what you mean about PHP's history, but you're wrong about it being "essentially a framework," and it's also not accurate to say it hasn't evolved much. Rather than a framework, the best way to think about PHP is like a toolbox.

PHP is kind of like your grandfather's big old tool cabinet that sits out in the garage: chances are there's a tool in there that does what you're looking for. Sure, it's not a precisely-organized, polished, brand-new set of tools, like those pristine and endless ratchet sets you see at Home Depot, which are like ASP.NET and RoR. Sure, if you buy a snap-together piece of furniture from IKEA, you don't really need any tools beyond a hammer to put it together, and there are frameworks like CakePHP that try to go this route. But PHP (in the absence of a framework) is a collection of time-worn, trusty, and sometimes unusual tools that a craftsman, given some wisdom and expertise, can build almost anything with.

PHP is a language that grew out of a framework, to be sure, and the marks of that heritage are all over it, from the several modules with overlapping functionality (mysql, mysqli, pdo, for example) to the complete lack of discernable naming conventions. And further complicating the situation is the fact that, as it evolved, the creators worked hard to maintain as much reverse-compatibility as possible. That's the biggest reason why 80% of the PHP projects out there STILL look like they were written in 1997. But don't judge the capabilities of the language by the nonsense people write with it; if writing something lousy made a language invalid we'd have to give up on English too.

If you've ever seen modern (5.3 or later), object-oriented PHP written by someone who actually knows what they're doing, it's fantastic. I would still highly recommend grabbing a framework from somewhere, but it's also pretty easy to just pick and choose parts of the Zend Framework and PECL and assemble them into your own framework. And for everyone who just threw up into your mouth at the phrase "assemble them into your own framework," understand that in PHP this isn't as tedious as it could be in other languages. (My experience developing with Java frameworks was like being stuck in a hell of mirrors, but that's another story.) Almost everything snaps together, the things that don't require only minimal massaging.

PHP was designed by people who just want to shut up, sit down, and get the website written. It's easy to grok, it's straightforward to write, it's well-documented, and it lets you write code fast. And why? Because your grandfather, once upon a time, needed to do the same thing, and he had a tool for that exact purpose, and it's still in the toolbox out in the garage.

I agree that - by far - the most important factor of a good solution is the developer, but some languages are so poorly designed that they get in the way, and IMHO, PHP is one of them: __FILE__ should not resolve symlink paths.

Not strictly true:
http://us.php.net/manual/en/intro.pcntl.php

I've written a multi-threaded PHP program that runs from the command line. Works like a charm.

You call these mostly bug fixes?: http://www.php.net/manual/en/migration53.incompatible.php http://www.php.net/manual/en/migration53.new-features.php I'm not saying that the changes are in the wrong direction but they break a lot of existing applications especially if you use some frameworks. It's one thing to modify your application but it's completely different waiting for the upstream vendor to modify theirs. Don't tell me to modify the framework myself because that is the problem exactly, spending more time unrelated to my application brought on by changes in the language. Even if I modify the framework and submit the changes, there's no guarantee they will be in the next version of the framework. And if you want examples google 'magento php 5.3'. You get an error message any time you run a PHP script if you have the mcrypt library installed(which lot of software use including phpmyadmin).

You call these mostly bug fixes?: http://www.php.net/manual/en/migration53.incompatible.php http://www.php.net/manual/en/migration53.new-features.php I'm not saying that the changes are in the wrong direction but they break a lot of existing applications especially if you use some frameworks. It's one thing to modify your application but it's completely different waiting for the upstream vendor to modify theirs. Don't tell me to modify the framework myself because that is the problem exactly, spending more time unrelated to my application brought on by changes in the language. Even if I modify the framework and submit the changes, there's no guarantee they will be in the next version of the framework. And if you want examples google 'magento php 5.3'. You get an error message any time you run a PHP script if you have the mcrypt library installed(which lot of software use including phpmyadmin).

The language changes too rapidly

Erm... what? Have you actually looked at the changelog in the past few years? It's all bug fixes, there's absolutely nothing interesting going on there! Development in PHP has completely stagnated for years now. PHP 5.2 was released in 2006 (!!!) and still not everybody has caught on. Then 5.3 came out 3 years later, but it's even rarer to encounter that in the wild. The differences are totally marginal and the stuff they're deprecating is mainly bad stuff from PHP3 and PHP4 that you shouldn't have been using in anything for the last couple of years anyway.

There's a lot wrong with PHP and there's a lot of bad stuff in there, but in my opinion the worst thing about PHP is the lack of progress to improve things. So no, I don't agree the language changes too rapidly, I think it's changing not nearly rapid enough.

implode() can, for historical reasons, accept its parameters in either order. For consistency with explode(), however, it may be less confusing to use the documented order of arguments.

Just imagine, soon we can run a webserver on Windows, and even use PHP! Soon we can even have an open source database on windows. Not to mention an open source office suite! All thanks to the windows 8 store! /sarcasm.

Seriously, why on earth is this news? Windows is not incompatible with open source, you know... Just download and install. Or will MS try to lock Win8 down so much that we seriously expect to get apps from the app store???
In which case: Tnxbutnotnx.

I have found contributing to open source to be a great learning experience and also rewarding. I started my own RPC-via-socket library for Actionscript and am now working to revive a defunct PHP extension, AMFEXT. I could use help if you know some C.

YET AGAIN?
And when it was problematic before?
Come oon... I'm pretty sure PHP itself is not the problem. The problem is how do you secure your system so it can't access all the information. You can just store passwords on the system, which will never give you complete list of hashes of all accounts at once (dumb, but simple solution that works) and will send alert to admin.
Grenade in the hands of the monkey is dangerous and may kill you, but not in the hands of Rambo.

If you write code in a bad way, it can't be the fault of the language you use.

Python and perl itself works on the web server other way. You just can't isolate and limit it as it's possible with PHP.
"PHP is designed specifically to be a more secure language for writing CGI programs than Perl or C, and with _correct selection_ of _compile-time_ and _runtime configuration options_, and _proper coding practices_, it can give you exactly the combination of freedom and security you need."
http://php.net/manual/en/security.php

You just can't simply isolate Python or Perl program from the paths it's serving with anything. Only possible solution is LSM like Apparmor or SELinux.

Really? Apache has 200+ failed unit tests that are just ignored?

They're not even close to comparable. Apache has served me very well. My server is not even vulnerable to this as I don't have mod_deflate loaded or compiled. (I tested using the kill script.)

Oh, and not only is the project's QA apparently nonexistent (not that they're the only big project that doesn't have useful tests), they also don't have any sense when it comes to their website. OK, they posted a message that 5.3.7 has a severe security bug on their front page; that's a good start.

But they then should have pulled the release, and made it deliberately difficult to get to. They didn't. If you Google "PHP", the second link is to their download page, and you can grab 5.3.7 from there without ever seeing that warning.

I'm pretty sure that the project is run by a bunch of 12 year olds.

1) The problem was found and announced by "the php development community," and presumably found by them, too (admittedly, not prior to release).

That seems entirely incorrect. According to the bug report it seems to have been found by someone external, it was found in a release candidate not the released version and seemingly filed before the release was made.

2) Why aren't you involved in acceptance testing, if you see a problem with how it's being done?

Speaking for me, we pay Zend for server licences and imagine that in someway contributes to a professionally run project. Though I have to say we are becoming increasingly unsure as to whether we get any value for money for that, of the security fixes that 5.3.7 fixed I haven't noticed any of them being pushed to Zend Server in a priority fashion and I don't think we've ever had a single support question resolved satisfactorily. Sometimes being a Zend customer seems merely to open you up to sales pushes.

Looking at the actual bug report, yes, I'd say so. Returning the salt without the hash does rather defeat the point of hashing.